That's a pretty big assumption. Any decent webdev should not let GET/HEAD/OPTIONS modify state (joining a meeting is changing state) and additionally PUT/DELETE should also be idempotent.

POST with JSON (or other non-form formats) api's should also have it's content-type header checked (text/plain forms can send a JSON body but the content-type will be text/plain). PUT/PATCH/DELETE and POST with a non-form content-type (application/x-www-form-urlencoded, multipart/form-data, or text/plain) will trigger a preflight so that CORS is properly checked before the actual request reaches the server.

The current installation was fetched via HTTPS, right? Either by you or in the factory.

Just saying the "bootstrapping already happened" does not make it not happen. It still needs to bootstrap trust from somewhere

Sure, but that's true for 99% of things. Unless you establish trust outside of the normal distribution channel how would you protect against this? What is your proposed channel that is not bootstrapped from HTTPS PKI?

It's a feature of open data, it's open and usable by anyone.

> ... it does have a few small problems, such as not working on modern computers ...

When connecting to this site in firefox says

> An error occurred during a connection to tom7.org. Peer attempted old style (potentially vulnerable) handshake.

Last I checked I don't think AWS included things like Amazon Prime Video either, AWS is primarily their buissness/platform offerings, not consumer things like Twitch/Prime/Music/etc.

UK (United Kingdom of Great Britain and Northern Ireland) is a country consisting of several countries and other territories.

Why not use native css variables?

> Moreover, if you're working within a framework, such as Next.js, this minimization step automatically happens when you build, without even having to worry about whether it's happening

Again, if you are using plain css I don't think this is an issue. With any modern build system it will spit out css file for that build, right?

> After a long while, I concluded that, for me, Tailwind really is more efficient and maintainable and even more readable, but it definitely took quite a bit.

I think this sentence says it all: Any framework will be "more efficient and maintainable" once learned, even if "took quite a bit".

For tailwind I think it's an abstraction too far, but that's a decision we all do ourselves.

It sorta does matter. Either the actual raspi does nothing of value or the traffic has value that should be protected.

Sure, I heard the argument that public HTTP traffic does not need encryption but if it is of any value then both parties have a interest in it unmanipulated, uncenscored, validated or all of the before. Even if it is just preventing the ISP injecting dumb ads.

I don't see anywhere where the jump from "structuring for AI" directly leads to "laying people off", unless "structuring for AI" means there is less work for people to do, do you?

The only solution in such a case would be to manually remove the lockout flags in the db.

It is hard for serious use-cases. That does not mean you should not do it, but know what tradeoff you are doing in the build-vs-buy equation. Know that this part of your system probably requires more testing, review and expertise than your core product.