Live data from Hacker News

Web Environment Integrity API Proposal

github.com

131–140 of 460 posts

Re: Web Environment Integrity API Proposal

#131
post #75

Earlier quoted context omitted.

> There are plenty of alternatives Yeah, not for long. Go back and read the proposed changes.

Please explain what you mean. It sounds like you have an important point that can only be found if people sit and carefully read several pages. Important points deserve to be stated more plainly.

The entire point of this spec is that your alternative browser wouldn't be able to attest to its "integrity" unless it was exactly as locked down as the other ones. If you have some kind of rebuttal to the shared context we all otherwise have, maybe you should be the one forced to state it more plainly.

Re: Web Environment Integrity API Proposal

#132
post #5

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 browse…

> who is finally putting their foot down and deciding that we are all going to be forced to either used fully-locked down devices The person who wrote the proposal[0] is from Google. All the authors of the proposal are from Google[1]. I've been thinking carefully about this comment, but I really don't know what to say. It's absolutely heartbreaking watching something I really care about die by a thousand cuts; how do…

> How do we protest this?

Perhaps, make a web page with something like:

  if(navigator.getEnvironmentIntegrity) window.location="[some URL with the protest]";

Re: Web Environment Integrity API Proposal

#134
post #125
post #115

Earlier quoted context omitted.

> 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.

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 bes…

> 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.

Re: Web Environment Integrity API Proposal

#136

Earlier quoted context omitted.

> how do we protest this? You do not and you cannot. It was written in stone once Chrome dominated the browser market. What Chrome (Google) wants, Chrome (Google) gets. Despite all the good engineering Google wants to sell ads, that's all there is to it. And the result is this proposal. > The saving grace here might be that Firefox won't implement the proposal. It's irrelevant and we are an irrelevant minority. Unles…

You can by not using Google products. Change the search for ddg or kagi. Change your email for proton. Use Dropbox instead. Remove Chrome, live with iceweasel or Firefox. It is not like you'll be loosing much. This is the time to change, while we still have other players in the market.

No, you can't - not until you get a significant part of the world's population to join your protest.

The point is that if chrome implements this, netflix, amazon, facebook etc might decide they'll use this feature and only permit browsers who implement this to use this site.

Even if the only browser that does so is chrome, that's fine because chrome's market share is big enough that they can ignore the rest.

Have fun using Firefox if half of the web locks you out or treats you like a second class citizen.

Re: Web Environment Integrity API Proposal

#137
post #64
post #9

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.

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 for…

> 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.

Re: Web Environment Integrity API Proposal

#138
This isn't extreme enough. If they're going to put out a very controversial proposal like this, they may as well go all in. The push back against this is going to fizzle out, and it will be shoved through regardless of anyones opinions.

Governments will love this due to protection and security it provides among other things. I wish I could say I was surprised, but Google has continued to fail to deliver even when they try for a power-grab play like this.

Feature requests: - Add a distributed bad-actors list similar to DNS. - Start the process of introducing this functionality at the hardware level. - Require photo personal identification to prove humanity.

Re: Web Environment Integrity API Proposal

#139
post #66
post #57

The underhanded way this is being proposed is really something else. It's hosted on a non-google github to provide distance, it's worded in a way that makes it seem like this is something that benefits users, when it's the absolute opposite of that. It subverts the whole concept of a user agent. This is a huge threat to our industry and we cannot allow this to happen.

I agree with everything except the last part... It's not a "threat to" the industry... It literally _comes from_ the industry... Unless the tech industry is willing to lose one of its biggest sources of revenue, this is exactly what the industry wants...

This. As much as they'd like to pretend they're still free-spirited hippies, this is the tech industry.

Re: Web Environment Integrity API Proposal

#140
post #59

What's strange to me is that the main author of the spec -- Ben Wiser -- seems to be against closed, wall-garden paradigms as he has written in a blog post "I just spent £700 to have my own app on my iPhone" [1]. In the post, he laments the state of the App Store monopoly on iOS and ponders returning to Android for the app installation freedom. How can he reconciliate these views with this spec, which he is the main…

"It is difficult to get a man to understand something, when his salary depends on his not understanding it."

― Upton Sinclair

Post reply on HN