Web Environment Integrity API Proposal • Hacker News Board

Re: Web Environment Integrity API Proposal

#331

Post by YoshiRulz » Sat, Jul 22, 2023, 10:26 AM UTC

joshuamorton wrote: post #76

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.

The largest subsection of the document is spent discussing how to prevent specifically this situation, and this is called out explicitly as a non-goal.

They didn't try hard enough. That section concludes "Established browsers would need to only use attesters that respond quickly and fairly to new browsers' requests to be trusted," so in the end, Chrome's monopoly lets it call all the shots.

Re: Web Environment Integrity API Proposal

#332

Post by garganzol » Sat, Jul 22, 2023, 10:29 AM UTC

maxloh wrote: post #326

garganzol wrote: post #47

I see one more dangerous development imposed by this move: limiting access to web content for rival search engines. I'm sure that Google Robot will pass all "high security standards" and web integrity checks, while others won't be able to do so.

Then we may just pretend ourselves as Google bot.

We may not if the identity is validated cryptographically.

Re: Web Environment Integrity API Proposal

#333

Post by RupertWiser » Sat, Jul 22, 2023, 10:37 AM UTC

Proposal author here

I’m hoping to get back to everyone as soon as possible. I hope you can all appreciate that I’m a human being and this has been a lot!

In the mean time, I wanted to repost my last comment on the GitHub issue thread [1]:

Hey all, we plan to respond to your feedback but I want to be thorough which will take time and it’s the end of a Friday for me. We wanted to give a quick TL;DR:

- This is an early proposal that is subject to change based on feedback.

- The primary goal is to combat user tracking by giving websites a way to maintain anti-abuse protections for their sites without resorting to invasive fingerprinting.

- It’s also an explicit goal to ensure that user agents can browse the web without this proposal [2]

- The proposal doesn’t involve detecting or blocking extensions, so ad-blockers and accessibility tools are out of scope.

- This is not DRM - WEI does not lock down content

- 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

[1] https://github.com/RupertBenWiser/Web-Environment-Integrity/...

[2] https://github.com/RupertBenWiser/Web-Environment-Integrity/...

Re: Web Environment Integrity API Proposal

#334

Post by yonatan8070 » Sat, Jul 22, 2023, 10:41 AM UTC

This already exists on Android in the form of "SafetyNet", which apps can use to detect if they are running on a device that isn't "secure", like a device with a custom ROM or a rooted device

Re: Web Environment Integrity API Proposal

#335

Post by jwally » Sat, Jul 22, 2023, 10:43 AM UTC

/tinhat on

Cynical outlook because I guess its where my mind wanders I guess...

In the last year Puppeteer became a lot harder to detect, which creates a problem.

THIS would provide a solution, no?

Probably a coincidence, but a fortuitous one if creating demand for THIS feature was your goal.

/tinhat off

Re: Web Environment Integrity API Proposal

#336

Post by maxloh » Sat, Jul 22, 2023, 10:43 AM UTC

kykeonaut wrote: post #86

I am not a hopeful romantic, but the EU has been investing on vendor neutral web-browsers like Nyxt [0] and the UR Browser [1] through the Horizon Europe program. I doubt that legislators (at least in the EU) will view this as a positive development, assuming EU legislators know what they are doing. On the other hand, lobbying by big tech is still very much a threat. [0] https://nyxt.atlas.engineer/ [1] https://www.u…

The first one is close-sourced. Why should I choose it over a open-core alternative (Chrome).

Re: Web Environment Integrity API Proposal

#337

Post by maxloh » Sat, Jul 22, 2023, 10:46 AM UTC

andersa wrote: post #186

hamishwhc wrote: post #180

How can the “attesters” verify the integrity of the user agent? Sure the attestation is signed, but why can’t we mess with the data sent to the attester and just nullify the entire point of the proposal? The “browser acceptance criteria” in the spec, that would presumably contain this info, is just “TODO”. Thanks Google for conveniently omitting that key detail. Also interesting that its implied in the explainer that…

You don't send any data to the attester. It runs locally on your device, or rather is part of its core functionality. Building a chain of trust from the TPM hardware module, validating secure boot is enabled, validating the kernel and drivers have not been tampered with, eventually validating the browser has not been tampered with. You can't run your own attester - these are implemented by the companies who provide t…

Could this be reverse engineered so that third-party browsers sent the same hash as Chrome?

Re: Web Environment Integrity API Proposal

#338

Post by 1vuio0pswjnm7 » Sat, Jul 22, 2023, 10:53 AM UTC

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…

Previous discussion:

https://news.ycombinator.com/item?id=36823871

Got flagged and killed. :)

Re: Web Environment Integrity API Proposal

#339

Post by lucideer » Sat, Jul 22, 2023, 10:54 AM UTC

enumjorge wrote: post #54

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…

> The saving grace here might be that Firefox won't implement the proposal. As others have said, FF doesn't have a lot of leverage left to influence those type of decisions, but Safari might. Not sure what their position is on this proposal. The one pager has a section on stakeholder feedback [0], but doesn't name them for some reason. [0] https://github.com/RupertBenWiser/Web-Environment-Integrity/...

> FF doesn't have a lot of leverage left to influence those type of decisions

FF didn't have leverage in 2005 but we're still somehow living in a post-IE world. Leverage and market share aren't a concern, community support is all that's needed. The issue is that Mozilla Corp have been rapidly burning community bridges at pace of late, topped off by the fact that 2005 Mozilla wasn't dependent on Microsoft for their income.

Re: Web Environment Integrity API Proposal

#340

Post by tetrep » Sat, Jul 22, 2023, 10:57 AM UTC

RupertWiser wrote: post #333

Proposal author here I’m hoping to get back to everyone as soon as possible. I hope you can all appreciate that I’m a human being and this has been a lot! In the mean time, I wanted to repost my last comment on the GitHub issue thread [1]: Hey all, we plan to respond to your feedback but I want to be thorough which will take time and it’s the end of a Friday for me. We wanted to give a quick TL;DR: - This is an early…

> It’s also an explicit goal to ensure that user agents can browse the web without this proposal

How, in an information theory sense, can you stop website operators from using this attestation information to block subsets of users? The "holdback" mentioned in your reference link seems like an optional thing, as if we're concerned about good faith actors rather than the opposite.

It would be nice if the spec included examples of how a hypothetical bad actor couldn't abuse the spec to block non-attestors. i.e. How do we stop "this website only works in Chrome on Windows" but for attestation? Right now, it's trivial to "fix" because we can lie about our environment (it's likely just reading our User-Agent) and it's unlikely that the website will actually not work in other OS/browser contexts.

Some websites really do only work in certain contexts, but I think critics' concern is what happens when the website would work perfectly fine, but it refuses to. I think this is largely the same concerns people have with mobile app permissions, but those can be gatekeeped by mobile app stores who can enforce political goals such as "You can't ask for permissions you don't need and refuse to work when you don't get them", websites have no such constraints.

What's to stop websites from blocking random users now? Nothing, really. But we don't have to bypass any cryptographic attestations in order to try to work around those blocks. This spec seeks to stop that.