Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Environment Integrity API Proposal

github.com

Post reply on HN
Print view View original

141–150 of 460 posts

Re: Web Environment Integrity API Proposal

#141

Post by zzo38computer »

pmlnr wrote: post #29
tentacleuno wrote: post #13

Earlier quoted context omitted.

> 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 The proposal for Chrome, you don't, because there's no stopping it. See DRM, Secure Boot, all the rest of the shitshow pursuing "trusted environment". It'll never happen, but CEOs won't accept reality. You can, however, embrace the rest: eg. keep serving your own content on http (along with https), gopher for retro compatibility, and because they are less prone to break. Keep using your curre…

> if I want resolution above 480p, I use a Chromecast with Android TV.

I am one who specifically does not want a resolution above 480p. Unfortunately, some TV services had decided to remove that feature and now it wastes disk space due to the higher resolution. I also want to be able to use an external caption decoder and recorder (in my case, the same device does both), so will use the composite video and not HDMI (which doesn't have captions).

Steven J. Searle wrote: "The sad fact of the matter is that people play politics with standards to gain commercial advantage, and the result is that end users suffer the consequences. This is the case with character encoding for computer systems, and it is even more the case with HDTV."

> keep serving your own content on http (along with https), gopher for retro compatibility, and because they are less prone to break.

Yes, it is reasonable. I think that "HTTPS only" is (mostly) no good, but having both is good. HSTS is no good.

Re: Web Environment Integrity API Proposal

#142

Post by xg15 »

cesarb wrote: post #94
drbawb wrote: post #83

There is one thing I'm not quite clear on here: >The attestation is a low entropy description of the device the web page is running on. >The attester will then sign a token containing the attestation and content binding (referred to as the payload) with a private key. >The attester then returns the token and signature to the web page. >The attester’s public key is available to everyone to request. I'm assuming "attes…

> I'm assuming "attester" here means "hardware authenticator." How is the attestation low entropy if it's presumably signed by a key that is unique & resident to my device? From what I understood, the "attester" is a remote server, which signs the attestation with its own key, after somehow verifying that the browser and operating system and drivers and machine is not running any code that this remote server does not…

Also, there probably will be per-device keys, it's just that they are only used in the communication between the attester and the device, and not exposed to the web page.

So you're at the complete mercy of the attester (and of whatever deals it made with the sites) but the sites technically can't use the token to track you. Privacy!!!

Re: Web Environment Integrity API Proposal

#143

Post by mschuster91 »

emilsedgh wrote: post #51
spystath wrote: post #20

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…

This is not the right attitude. Google wanted AMP. Google didn't get AMP. AMP is dead.

It was fun while it lasted though, finally news sites that could be read on an average German mobile data connection.

For the uninitiated: Germany's mobile phone network has been ridiculously expensive and unreliable for decades. Everyone else in Europe has done it better, because no one else thought they could extort 60 billion euros from the providers for RF spectrum licenses - we're still paying for that blatant debt-shifting today.

Re: Web Environment Integrity API Proposal

#144

Post by mschuster91 »

apostacy wrote: post #106
riffraff wrote: post #37

Earlier quoted context omitted.

I think in this case Firefox is in a different position: if it didn't support EME netflix wouldn't work. But in this case it could report "sure, this is a real user alright" by being its own attester, can't it?

So what if Netflix doesn't work?? That is the choice of Netflix. Big content will always want more control. Firefox will never be able to keep up. They will just do a mediocre job of working against their users. Microsoft and Real Player pushed hard for an integrated ActiveX based DRM ecosystem over a decade ago. I'm so glad that Mozilla flatly refused to entertain such idiocy. I sure wish that Mozilla still existed.…

The problem is, back then most people on the Internet were techies. They knew their shit.

Today? Guess who Grandma's gonna call with "my Netflix isn't working"? And she won't care why, all she cares about is Netflix.

Re: Web Environment Integrity API Proposal

#145

Post by WhyNotHugo »

tentacleuno wrote: post #13
saurik wrote: 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?

Probably the privacy angle is best. Given that this uses an "attester’s public key", this enables to uniquely identify a given device repeatedly over time with no margin for error. It's essentially "perfect fingerprinting".

There's also the option that devices don't use a per-device key. If all the devices from a vendor use the same keypair, then this would be broken by just extracting the key from a single device (AFAIK, in the US this would likely not be legal to use).

Re: Web Environment Integrity API Proposal

#146

Post by 20after4 »

xg15 wrote: post #136
motbus3 wrote: post #122

Earlier quoted context omitted.

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…

It might be time to abandon that half of the web. Radical software freedom ideology is looking less radical and more rational by the day.

Re: Web Environment Integrity API Proposal

#147

Post by xg15 »

I think "don't use Chrome" is really not the best way to fight this - instead, make it known. Get out to as many people as possible that this thing exists, spread awareness, explain the consequences, make a stink.

Google is absolutely in a position to implement this and I figure a good number of sites would immediately join. However, the image of "tech" is tarnished enough already and the general population is more aware of the importance of having control about their online experience.

So I'm kinda optimistic that more public awareness of this might lead to a larger backlash and might make Google think twice in continuing this, lest risking a PR disaster.

Re: Web Environment Integrity API Proposal

#148

Post by gray_-_wolf »

freeone3000 wrote: post #112
jabbany wrote: 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.

There is no key in chrome, the signing is done via a 3rd party server.

Re: Web Environment Integrity API Proposal

#149

Post by Buttons840 »

saurik wrote: post #131
Buttons840 wrote: post #128

Earlier quoted context omitted.

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.

Okay, so you're not saying that we're going to lose the ability to use another browser, just that the other browsers might not be good for much.

I think the comment you originally replied to is trying to say "use the other browsers, even if they are not good for much".

Re: Web Environment Integrity API Proposal

#150

Post by charcircuit »

tshaddox wrote: post #28

It seems like a pretty clever way to propose extremely powerful DRM functionality, phrased as if it’s about trust and security.

L1 DRM for browsers already exists. This is about providing an extra layer of security to sites that may need it like banks.
Post reply on HN