>That's settled then. Full filesystem, location, camera, and microphone access should therefore come on by default without a permission dialog. Why not bring back Java and Flash while we're at it! It's not the browser vendor's fault that websites are misusing it.
Now who is arguing in bad faith? if you have read the proposal, it's clear that they are being careful and are upfront about the some potential misuses and the proposed handing of them.
> to verify that your system is using a Google-approved bootloader to load a Google-approved operating system which only loads Google-approved drivers and Google-approved software (or worse, website-approved software).
again there is no such thing proposed.
The "attester" is not specifically Google. anyone can become an "attester". The chain of trust is a chain that trusts tokens not specific "things". if you for example would trust let's say Opera as the attester, Opera would need to trust windows or Linux or Android as the OS attester.
The analogy here is the certificate Authorities. You may very well have a "let's encrypt" attester that democratizes the good parts (certification) without the bad parts (too much information) .
> if you for example would trust let's say Opera as the attester, Opera would need to trust windows or Linux or Android as the OS attester.
But it's not the user ("you") deciding which attesters to trust - it's website operators. And they will choose to trust only attesters that meaningfully (cryptographically) verify the user's client environment, including the secure boot chain, OS, and browser. Otherwise the attestation can be spoofed, in why case why would they bother using the EnvironmentIntegrity API at all?
> But it's not the user ("you") deciding which attesters to trust - it's website operators.
You know what? They are already doing it. This just gives them another option.
> And they will choose to trust only attesters that meaningfully (cryptographically) verify the user's client environment, including the secure boot chain, OS, and browser. Otherwise the attestation can be spoofed, in why case why would they bother using the EnvironmentIntegrity API at all?
You might as well complain that any website requires any sort of authentication or authorization.
How is WEI any different from all the other current methods which have not killed the "open web" in the way the hysteria over WEI is claiming?
Really?? Mind telling me how to access Netflix, Disney+, or any other streaming service without authentication/authorization? I'll take the information on banks too.
Where did I say you could access these without authentication? Nowhere.
But I can still access them with my device being controlled by me, I can create bots/extensions to export and archive content. I can because there's no reliable method to identify whether my device acts in my interest, so they have no choice - they have to restort to methods that can be cracked. WEI is an attempt to introduce that reliable method.
Sure, there's EME with Widevine L1, but this is currently limited to providing media content, not apps themselves. That's why WEI is considered the DRM for the web.
I have, and that is not a viewpoint unless you wrote the proposal.
> if you have read the proposal, it's clear that they are being careful and are upfront about the some potential misuses and the proposed handing of them.
The goal of the proposal is strictly incompatible with our freedoms. After all, restricting which devices, environments and software we're allowed to use to visit the website is the entire point of this proposal, is it not?
> again there is no such thing proposed. The "attester" is not specifically Google. anyone can become an "attester". The chain of trust is a chain that trusts tokens not specific "things". if you for example would trust let's say Opera as the attester, Opera would need to trust windows or Linux or Android as the OS attester.
So what? Even if this were true in any practical sense, as a user I have no control over which attesters the website trusts - and they will require attestation from parties that attest that I'm running the latest version of Windows or MacOS with Spyware version 5.49.182 installed, and another party that attests that their ads are visible in my framebuffer.
That won't happen immediately, of course, it would be much too obvious. But introduction of WEI establishes a clear path forward towards that reality. Once WEI is in place, the chain of trust will continuously creep up the stack until everything from the TPM chip up to your framebuffer and display is locked down. They'll slowly boil the frog, like they always do.
> The analogy here is the certificate Authorities. You may very well have a "let's encrypt" attester that democratizes the good parts (certification) without the bad parts (too much information) .
That's a terrible analogy. For one, the only thing TLS server certificates attest to is that I *the user* am connected to the *server* that I intended to connect to.
A better analogy would be mandatory TLS client certificates which would attest that I'm John Doe, underage, registered to reside in a country where the legal drinking age is 18, warning the websites that my juvenile criminal record is spotty. That's what WEI is comparable to, and you'd see a similar level of pushback if that's what was being introduced.
> it's clear that they are being careful and are upfront about the some potential misuses and the proposed handing of them.
On the contrary, my main issue is that they identify one of the primary issues and fail to address it.
The biggest issue is that web designers will design around WEI such that the web is unusable without it. For example, while the current use case might be “captcha without WEI, no captcha with WEI”, a future use case might be “captcha with WEI, 401 without WEI”
Essentially this means an end to the open web: websites block you if you aren’t attested. If you want to browse from NewOS, tough cookies that’s not recognized by attesters
This is addressed in the proposal in “Open Questions > How will we prevent this signal from being used to exclude vendors”.
The only proposed solution is in section “Holdback”:
“[…] we are evaluating whether attestation signals must sometimes be held back for a meaningful number of requests […] Such a holdback would encourage web developers to use signals for aggregate analysis and opportunistic reduction of friction, as opposed to a quasi-allowlist […]”
This is a massive potential issue. The author acknowledges WEI could become an allowlist for the web. The author implicitly acknowledges this is most likely if most clients are using WEI (hence, the proposed solution of artificially decreasing WEI usage via holdback)
And even then, the proposed solution of holdback is not a solid one. There’s no technical reason that WEI will continue to have holdback in the future, at best maybe a google pinky promise. Further, there’s solid game theoretic reasons we can predict that holdback may vanish: if popular sites start using WEI as an allowlist, then any browser with holdback will have a degraded browsing experience on a percentage of visits. You can win market share by abandoning holdback!
As a tragedy of the commons, we can reasonably assume in the long term WEI is supported on all visits by all major browsers and a nontrivial number of websites use it as an allowlist.
In conclusion: the author admits WEI breaks the open web with sufficient market share, but the only proposed solution seems guaranteed to fail in a competitive browser marketplace based on game theory.
> The biggest issue is that web designers will design around WEI such that the web is unusable without it. For example, while the current use case might be “captcha without WEI, no captcha with WEI”, a future use case might be “captcha with WEI, 401 without WEI”
You know they can do that right now, right? They aren't doing it. Will more do it because it is simpler now? Sure. Will it put "an end to the open web"? Nope. If they wanted to end it, they could have already achieved that. WEI is just simply another better option for the websites which sorely need it. Sure, some other sites will abuse it, but I think you already avoid them since you still think the "open web" is still a thing.
I’m not sure what you mean by “they aren’t doing it”. WEI doesn’t exist yet, obviously nobody is blocking clients who aren’t attested.
More to the point, even the author of this proposal has recognized this is an issue, identified it as so in the proposal, then failed to put forward a workable solution. That’s my problem.
> I’m not sure what you mean by “they aren’t doing it”.
Making the web impossible to use if you don't fit into their specific requirements. WEI is just another signal. It won't be the only signal for the vast majority of the web. Google cannot do anything to break the web without the help of Apple. Frankly, Apple has a better chance of breaking anything open than Google does. Apple has the vertical control. Google has what? Chrome? I just don't understand how people seem to think Google has all this power, but continue to ignore Apple.
> WEI doesn’t exist yet, obviously nobody is blocking clients who aren’t attested.
Yet a lot people seemingly know its going to do this, that, and some other bad thing even though there is no proof and stated goals which are the opposite.
> More to the point, even the author of this proposal has recognized this is an issue, identified it as so in the proposal, then failed to put forward a workable solution. That’s my problem.
They cannot prevent websites from requiring X to access their sites. There is no workable solution to force someone to accept traffic against their wishes. If they only accept requests with some custom header, that's their prerogative. Many features of browsers have been (ab)used for "nefarious" purposes. Should we get rid of those? This whole thing feels like since Trump is not president in the US any more, certain people need a boogeyman and are using Google in his place. Anything Google does is automatically bad.
> They cannot prevent websites from requiring X to access their sites.
They can by lowering amount of signals site gets - so to make it impossible to guess what client is running.
> There is no workable solution to force someone to accept traffic against their wishes.
Not give someone way to disallow traffic based on OS or Browser.
> If they only accept requests with some custom header, that's their prerogative.
And it is users prerogative to not give you any custom header which they do not want - or if you force them to do so give you not real one.
>Many features of browsers have been (ab)used for "nefarious" purposes. Should we get rid of those?
Yes we should. Or at least we should do risk assesment on those to check if they should be part of standards and Browsers. We should do more risk assessment of any new feature and standard.
>Anything Google does is automatically bad.
If they start championing privacy and less pro-corpo bs - I will applaud them for that.
> This whole thing feels like since Trump is not president in the US any more, certain people need a boogeyman and are using Google in his place.
Don't bring your (USA) bs politics to this - if anything it is your fault to not make proper regulations on your market.
> even though there is no proof
If you understand even tiny bit of tech - you will see the definite proof - the proposal.
1. Authors don't understand what tech they use. (not possible as they acknowledge issues)
2. Authors don't understand that something unrealistic is unrealistic.
Idea that you can give companies or corporations tools to check "did user modify his environment" and they would not use it to exclude users is stupid or disingenuous because advocates for this did exactly comment in such way: We want this proposal to do precisely that.
Again Google tries to defend it by saying "we will return invalid 'false' for some of the users/times of Chrome users" [to make sure that website will not do that] which for me is not only bad because it then creates "when google revokes this policy we are in even worse situation" but then leaves the issue how google decides "who" to give back this 'false':
I will reject times immediately not only because this can be easily circumvented by website [check n-times] to detriment of user but it would also contradict official documentation of WEI (same token for same input from user).
And this leads us to another point - if Google wants to return false negatives it would need to either keep information that is supposed to return 'false' - EU will not be very happy with that (also it does contradict this "chrome users"); or more likely it will be implemented in chrome.
Now when we established that implementation in chrome is most probable - we can also establish that:
A) Implement this on profile basis - companies will ask you to reset profile if you are this false negative.
B) Implement on connection basis - companies will ask you to refresh.
C) Implement on device age / os version / type - Google can even make the manufacturers happy with this one.
… as you can see at most this will be nuisance and if by some weird way:
Z) Implement on Super-complicated basis - this will be still possible because…
3. Google plays disingenuous word game with us here by saying - We won't destroy open web
Other Chromium browsers may ignore that Google X% false negative (Google may loose few % of users before it scrapes this policy). And there is 0 need for Google to actually do something when companies will misuse this API.
In simple words the part that should worry you is not that "Google will destroy web by using this API on Chrome and it services", what must worry you is that other companies will do that for Google and Google will wash their hands from this by saying "We wanted good but didn't work". You can see that tone from the Google - We don't want that so we created these "holdouts".
They are proposing thing that any sensible person see as clear cut attack (or stupid idea that can only work this way) on Privacy and Your Right to use Your Device (and for some people Your OS and/or Your Browser) as You want to use. They are at fault here.
"anyone can become an "attester"" - and no site has to respect that.
Read between the lines - using TLS as example: I can attest that my site is my by being self-certified but no browser will accept that - as my certificate is not "attested" by browser or OS.
The WEI attester is exactly same - if site decides that it trust only Google, Apple and Microsoft - you do not have any way to access the site if you don't have attestation from that group, period.
"Opera would need to trust Linux" - Again I need to stress out to anyone who doesn't understand anything about Linux - Linux is not single uniform OS - it is bunch of distributions (OSes) that agree on some common API (not always) to produce more or less something that seems to be single OS for application (often not really) - binary compatibility is not a thing to this degree that linux has many (again no uniformity) separate solutions to make closed source binaries to work.
In reality trying to attest "that binary is not modified" on Linux is simply fallacious or outright misguided on basic idea - leaving aside distros that do not ship binaries (Gentoo) many ship often modified versions of software. And Users may modify software as they see fit - so there is literary no way that you can attest Linux.
By Anyone I didn't mean end-users. The TLS analogy stands. No browser has made the decision to trust only one authority. A motivated and funded organisation can become an Authority (like Let's Encrypt did) and the same can happen in the WEI case too. Ofcourse noone can trust self-certification. At the "trust-me-bro" game bots are more convincing than real users.
If client has to be certified, then as product OS must be certified out-of-the-box for non-technical user. This will make sure 97% of market is covered by Apple, Microsoft and Google - these are "Authorities" web will have - even if the remaining few percent would be unified - it still will lead to most often then not "not being included" as trustworthy from server side.
>The TLS analogy stands.
no it does not. TLS cares about connection not OS stack. Also power dynamic flows in opposite direction.
>Ofcourse noone can trust self-certification.
If you want you can - because You (user) can import any certificate.
The problem for me is that:
[Free/Open] Source/Linux in their entirety can be attested only if self-certification is possible. AND
Self-certification means that WEI doesn't work. AND
Any proposal that excludes any OS (or Linux distribution) from web is unacceptable.
Do you see logical outcome which this reasoning leads me to?
>No browser has made the decision to trust only one authority.
But it is not the browser here who has the final power "to trust", it is the server. And companies will only care about Windows, Mac(Safari), Android and Chrome.
>A motivated and funded organisation can become an Authority (like Let's Encrypt did)
Let's Encrypt could do that because TLS works in reverse direction and it is website that must be certified not the user.
> At the "trust-me-bro" game bots are more convincing than real users.
Yes exactly which is again everyone's point - for 10001 times and again "You cannot trust the client" - it is impossible to create privacy/[freedom of use for browsers and OS]-focused 'secure' and perfect attestation about client.
One has to give - 'security'/perfection or privacy/[freedom of use for browsers and OS].
We calculated what this proposal brings and rejected it on basis that bad is bigger than potential 'good' it can bring.
And again to put it clear - you need bots: search crawlers, web archive bots, URL scanners.
So put it clear - it is clearly from my perspective a wrong proposal.
Read the proposal: https://github.com/RupertBenWiser/Web-Environment-Integrity/...
>That's settled then. Full filesystem, location, camera, and microphone access should therefore come on by default without a permission dialog. Why not bring back Java and Flash while we're at it! It's not the browser vendor's fault that websites are misusing it.
Now who is arguing in bad faith? if you have read the proposal, it's clear that they are being careful and are upfront about the some potential misuses and the proposed handing of them.
> to verify that your system is using a Google-approved bootloader to load a Google-approved operating system which only loads Google-approved drivers and Google-approved software (or worse, website-approved software).
again there is no such thing proposed. The "attester" is not specifically Google. anyone can become an "attester". The chain of trust is a chain that trusts tokens not specific "things". if you for example would trust let's say Opera as the attester, Opera would need to trust windows or Linux or Android as the OS attester.
The analogy here is the certificate Authorities. You may very well have a "let's encrypt" attester that democratizes the good parts (certification) without the bad parts (too much information) .