I'd do the same thing if I was working for the devil and I knew it.
Privacy features like user-agent reduction, IP reduction, preventing cross- site storage, and fingerprint randomization make it more difficult to distinguish or reidentify individual clients, which is great for privacy, but makes fighting fraud more difficult. This matters to users because making the web more private without providing new APIs to developers could lead to websites adding more:
- sign-in gates to access basic content
- invasive user fingerprinting, which is less transparent to users and more difficult to control
- excessive challenges (SMS verification, captchas)
My question is whether there is any data to back up those claims.
And even if it stays as described, the percentage will be low enough that those that fail attestation can be safely barraged with captchas or simply told to go away. (You can try browsing the web with TOR to get a taste of how you will be treated)
The whole post can be summarized as "trust me bro"
This is precisely what the reported issues are trying to achieve, regardless of their tone. The current path is completely wrong and reckless. The first step of working together would be to abandon this approach entirely.
This is akin to suggesting that we'd solve global warming by triggering a nuclear winter. This is not something you can solve by iterating and finding a middle path. The entire premise of this proposal is dangerous and should be binned.
Just think about all the potential ways in which this approach can (and obviously would) be abused.
(Posting this here as I just noticed they disallowed commenting)
I'm curious what "better forum," if any, Google will actually engage with on this matter. I too wouldn't this sort of overwhelming reaction to happen in a personal repository. But the conversation needs to happen somewhere!
> 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
After the weekend - leaves long comment but doesn't reopen comments as promised.
It focuses heavily on privacy concerns and how those will be resolved - the vast majority of criticism I've seen hasn't been related to this at all, and those aren't especially hard problems to solve in the context of the existing spec.
It still largely ignores browser diversity & experience this will create for non-Chrome users. His argument is that blocking fingerprinting in future will mean anti-fraud will make the web unusable, and WEI will make it usable again. Given you accept the premise, still the conclusion is only true for browsers that can access WEI - which means the web will become unusable for browsers who can't (Linux, rooted Android, Firefox, etc etc).
For the ecosystem as a whole, it's better if everybody has a fair playing field. By definition, WEI structurally privileges certain clients. The more widespread that becomes the worse the effect on the wider ecosystem is. If WEI does not exist, and fingerprinting does not exist, providers will be forced to find ways to limit the impact of anti-fraud mechanisms. If 90%+ of browsers use attestation, that pressure decreases dramatically. Using Tor on the web today is a good example of the likely experience.
The mention of holdbacks here touches on this (though for full blocks, rather than wider impact) but ignores the existing strong pushback against holdbacks from others closely involved in the spec & discussion around this (https://github.com/RupertBenWiser/Web-Environment-Integrity/...) and ignores that the attestation they already shipped on Android for exactly the same use case does _not_ do this.
Fundamentally, the issue isn't about privacy during these checks, or whether defeating fraud without fingerprinting is valuable. Those are reasonable but obvious points. The issue is that client-focused validation for fraud is a flawed goal in itself (it's impossible - even with full & perfect attestation, you can set up a fully automated + WEI-approved machine by automating input peripherals directly) that risks enormous collateral damage, and we shouldn't encourage it in any sense. We definitely shouldn't standardize practices to make it easier.
At the end of the day, if you want to block fraud you have to do so server side (statistical analysis, rate limits, validated user accounts, requiring payments, some kind of proof of work, etc). This is a hard problem, absolutely, but it's unavoidable.
How else are they going to learn more about me and shove ads that they think I care about?
> An owner of this repository has limited the ability to comment
"There seems to be something wrong with your request, try reloading this page"
Good luck getting this ad infinitum you are on an environment that Google doesn't approve.
I very much doubt author himself believes that.