Will these ones retain vendor support longer than the last batch?

I suspect that they feel at least incrementally less burned in this case; since, while it wasn't obviously a good idea for a product, it at least goes somewhere: if you can make a phone functional and adequately rigid at that size; it's quite possible that there's a more sensible device size that you can still apply the miniaturized motherboard and whatever mechanical engineering you did for rigidity to; and just fill the rest of the case with battery; and there may be some other cases where the ability to get an entire SoC and supporting components into a particularly tiny area or make a thin component of a larger system quite rigid is handy.

Still doesn't really explain flaying a normal phone until it barely has a normal day's use with a totally fresh battery when you are still going to glue an entire baby spy satellite to one end of it; but some of the actual engineering is probably reusable.
The 'butterfly' keyboards, or the under-mouse charging port, by contrast, went nowhere. They tried and failed at a few iterations of keyboards that committed expensive suicide if you looked at them wrong; then just went back to allocating the extra mm or whatever once Jony was safely out of the picture; and it's not as though putting the port on the bottom rather than the front of the mouse involved any interesting capability development.

Whatever product manager thought that the 'air' would be a big seller deserves to feel bad; but the actual engineering team can probably feel OK about the odds that a future phone will look somewhat air-like if you were to remove the normally shaped case and larger battery.

Before flash was even practical, computers kept BIOS on true ROM and used a small persistent storage commonly called CMOS for configuration. It could be a pain because the button battery that maintained it could die.

These days, you could use a small flash for configuration and a larger one with write disabled in hardware for the boot code.

On the other hand, by far the greatest threat to your laptop is someone wanting to steal it outright and sell it off. They're not going to bother with anything on it, just blow it away with a bootleg copy of Windows and call it a day.

The people looking to profit from information on your laptop will do it from half a world away while you are using it.

This can be used to regain access to laptop you won that has been hijacked by DRM you don't want. Since it requires physical possession of the laptop, it doesn't pose much risk to the end user.

I just disable secure boot. If the device leaves my control long enough for someone to do something with it, it has to be treated as potentially compromised with or without secure boot. Why create an additional recovery roadblock for myself? Security is a funny thing if you think about it carefully enough.

Always lock your car so when someone steals your $5 flashlight they also break your $500 window. Always install security lights so criminals can see what they're doing when they break in.

So the faster we help them develop, the slower the world population climbs.

Let's face it, many evangelical Christians have voted for an administration that would instantly deport Jesus to El Salvador if he appeared today.

The upshot of my comment is that OEMs do have an easy option to not chain their devices to their cloud. They WANT to chain the devices, but then don't want to maintain the server and cry about the cost of their own self-imposed obligation as an excuse to brick features.

It's a scam.

ESP32 isn't all that new, and has never been expensive. Most of the OEMs doing rug pulls these days had the option easily available at design time.

You can put a web server on an inexpensive ESP32 these days. That server can be a lot simpler than the one in the cloud since instead of having to maintain many accounts, it only needs to handle 1.

It's stupid; but at least more honest than trying to dress 'grok' up as the master control computer.

In the MS case; it wouldn't be too surprising if that order is also the one that urgency dictates. Neither is totally unavailable on-prem only; or entirely without more-chatty-than-one-would-like behavior; but if your concern is about your dependence and Redmond's potential direct control their groupware stuff is moving faster than their OSes(at least if you have enterprise licenses and someone to handle keeping them quiet) in the direction of pure SaaS.

You'll get some nagging about how Azure Arc is definitely the cool kid's future of glorious hybrid manageability; but your ability to run Windows as though it were 15 years ago is definitely greater than your ability to run Office that way.

I suspect that this won't be the last case we see; as MS has shown comparatively little interest in backing down on the future being azure SaaS, and there's no real equivalent to some steep but temporary discounts for dealing with people who have fundamental privacy and operational control issues; while it's not terribly challenging to find a special discount that makes sticking with the status quo look cheaper than trying to do a migration.

I obviously don't expect better from these sorts of people; but I'm honestly puzzled as to why they would turn the screws so quickly and blatantly despite having gone to all the trouble of a reshuffle and a new lineup and some spiel about being likeable rather than Alexa just being something that you sort of poke at because Prime members were given a free surveillance puck with some offer one time.

Is Panay one of those abhuman lunatics who genuinely thinks that the only objection to relentless advertising is that it isn't "relevant" or "engaging" enough? Does he have a scorpion nature that leads him to knowingly doom his own product just because that's what he is? Is he just a figurehead who got to choose the case plastics colors and smile on stage; but some adtech business unit calls all the shots?

I'd fully expect this sort of thing to betray you; but only after enough of a honeymoon period for people to be pleasantly surprised by the behavior of the launch units so that there is actually enough of an install base to betray.

It sure is a good thing that 'AI' companies are notoriously discerning and selective about their training inputs and not doing something risky like battering on anything with an IP address and an ability to emit text in the desperate search for more; so this should be a purely theoretical concern.

Snark aside, I'd be very curious how viable this would be as an anti-scraper payload. Unlikely to be impossible to counter; but if the objective is mostly to increase their cost and risk when they trespass outside the bounds of robots.txt something that will just look a trifle nonsensical in places to a human but could cause real trouble if folded into a training set seems like it could be quite useful.

It can certainly be done otherwise; but it's not exactly unrelated when, in practice, a TPM is the industry standard mechanism for making a PC or PC-like system capable of cryptographically secure remote attestation; and when TPMs quite specifically mandate the features you need to do remote attestation rather than just the ones you would need to seal locally created secrets to a particular expected boot state. They are certainly can do that, and it's presently the most common use case; but locking down remote attestation was not some sort of accidental side effect of the design.

The place where TPMs potentially get toothy is remote attestation. As a purely local matter having your boot path determined to be what you think it is/should be is very useful; but, by design, you can also request that from a remote host. Again, super useful if you are dealing with a nasty secure orchestration problem(Google has a neat writeup of how they use it); but also the sort of thing that is potentially tempting for a relying party to use as part of authentication decisions.

We've seen hints at related issues on the Android side; where hardware attestation API or 'Play Integrity' API demands are made by some applications that block 3rd party ROMs, even if the boot sequence is entirely as expected(and even if the 3rd party ROM is almost certainly in much better shape than the first party one; eg. Graphene vs. some out-of-support entry level Samsung); which has chilled 3rd party ROMs considerably.

If relying parties who are important(ISPs, banks, etc.) do start demanding attestation the situation in practice becomes a great deal more restrictive.