zlacker

>>reacto+(OP)
This is pretty much the inevitable end-game of the web, in no small part funded by ad-based business models (as the analog gap pretty much destroys most attempts to use this stuff to do copy protection) and enabled by developers who have insisted we shove as much difficult-to-implement functionality (by which I am talking about CSS complex stuff, not powerful-but-easy-to-code APIs for OS-level access) into the browser as possible.

The result: there is now effectively one dominating web browser run by an ad company who nigh unto controls the spec for the web itself and who is finally putting its foot down to decide that we are all going to be forced to either used fully-locked down devices or to prove that we are using some locked-down component of our otherwise unlocked device to see anyone's content, and they get to frame it as fighting for the user in the spec draft as users have a "need" to prove their authenticity to websites to get their free stuff.

(BTW, Brave is in the same boat: they are also an ad company--despite building ad blocking stuff themselves--and their product managers routinely discuss and even quote Brendan Eich talking about this same kind of "run the browser inside of trusted computing" as their long-term solution for preventing people blocking their ads. The vicious irony: the very tech they want to use to protect them is what will be used to protect the status quo from them! The entire premise of monetizing with ads is eventually either self-defeating or the problem itself.)

>>saurik+L5
> we shove as much difficult-to-implement functionality (by which I am talking about CSS complex stuff, not powerful-but-easy-to-code APIs for OS-level access) into the browser as possible.

"powerful-but-easy-to-code APIs for OS-level access" are actual hard-to-implement-right functionality that is often pushed to browsers with very little discussion or considerations.

>>troupo+DD
But the chance of a web page actually needing that functionality to render at all is rare for hopefully-obvious reasons. The status quo is that progressive enhancement is dead: a few-year old copy of Safari can now simply not browse much of the web anymore because it is missing some corner case of CSS or web components or whatever: I often am stuck at loading spinners or are simply thrown into a blank page... the best case is a client-side rendered 500 error on many pages.

It was critical for the web to be easy to implement the core of for a small team or even a single concerted god-tier developer--imagine Fabrice Ballard--and the current spec has failed so hard at this that even tech megacorps have thrown in the towel. People get upset about WebUSB... but that's not the API surface that is causing us issues. If I had to single-handedly implement all of canvas/WebGL/WebGPU and JavaScript/WebAssembly I could pull it off (noting I used to be a video game engine developer).

>>saurik+TF
> But the chance of a web page actually needing that functionality to render at all is rare for hopefully-obvious reasons.

The chance of a page using something has no bearing on how dificault something is to implement.

> People get upset about WebUSB... but that's not the API surface that is causing us issues.

It's one of the hundreds of APIs, and yes, it causes issues, too. Because it also needs to be implemented, and it also adds to the complexity of the web browser.

>>troupo+JL
No: it doesn't need to be implemented unless you actually want to do something with USB. Random websites aren't not working because you don't support USB. My iPhone doesn't support WebUSB even if I updated its firmware.