I would say then that we're actually in agreement... My use of the term "app-maker" was in reference to Sginal/WhatsApp etc: apps bundled/tied to services. Not to things like Thunderbird, as there is no such service bundled. Users think primarily of apps. Further, saying it's merely about services is a hair misleading, by way of the fact that the E2EE doesn't happen in the backend, by definition. I'm not sure how, given your nit-pick, one should describe an outsourced-app that is bundled/tied with a specific service. Not that I'm aware of many of those that concern the regulators. Either way, the code that the regulation applies to is the app. How you define the boundaries is beyond the scope of the regulators' understanding. They consider it one service.

ok, so your nitpick is "app-maker". I'm sure the lawmakers or bureaucrats didn't consider Thunderbird or Enigmail as relevant to begin with. They only considered Gmail's S/MIME [yes, S/MIME isn't Google specific, but Gmail is still a tightly-coupled service and software combination], ProtonMail, WhatsApp, Signal etc. probably iMessage too. From that perspective, the service and the software are vertically integrated, so well within the scope. So yeah, if mastodon started supporting E2EE, that would potentially evade this law, as the service vs software are decoupled. But they're not popular enough [yet] for the government to care.

I'm unclear that "telco" and "telecommunications provider" are synonymous. that is, "telco" doesn't mean to me "telecommunications" but "telephone company". thus yes telco is pretty distinct, but arguing that WhatsApp or Signal isn't a "remote communications" product is a hair harder

This technically is speculation, not analysis in light of the regulations themselves...
pretending that it doesn't affect E2EE I expect is incorrect. Just define the app-maker as a telecomm provider, and require them to a) keep ID b) provide a backdoor or disable E2EE.
and with ID, rubber-hose cryptanalysis becomes trivial. ditto to the guy above mentioning .bin files.

Perhaps it is my years in large-scale website traffic... but I fail to see the point of HTTP/2 or HTTP/3 in origin servers.
Edge/proxy servers? Sure. and yes, Apache *can* be used as a proxy server, but I don't think anyone uses it at scale for that.

HTTP/2 is optimized for single-user sessions with HPACK plus header-deduplication [e.g. Cookie headers]. HTTP/3 is basically HTTP/2 over UDP.
Neither are useful for origin servers, where connections are likely to be re-used for different users and there's not much use for multiplexing or pipelining.

Most business continuity plans have time horizons of hours to maybe weeks.

e.g. a datacenter goes down, you have another but it may take an hour or 3 to migrate all the business processes.
If it's a warehouse fire, you plan to reroute your logistics to serve your customers [or your own stores] with notifications of shortages over the next week or two.

This situation requires months to years.
Most BCPs involve insurance, to cover the losses of revenue or the costs of performing the plan.
I expect that "sue the bastards" is part of this plan, especially if the insurers require it.

I'm certainly old enough to have gotten into the "good enough" trap... and mostly gotten over my "ooh, shiny" phase.
But I think you may be wrong for an altogether unexpected reason: WiFi7 has MAPC [Multiple Access Point Coordination] and a sub-tech c-SR [coordinated Spatial Reuse]. If this is what it sounds like it is, and even if it isn't yet it may become it: beam-steering.
This requires more bandwidth on the backhaul than the actual used data at the wireless client, b/c the same data is transmitted by multiple APs [and potentially as uncompressed RF].
Even *better* if it then makes it possible to pierce a transmission through a noisy background like when you have all your neighbors stomping on the available channels.
It's already a thing for 5GNR, and it could be coming in less than a decade to home WiFi, at least if we can convince enough of the hoi-polloi that wired backhaul matters. Plus, in various "home automation" groups, it is already being recommended to add conduit to rooms, allowing additional APs to be added later.

Note, WiFi7 has these features in the spec, but they're all "optional"; WiFi8 is concentrating on "Ultra High Reliability" of which MAPC is a part, so they're making all those WiFi7 optional features mandatory. And the research on how to make this work in ways that matter is the subject of various papers on arxiv.org, specifically 2303.10442v3 and 2305.04846, among likely many others.

Who needs propaganda? Just observe some sheriff or city PDs around end of the quarter, for how many more cops are out patrolling for speeders. Ticket quotas are a thing.

The items specifically called out in TFS are WiFi network lists and notification data. Things currently handled in the OS, and at least the notification data is very sensitive. The WiFi data is probably too.
It's clearly not possible to eliminate notifications, at least w/o making iOS inferior vs Android's functionality.

Consider the potential ramifications of there being a BonziBuddy re-skin for the home screen that intercepts all notifications and adds bouncing bananas... and also feeds back the notification data to somewhere.

The problem you're presenting [in your 2nd paragraph] is for symmetric ciphers. But that's not the problem presented by TFA. There the question is to take a public key and produce the private key. There the math is well-defined for validation.

Additionally, albeit this is well beyond my expertise, re a plausible but incorrect decryption [of a symmetric cipher], you're dealing with a few issues.

a) you're basically asking for the equivalent of the intersection of multiple checksum/hash functions. Possible, but odd. Then again, QC is odd.
b) the number of collisions is still finite when you have a finitely sized input. The shorter the input, the fewer possible collisions there are, to the point where your posited "valid sentence" is too short to be probable. Most of the forced collisions I've read about were involving appending gibberish to the input. But again... I'm not a cryptogeek & I haven't read all the types of hash breaks, and this may also break the analogy for hash vs cipher.

re state of the rat & RSA2048... yeah, it's still state of the rat. At least 18 months ago, the last time I was directly involved therein, Google, Fastly & CloudFlare only allowed 2048 bit RSA keys on their CDNs/LBs [also 256bit EC].
They didn't care what you had on your origins [and for that, keepalive/pipelining is a thing], but for computation reasons they don't allow big RSA keys on their outward facing systems [and ditto Google's internal LBs].

I do agree that 1M qbits is believed currently impossible [who knows what's hiding in classified labs], but in any case RSA2048 is the standard and many big names have roundly rejected RSA3072 and RSA4096.

If they wrote people, that suggests they succeeded in making artificial sapience. But they should also be charged with slavery.

Barring political considerations, they can't sell the fabs. Why? They'd have to give up the CHIPS funding. Not just "give up" but likely "pay back".

a) increased efficiency doesn't change capacity factor [maybe if they added cooling, but that increases expense and thus decreases profit]. It just increases nameplate capacity.
a.1) as noted by the other guy, tracking is a thing, but that increases capex costs and maintenance. That is a possible increase in capacity factor. It also doesn't change efficiency.
a.2) does agrivoltaics help with cooling?
a.3) arguably cooling changes efficiency [bringing efficiency closer to STC from NOCT], but that's not an improvement in the cells, but rather the installation methods.
a.3.1) the panels on my house, STC/nameplate is 380W/panel. NOCT is 285W/panel. STC only happens during spring or early morning on cooler days. Total panels: 60, total nameplate 22.8. But my inverters limit to 20kW. Typical summer peak is ~16kW.

b) the states/locations where it was installed to begin with would be where it was most optimal [because that's where the investments make the most sense], e.g. lower latitudes and less clouds. Later installs would be in states that are less optimal [best case, no worse].

c) more installs doesn't change capacity factor.

Just went to NetZero's website.
Their "HiSpeed Accelerated Dial-Up" says it is "$29.95* a month" or [and this isn't linked directly from their showAllServices.do page] their DSL is "as low as $39.95* a month".