Live data from Hacker News

Web Environment Integrity API Proposal

github.com

191–200 of 460 posts

Re: Web Environment Integrity API Proposal

#191
post #36

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…

What about Safari? It has significant market share. Seems like our best bet now

If my goal is to try to avoid vendors locking down what I can do with my computer, I don't think switching from Linux to MacOS is going to be an improvement.

Re: Web Environment Integrity API Proposal

#192
Oh by "Web Environment" you mean "my machine" lol!

I already got caught by this kind of thing - a https://github.com/nativefier/nativefier app wrapping Youtube Music doesn't work, because Google detects somehow that you are not using a trusted browser and refuses to serve.

This is sort of moving in the "zero trust" (as in let's use ML etc. to detect if we trust something. username/password is not enough), which I fear because it will break a bunch of stuff for genuine users and make things less reliable.

Re: Web Environment Integrity API Proposal

#193
post #72

It's time to break Google up. They're the AT&T and Standard Oil of our generation. Make Ads, YouTube, Search, Cloud, Chrome, etc. all independent companies. Demand that antitrust regulators do their damn jobs for a change.

counterargument: let's say the us gets in a real war with china, a massive conglomerate like google would probably make massive contributions to cyber/technological warfare that the individual pieces would have a hard time doing i agree they should be broken up, but it might be the wrong time for it.

Can you give us an example of wartime contributions that require expertise across the verticals of browser vendor, advertisement marketplace, a remote home video/audio monitoring vendor, an OS vendor, and a productivity software vendor? How does integrating those verticals help in an attack or defense scenario any better than having those separated?

Re: Web Environment Integrity API Proposal

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

Google have thrown enough mud at the wall that something stuck?

We could be here saying "Google was genius releasing Google Plus - that stopped Facebook etc. in their tracks and now they own social media"

Re: Web Environment Integrity API Proposal

#196
post #25

Earlier quoted context omitted.

It's signed? Sure you can fake the results of an attestation in your fork, but your fork would be using your own key to sign the response, a key that the site can reject.

Ah, we’ll also have to extract the key from chrome. It’s no worse than WideVine.

I don't believe any of the HD widevine keys have been revealed.

I would practically guess the keys that did get revealed were deliberately leaked, low stake keys, that keep people still willing use to use widevine platforms at low res without being angry.

Re: Web Environment Integrity API Proposal

#197

If this isn't added to the web you will see things like banking websites go away and require a mobile app. Features like this keep the web relevant.

Banking web sites seem alive & fine & well, so unsure what you are trying to claim here.

Re: Web Environment Integrity API Proposal

#198

I'm highly annoyed by this prospect (I do love tinkering with the websites and cannot imagine using web without UserCSS, UserJS and ad block...)

There's been some wishy claims maybe perhaps users-scripting & debugging will be left intact, that the intent here is about other levels.

But there's basically no real actual meat to this specification. It's abstract: it doesn't really say what Web Environment Integrity is, it's up to the browser to determine, and the rules could keep getting more and more and more specific at the browsers leisure.

Re: Web Environment Integrity API Proposal

#199

If this isn't added to the web you will see things like banking websites go away and require a mobile app. Features like this keep the web relevant.

Banking web sites seem alive & fine & well, so unsure what you are trying to claim here.

When P(fraud|request from browser) increases and P(fraud|request from mobile app) decreases and P(customer has mobile device) approaches 1 it starts making less and less sense to support running a web interface.
Post reply on HN