Google won't ditch third-party cookies in Chrome after all

Likewise "autoplay blocking" isn't too hard to overcome. It's more out of politeness that it's ever honored.

This is incorrect. Without 3P cookies widgets like Disqus cannot track (and automatically sign-in) user across different websites, but everything else including posting comments or liking them should work, you just need to sign-in on every website instead of doing it once.

> Any website can add Google Analytics by copy and pasting 1 line of code.

Again incorrect. Google Analytics doesn't need 3P cookies to count the number of visitors. Without 3P cookies it is just harder to correlate visits across different websites, which is what website owners don't really need, why are you supposed to know what competitor sites your users visit? None of your business.

And for cross-site authoriation there are standards like OpenID. So we could disable 3P cookies right now and Internet will work just fine.

You may need JWTs or their moral equivalents for 3rd party services but, especially for 1st party services, session identifiers are a fine enough scheme that are oftentimes implemented more securely and have the same amount of statelessness (at least from a REST perspective) as a JWT.

Not that cookies are allowable within the constraints of REST anyway due to violation of the uniform interface/stateless constraints, but pragmatically cookies have the most user agent support, and when used as just an session identifier, are relatively close to following the constraints and are much better supported than using the Authorization header or whatever[1].

Statelessness (the lack of "sessions") refers generally to the fact that the client and the server don't need to share state, i.e. the client has all it needs to make a request rather than, like, an "authorization context" or something (which is what a "user session" colloquially is). Unfortunately, the difference in the way the terms were used kinda led to this confusion which made people think that they weren't doing REST unless they were using JWTs or signed cookies.

It's the difference between storing the shopping cart in a cookie or what have you vs. creating a shopping cart resource. In the former scenario, the server has to track where in the (often implicit) state machine the current client is[2], whereas in the latter, the client has all it needs (a URI, authz token, etc) to make the request and all the state is stored server-side.

[1]: If browsers had better support for setting the Authorization header somehow, this would almost certainly just be a "best practice" that we take for granted. Automated clients with API keys tend to be better in this regard.

[2]: And there are significant disadvantages to doing it this way, if you've ever lost your cart or got those weird "session expired" errors after hitting the back button, you've ran into the pitfalls of doing it this way.