Can't trust 'em.
Google employee responds to negative feedbacks on WEI
21–26 of 26 posts
Re: Google employee responds to negative feedbacks on WEI
#22Amazingly 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…
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.
Re: Google employee responds to negative feedbacks on WEI
#23Earlier quoted context omitted.
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 t…
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…
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. :)
Re: Google employee responds to negative feedbacks on WEI
#24> 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…
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.
Re: Google employee responds to negative feedbacks on WEI
#25Holdbacks 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…
> 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.
Re: Google employee responds to negative feedbacks on WEI
#26Earlier quoted context omitted.
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…
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 :)