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

91–100 of 460 posts

Re: Web Environment Integrity API Proposal

#91

Post by wmf »

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…

Maybe your device sends a signed attestation to the OS vendor and they generate a more generic attestation (basically "this is a legit Chrome browser running on Android but I won't tell you anything else").

Re: Web Environment Integrity API Proposal

#92

Post by drbawb »

h4x0rr wrote: post #36
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…

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

I doubt Apple will be our savior here. Apple is in a great position to implement this spec: their secure enclave and the systems they've developed around it are practically the state of the art. Also Apple is in bed w/ traditional media. (Apple News, Apple TV, iTunes, etc.) Microsoft has been doing the same[1] for years w/ Pluton on the Xbox to protect their IP. Google has been doing this on Android using, dm-verity, SafetyNet, et al. Nintendo employs similar protections on the Switch with moderate success. (After the bootrom of the initial HAC-001 was patched on the production floor the only real option to attack a modern Switch is physically glitching the console.)

I suppose Apple may object on the grounds of being a "privacy focused" company, but I'll believe that when I see it. I'm not gonna sit here holding my breath for these megacorps to do the right thing.

[1]: https://www.youtube.com/watch?v=U7VwtOrwceo

Re: Web Environment Integrity API Proposal

#93

Post by wzdd »

fabrice_d wrote: post #14
PaulHoule wrote: post #3

Earlier quoted context omitted.

It looks very similar to the “secure boot” mechanisms in Windows and other commercial client OS. Strikes me as very dangerous though on the web where there are so many paths for malware to get in and this could get in the way of plugging the holes.

No, it's similar to attestation APIs like android SafetyNet (now called Play Integrity API) that are used to check that "your ROM is valid according to Google". Secure boot can protect you eg. against malware gaining write access and modifying your system. I see it as user protection, as long as you can sign the trust chain. This is what GrapheneOS is doing as far as I know.

A trust chain beginning at the bootloader is what will ultimately enable this API, though, because that's what SafetyNet/Play Integrity API relies on. If you don't have a locked bootloader, or you're not running stock Android, you won't pass SafetyNet/Play Integrity (at least the higher tiers of it).

To take your GrapheneOS example, apps wishing to support it must add GrapheneOS keys: https://grapheneos.org/articles/attestation-compatibility-gu...

If this proposal goes ahead, it's unlikely that you'll be able to convince site owners and/or ad networks to add the keys of your open source OS.

Re: Web Environment Integrity API Proposal

#94

Post by cesarb »

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 completely trust. That key can be used at most to identify the remote server, which is supposedly shared by a wide number of devices.

Yes, this means that your browser depends on having a working connection to that remote server for every attestation it makes, and that if that remote server colludes with the web page (or is compromised), it can leak your identity.

Re: Web Environment Integrity API Proposal

#95

Post by t0astbread »

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…

Generally agree but I don't think Secure Boot falls in this category unless the keys are locked in firmware (and in that case the firmware is the problem). Root passwords aren't evil either just because they can be withdrawn from the user.

Re: Web Environment Integrity API Proposal

#96

Post by Terretta »

jabbany wrote: post #30
dmantis wrote: post #7

The literal attempt to censor web usage of Linux and BSD desktops, other FOSS clients, custom Android ROMs, etc with an open reasoning "to sell you ads". They don't even try to masquerade it.

Yeah I mean the first of their examples is literally: > Users like visiting websites that are expensive to create and maintain, but they often want or need to do it without paying directly. These websites fund themselves with ads, but the advertisers can only afford to pay for humans to see the ads, rather than robots. This creates a need for human users to prove to websites that they're human, sometimes through task…

Why stop there. Let's see who is behind the problem they're solving with item 2:

Some examples of scenarios where users depend on client trust include:

1. Users like visiting websites that are expensive to create and maintain, but they often want or need to do it without paying directly. These websites fund themselves with ads, but the advertisers can only afford to pay for humans to see the ads, rather than robots. This creates a need for human users to prove to websites that they're human, sometimes through tasks like challenges or logins.

2. Users want to know they are interacting with real people on social websites but bad actors often want to promote posts with fake engagement (for example, to promote products, or make a news story seem more important). Websites can only show users what content is popular with real people if websites are able to know the difference between a trusted and untrusted environment.

Not written in item two: And the people paying to promote the posts funding these sites want to know the promotions are landing on real consumers' screens.

Re: Web Environment Integrity API Proposal

#97

Post by akomtu »

TheAceOfHearts wrote: post #6

This seems like a step closer to killing the open web. "Sorry, you can only access this website using this specific device with a browser compiled by Big Tech, it's for your own good." Not surprising that this is all coming from Google, the world's biggest adtech company.

It's the ad-tech sector of the web declaring a secession from the internet, for ads can't live under the law of the open web. The new AdWeb is going to look like appstores: websites will need to pay to the adweb owners, and users will need to use smartphones or locked down browsers. As for the open web, it will stay and continue evolving free from money making concerns.

Re: Web Environment Integrity API Proposal

#98

Post by rpastuszak »

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

It's not even phrased like that... If you read their examples it's very clear that they're not hiding the goal of using it as DRM for advertisiers. In fact, their first example (!) outlines how this would be appealing to advertisers because they can attest a real human is viewing the content.

It's very likely that technical (or otherwise) decision makers at ad-tech adjacent businesses are the target audience of that documentation, not us.

Re: Web Environment Integrity API Proposal

#100

Post by andrethegiant »

leodriesch wrote: post #17
lucideer wrote: post #12

The issues tab is a fun read - never seen a response like this on a web spec.

They seem to have closed down comments on it, I'm seeing > An owner of this repository has limited the ability to comment to users that have contributed to this repository in the past.

> I’m giving everyone a heads up that I’m limiting comments to contributors over the weekend so that I can try to take a breath away from GitHub. I will reopen them after the weekend

https://github.com/RupertBenWiser/Web-Environment-Integrity/...

Post reply on HN