zlacker

[return to "Web Environment Integrity API Proposal"]
1. caesil+29[view] [source] 2023-07-21 18:49:55
>>reacto+(OP)
Whether you like it or not (and I certainly don't), you've gotta sort of admire the sheer vision of a fifteen-year project to build a browser so good it comes to monopolize the industry, all because you've had the foresight to realize that monopoly will be crucial to securing your position as the adtech hegemon. An underrated masterpiece of evil genius.
◧◩
2. kibwen+nh[view] [source] 2023-07-21 19:28:26
>>caesil+29
And tech people fell for it hook, line, and sinker.

It's completely and utterly irrelevant that Chromium is open source, because the web is a protocol, and having the source for an implementation of the protocol doesn't matter in the least when you don't control the protocol. You can't just fork Chromium and remove a feature, because websites expect the feature, and your browser won't work on them. You can't just fork Chromium and add a feature, because websites don't care about your tiny fork and won't use your feature. You can't fork Chromium, you have to fork the entire web.

◧◩◪
3. zzo38c+AN[view] [source] 2023-07-21 21:51:19
>>kibwen+nh
> You can't just fork Chromium and remove a feature, because websites expect the feature, and your browser won't work on them. You can't just fork Chromium and add a feature, because websites don't care about your tiny fork and won't use your feature. You can't fork Chromium, you have to fork the entire web.

In some cases you can (although it may be difficult, because the code might be difficult too and maintaining with merging changes can make it difficult too).

You can remove features you don't want, possibly adding fake features in its place or those that access other features, e.g. the microphone access to instead access a file, etc.

You can add features that most people don't use even if you do use them. It can also be implemented in ways that are backward-compatible. Also, some features that are added are not features that the web pages will need to know anything about, because they are user features instead.

Nevertheless, some things cannot easily be forked in this way. For example, adding a "Interpreter" header to add support for additional file formats and make it compatible even with browsers that do not support it, cannot be made compatible unless you add a request header to specify its availability too I suppose, and then just complicates it.

[go to top]