I still don't get it. This approach still leaves all the wireless points of failure in place and adds CPE points of failure. I literally, and not pig-headedly, not understanding why you think it is better to replace the POTS as system-of-last-resort with FTTH rather than by defining wireless to be the system-of-last-resort.

Perhaps we are solving different problems. I am not trying to bring, nor guarantee, broadband to the masses. POTS doesn't do that, anyway. I am very specifically addressing the problem that these POTS-maintenance laws were intended to address; viz, households need a method to call emergency services in case of disaster, and that method needs to be as robust as possible across a variety of scenarios. It seems to me that wireless service minimizes both the cost and points of failure (if correctly dimensioned and maintained).

Jamming is an exotic scenario and a different argument from disaster robustness. An attacker who wants to take out a _lot_ of communications at once can take out infrastructure, which is in some ways cheaper than trying to jam spread-spectrum networks over a wide area.

As for the "places it won't reach" - sure, there are edge cases in both scenarios. Forcing a telco to keep a specific legacy system alive prevents them from using better solutions to those edge cases. If CA wants to mandate something, they should mandate a set of technical standards for connectivity and availability and let the telco solve for that problem.

Having worked in the alarm industry (Ademco -> Honeywell) for quite a few years, I can tell you that it is a cliche in the industry that alarm systems are installed and left in situ without modification for literally decades. Monitoring fees are dimensioned as pure passive income and a truck roll is the cause of wailing, rending of garments, and gnashing of teeth. I was involved in the Great Migration in the mid-2000s when regular POTS started to get VoIP legs in the middle in some of our biggest markets. There was not exactly joy in the monitoring/installer industry about having to persuade customers to buy new equipment and pay for additional monitoring services due to force majeure. There never is.

Aggregator to CO is almost certainly on fiber in most instances, probably still using up dark fiber laid in the WorldCom era. Regardless, it's a lot less effort to maintain one (or let's say two or three - for redundancy) copper links between nodes and central, than it is to maintain thousands of individual links to consumers. No matter how much you mux and demux in the middle, ultimately 10,000 individual homes require a minimum of 10,000 copper pairs from the home to ... someplace.

Note that this isn't quite the transparent plug and play you might think - things that aren't human voiceboxes and ears will notice the difference. Alarm systems, certain legacy home medical monitoring equipment, demand regulation equipment, etc.

Right, because it is easier to get a smaller ask approved than a larger ask. Asking to sunset the entire POTS network would be a bigger ask, less likely to succeed. But the goal is the same. Once they're allowed to block any new accounts, you have natural attrition - as people move house, die or otherwise conveniently discontinue their POTS services, those POTS services are not reconnected at a new location, and the POTS footprint starts shrinking even faster than it is today. So the next time they go to the gubmint, AT&T says "only 0.1% of our customers are using POTS, can we pweeeeeeeeeze kill it now?"

But you're missing the fact that in the wired copper POTS scenario, the telco's backend still needs to have power 100% of the time; whatever way you slice it, the telco needs to install and maintain backup power systems. And with wires you can't fall back to a different local node if the one nearest you - the one you're wired to - goes down. With cell service, subject to ToF-based protocol limitations, you can possibly handoff to a more distant node if an earthquake, fire, battery failure or Godzilla attack eliminates your local cell tower.

Why do you stipulate wired? No matter how I look at the failure scenarios, wireless seems to be more robust. In the wired scenario, you have local nodes with backhaul to the telco, and from those local nodes you have the last mile to the house. Assuming the last mile is IP and not analog voiceband, you still need battery backup at the customer end for the ONT or modem or whatever "hub" equipment is at the customer premises, even if the customer is using an analog POTS phone plugged into that "hub" as their emergency voice product. In real life, customers are mostly using WiFi-connected devices - phones, laptops - which require their own battery charging infrastructure anyway. Moving to a wireless network connection that eliminates the physical last mile seems to me to actually improve system robustness. The telco only needs to characterize battery backup for the equipment it owns - local node, and backhaul, and so forth. The customer uses their own devices and can have spare batteries, power banks, UPS, etc if they want. In the wired scenario the telco has to plan for an unknown number and load of customer devices, and once the telco's UPS goes dry all customers fall off the grid immediately.

Of all the things that never happened, this never happened the most. Flip over any POTS phone sold for the US market. You'll see a REN marking on the bottom - Ringer Equivalence Number. That number specifically characterizes the current drawn by the device when ringing. 1.0 is your standard legacy electromagnetic clapper. Electronic phones are typically in the ballpark of 0.25. If you put too many devices on your line, the world comes to an end - sorry, no, I mistyped - if you put too many devices on your line, one or more of them won't ring properly. In the days of pure electromagnets, consumer lines were typically rated for a total REN of 5, meaning you could have your main phone and 4 extensions on the same line. If you put too much load on the line, in the electromagnet days, you'd get quiet or no ringing. These days I can't imagine plugging in enough devices to overload the line, but if you did they would behave erratically. There is no "blowing the breakers by putting too many phones on the line". Circuit protection devices at the telco end prevent your shenanigans from causing trouble for other people.

... that any future Anthropic employee ever signs. The sourcecode contains trade secrets. Everybody who worked for Anthropic at the time of the leak is enjoined from talking publicly about those trade secrets. But consider the programmer they hire tomorrow, who has already read the leaked sourcecode. He already knows these trade secrets by virtue of their publication (no matter how inadvertent). So his NDA is inherently flimsier - Anthropic can't restrict him from talking about stuff he already knew about before he joined them.

Checking isn't the problem being solved. Sure I check what I run. Being able to check it on the webpage, then cut and paste it, then maybe check again that I cut and pasted correctly - is far less work, and FAR less error prone than having to type it in. Not to mention faster. If I validate it once, I can Ctrl-V multiple times rather than typing it all out again multiple times. Assume that I have sufficient sophistication to insert check steps where appropriate. Blocking me from using a simple memcpy() to do something rather than having to synthesize it every time is a productivity drain.

I mentioned nothing about random web pages. In our git repos, there are plenty of internal docs saying "to provision the embedded device, plug it in and run this 200-character commandline". Being able to paste those vs typing them saves a lot of time.

Current versions of MacOS have something called "System Integrity Protection" which restricts certain directories from being tampered with even in a su'd shell. It can be disabled, but it's a very off-label way to run the OS and the consequences could be ... spicy.

True but useless. For a long complex commandline input, it saves a lot of work to be able to paste it in. Not to mention the possibility that a typo might have undesirable consequences.

The thing is, I believe you just illustrated my point. You have to set up exotic environments to try to preserve opsec, and opsec is never a static thing - your system works until it hits a failure mode you didn't anticipate, and the cloud agent you're interacting with is constantly evolving. I'm less concerned with "how productive it is" - maybe it is the best thing since sliced bread. I'm not even concerned with "how reliable is it" - I want to check LLM output before I field it anyway. I'm by far the most concerned with "how SAFE is it"