Google employee responds to negative feedbacks on WEI
github.comDirect link to comment: https://github.com/RupertBenWiser/Web-Environment-Integrity/...
Holdbacks are an insufficient solution; there is a fundamental conflict in the specification's goals surrounding lock-in.
The overall goal for the spec is described in the comment:
> The WEI experiment is part of a larger goal to keep the web safe and open while discouraging cross-site tracking and lessening the reliance on fingerprinting for combating fraud and abuse. Fraud detection and mitigation techniques often rely heavily on analyzing unique client behavior over time for anomalies, which involves large collection of client data from both human users and suspected automated clients.
In other words, the intended goal of this spec is to discourage the development and use of fingerprinting techniques, login screens, and other invasive user-validation techniques on websites.
However, the goal of holdbacks is then described in the following way:
> This is designed to prevent WEI from becoming “DRM for the web”. Any sites that attempted to restrict browser access based on WEI signals alone would have also restricted access to a significant enough proportion of attestable devices to disincentivize this behavior. [...] The hold-back and the lack of browser identification in the response provides cover to browsers that spoof their user agents that might otherwise be treated differently by sites. This also includes custom forks of Chromium that web developers create.
In other words, one of the goals for the holdback system is to make it practically impossible for a website not to have fallback mechanisms for validating user trust when encountering requests that don't have attestation. And a essential part of that design is that even implementing browsers like Chrome will refuse to verify the environment integrity 10-15% of the time.
----
So why is this a problem? Because holdbacks are on-purposed designed to make it so that fallback mechanisms have to exist and that sites can't skip including them; but the whole point of this spec as stated is to discourage developers from building those same fallbacks they're required to include because the fallbacks violate privacy or are are invasive or are essentially login walls.
And 10-15% of the time even users in participating browsers will be subjected to those fallback strategies. So you're still basically guaranteed to have your device fingerprinted, and any site that uses login as a backup verification method still will require you to make an account.
The only thing that this would affect is the frequency of user-annoyances in front of websites -- essentially, if sites started using this as a substitute for captchas, this would encourage them to drastically increase the number of captchas they use since Chrome browsers would only see 10-15% of those captchas.
And that's also a problem if you're trying to guarantee that competing browsers won't be affected, because "your users see 9x as many captchas on every website" is a pretty stinking big competitive moat.
Forgive me for thinking that "you can build a browser that competes with us, but unless we specifically approve of your browser, anyone who uses it on Android will be solving captchas over and over at a massively increased rate until they eventually give up and move back to Chrome like a good little consumer" still kind of has a lot antitrust implications.
----
This proposal doesn't make sense; assuming the best of the authors I can only assume they haven't really thought through what they're trying to build. But you can not build an attestation method that simultaneously improves the web substantially for your own users over non-attestation methods, but that also magically does not hurt the web for any of your competitors who don't get those improvements.
And holdbacks only make those goals even more contradictory: because privacy, paywalls, and logins will still affect Chrome if it decides randomly that it's not going to attest to the NYT for the duration of today. The only aspect that this makes sense for is specifically user annoyances; and where annoyances are concerned an attestation method that excludes most mainstream users on unmodified devices from annoyances while leaving niche browsers out is an invitation for websites to discriminate against those browsers -- holdbacks change nothing about that situation.
You can't tell me this is about discouraging fingerprinting in the same comment that you tell me that you're going to guarantee that sites will still need to build fingerprinting solutions and will still need to use those solutions even on participating browsers.
> This proposal doesn't make sense; assuming the best of the authors I can only assume they haven't really thought through what they're trying to build.
This is my conclusion too.
Regarding alternative browsers, the "explainer" says that all browsers on a platform would be able to be attested. But this doesn't really matter, because support for arbitrary browser extensions nullifies all the trust requirements identified at the start of the document.
In other words, the moment a browser hits the Play store which both supports WEI and allows arbitrary extensions, sites relying on WEI will start ignoring it if it's sent from browsers other than Chrome.
Amazingly clever that they have hold backs! Make sure to read this before going along with the anti WEI train
> WEI prevents ecosystem lock-in through hold-backs
> We had proposed a hold-back to prevent lock-in at the platform level. Essentially, some percentage of the time, say 5% or 10%, the WEI attestation would intentionally be omitted, and would look the same as if the user opted-out of WEI or the device is not supported.
So this avoids the DRM or blocking certain browsers issue. Brilliant. I’m not entirely certain but I think this avoids the main issues which people had with the proposal.
I still think a lot of people will not read this and react with vitriol but I would like to expect more from hacker news, as a forum where people don’t simply downvote opinions they disagree with.
The existence of a configuration that limits attestation to a probabilistic phenomenon seems like a very thin foundation to stand on here - if it can be changed to requiring 100% attestation rate in the future I think it will be changed as soon as it is feasible to do so.
I haven't reviewed the proposal enough to see how they implemented that, and if it was done in a cryptographic way that prevents changing to 100%, then that could work. But the fact remains that control of our browsing computing environment is diminishing under this proposal.
It seems to me that “if it can be changed to 100% attestation rate in the future, it will be done” is a slippery slope argument and assuming bad faith on behalf of the proposal writer.
I think if it were changed to be 100% then it would be problematic. Also it seems the proposal writer would also agree that some form of opt out is required to make it viable so as to not forbid unknown clients.
I think its important to stay away from considering potential “what ifs” that completely defy the intent of the spec. For an example of why this isn’t effective discourse, we could have a potential addition to the spec to explicitly block users from certain countries. That’s not great but also its easy to understand why its not worth debating that point (even though it does sound scary).
If you had said that 5 years ago, I would have believed you, but the latest trend of megacorporations and billionaires moving against the interests of their users and ignoring their complaints has changed my stance on that.
Google is a big dog and will not care about our yapping. If it's allowed to do as it will without consequence then it will do so, and there is nothing that individuals can do to stop it other than to cease using their products.
Sometimes slippery slopes are real.
Part of the job of web specification development is to determine what potential bad actors could do in the future. If a spec was proposed that easily allowed blocking users from certain countries, I would want that listed in the potential risks. Mitigations and technical requirements are introduced into specs all the time that only exist to stop a potential future attack.
I don't understand how a probabilistic holdbacks can be effective if you can requests for the attestation token multiple times. If the holdback percentage is 10%, the probability of getting no attestation for 10 calls in a row would be something like 0.1^10 = 1e-10. This seems trivial to implement and use to block users.
Granted, I don't fully understand how they intend to holdback, but even if they cache the results of the attestation such that 10 calls in a row fails to attest, they can't cache it infinitely. Website can employ traditional fingerprinting techniques/cookies in combination with attestation to build pretty foolproof systems to not serve the user based on attestation results.
This too. Maybe Google is willing to say something like "okay, for the duration of today, no WEI for you"; but unless they're doing something a lot more clever than the spec suggests, the "fallback" could very well be "retry the request until it succeeds and sends an attestation token."
Google would need to make holdbacks persistent enough that you couldn't retry them and get a different result. Even if they do, there are other problems, but... I mean, randomly failing requests is definitely not enough to guarantee that attestation would be optional. And there are no details I see in the spec that suggest to me that Google is planning to do something different.
How would you even differentiate between retries? If you isolate it by domain, the website can redirect you 10 times, each collecting an attestation token. They could perform statistical analysis with cookies. Websites could even force logged in users to conform to a particular browser (banking apps already do this). It's difficult for me to understand how the authors can miss these implications. They even said that with holdbacks the websites can still perform statistical analysis. Statistical analysis is not just a tool for aggregate data. It can be applied to a single client with enough other identifiers.
The "explainer" does actually address this, by talking about "a small percentage of (client, site) pairs". In other words, a particular browser, going to a particular site, will always and forever either enable holdback or not.
So, no, you couldn't continually request attestation from the one site. Instead, you could create 20 separate top-sites and load them all in tiny iframes. :)
Even if requests to separate domains didn't work, a 5% user loss is likely something that many websites can afford to ignore.
Remember that Firefox has at least a 3% marketshare. Safari has somewhere in the neighborhood of 20%. If websites are willing to go Chrome-only in that environment, permanent holdbacks won't change anything for those websites.
Particularly not if the solution to those holdbacks is "reinstall your browser and the holdback will probably go away." Which... they'd need to be unless Chrome starts tracking users to figure out who should have what holdbacks :)
The only way that holdbacks matter is if they affect 100% of Chrome users -- ie every single one of your customers/readers will at some point not send you attestation at some point for your website. And even then... telling them to refresh the page becomes a problem.
But it it's only a subset of users, then just banning 5% of users (especially from ad-supported platforms) seems perfectly feasible for a company and would probably be a preferred solution for some of them.
----
User: "Hey, for some reason when I browse Reddit nothing loads."
Support: "Yeah, very rarely a new Chrome install will do that. If you create an account and sign in, and then you send us some verification documents like an ID so we know you're not a scammer, then you'll still be able to browse. Otherwise just reinstall Chrome."
User: "Is there anything else I can do?"
Support: "No, we have to protect our ad integrity. If reinstalling the browser doesn't help, contact Google about it."
----
> Instead, you could create 20 separate top-sites and load them all in tiny iframes. :)
This too :)
The "explainer" is either incoherent here, or at least fails to acknowledge that by implementing holdback they don't solve the client trust issues they outline at the beginning. For example, one of the goals is to prevent cheating in games. With holdback, by design, the game would not be able to distinguish between a cheater who has opted out, and a non-cheater for whom holdback is active. The same applies to other trust scenarios, such as banking, in which the 'malicious software' could simply opt out. You can't just deny 5-10% of users access to your site, so there is no option but to enforce captchas, fingerprinting, or logins on those users.
In other words, developers of web apps who want to know certain difficult-to-fake facts about a client's browser would not be able to rely on WEI with holdback (by design) and would be obliged to implement all the same invasive techniques they perform now -- but now just to apply them to 5-10% of users. So it doesn't save developers any time. Does it help users? It doesn't seem like it, for two reasons. Firstly, while it's nice to know that there's only a 1 in 20 chance that my browser will be fingerprinted on a given site, that means that if I browse for any reasonable length of time and visit enough sites I will certainly be fingerprinted, and my information shared with whatever ad networks the site is using. Secondly, if developers are going to implement browser fingerprinting anyway, why not just apply it to everyone as an extra signal? Sites don't take heat for fingerprinting users now, why would they care?
In summary, the holdback idea seems to be at odds with the rest of the proposal, and the only reason it sounds attractive is because it nullifies the whole thing.
I've commented in more detail elsewhere (https://news.ycombinator.com/item?id=36885174) but I don't understand how holdbacks solve anything about this issue; if anything they make me more skeptical of Google's motivations.
The TLDR is that I don't see how I'm supposed to believe that this discourages sites from using invasive fingerprinting techniques if those sites are essentially required by holdbacks to still have those invasive fingerprinting techniques at the ready: and 1 in 10 requests even from a browser that implements WEI will still be subjected to those fallback techniques, so your browser/device is still basically guaranteed to be fingerprinted by any site you visit regularly.
You can't discourage the development of something and require it at the same time.
And if the experience of non-participating browsers is so much worse that it's obviously better to implement WEI, then we're right back to the same DRM and competition questions that we had before.
If holdbacks are rare enough that sites can ignore them (or statistically filter them out and determine if a browser actually implements the spec), then those sites don't need to have a fallback mechanism and we're right back to DRM. However, if holdbacks are common enough that sites can't ignore them (and if they can't statistically determine whether or not holdbacks are holdbacks or a non-implementing browser), then everyone is still going to be subjected to the fallback techniques that Google says it's trying to discourage.
See the original note: It was much more of a "maybe we could do this, but it has a lot of problems": https://github.com/RupertBenWiser/Web-Environment-Integrity/...
Including the text since it’s pretty illuminating:
>Holdback
>To protect against both risks, we are evaluating whether attestation signals must sometimes be held back for a meaningful number of requests over a significant amount of time (in other words, on a small percentage of (client, site) pairs, platforms would simulate clients that do not support this capability). Such a holdback would encourage web developers to use these signals for aggregate analysis and opportunistic reduction of friction, as opposed to a quasi-allowlist: A holdback would effectively prevent the attestation from being used for gating feature access in real time, because otherwise the website risks users in the holdback population being rejected.
>Although a holdback would prevent the attestation signal from being used for per-request enforcement decisions, there remains immense value for measurement in aggregate populations.
>However, a holdback also has significant drawbacks. In our use cases and capabilities survey, we have identified a number of critical use cases for deterministic platform integrity attestation. These use cases currently rely on client fingerprinting. A deterministic but limited-entropy attestation would obviate the need for invasive fingerprinting here, and has the potential to usher in more privacy-positive practices in the long-term.
>We ask for feedback from the community group on the idea of a holdback, and are very interested in alternative suggestions that would allow both goals to be met.
To me this is very clearly stating there needs to be some mechanism that forces website developers to not block access based on the results at attestation so as to allow clients to opt out. I’m not seeing the “maybe we could this,” interpretation, instead I’m seeing “we need to do something to allow client opt out, here’s one such way (with issues)”
> We had proposed a hold-back to prevent lock-in at the platform level. Essentially, some percentage of the time, say 5% or 10%, the WEI attestation would intentionally be omitted, and would look the same as if the user opted-out of WEI or the device is not supported.
So, does that mean that sites would need to fallback to existing practices for these users (or for custom forks)? So, these users get the worse ux and that's considered "supporting custom browsers"? Now sites can spend less time and resources on detection, but wait...what about the 5-10%? So IT departments will be less likely to spend precious dev time and funding on improving detection due the overall risk reduction. I'm not sure that's a net win.
Seems like it. Also that everyone will eventually end up fingerprinted if they browse for long enough, because the holdback is randomly enabled on a per-(client,site) basis.
Quoting this[1] commit comment:
[1] https://github.com/chromium/chromium/commit/6f47a22906b28994...US: https://www.ftc.gov/enforcement/report-antitrust-violation antitrust@ftc.gov EU: https://competition-policy.ec.europa.eu/antitrust/contact_en comp-greffe-antitrust@ec.europa.eu UK: https://www.gov.uk/guidance/tell-the-cma-about-a-competition-or-market-problem general.enquiries@cma.gov.uk India: https://www.cci.gov.in/antitrust/ https://www.cci.gov.in/filing/atd
> WEI’s goal is to make the web more private and safe
Yeah, hopefully you can sleep better telling yourself that.
> An owner of this repository has limited the ability to comment to users that have contributed to this repository in the past.
Fucking joke.
I think the actual comment is this one? https://github.com/RupertBenWiser/Web-Environment-Integrity/...
On my phone this is collapsed and hard to find by default.
That one is 5 days old. The one being referenced is https://github.com/RupertBenWiser/Web-Environment-Integrity/...
Can't trust 'em.