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/...
What prevents a website from using invasive fingerprinting _AND_ WEI together? I strongly suspect websites will end up using both WEI and invasive fingerprinting because:
1. Websites will want to use invasive fingerprinting on old browsers and it would work within browsers that deliberately don't implement WEI.
2. Websites will want to get as much invasive fingerprinting information as they can get their hands on.
3. It is another layer of fingerprinting in the likely event that WEI is ineffective due to TPM exploits[1], operating system/driver exploits, web browser exploits, determined actors using rooms of computer display recording devices and robotic arm mouse movers, etc. Invasive fingerprinting further increases the cost and complexity to actors the website is trying to block.
> This is not DRM - WEI does not lock down content
It is absolutely 100% DRM. Your proposal states that devices would need to attest their configuration to the website. The website can then block the user because it doesn't want to show the news article to a Linux device where the user can block annoying pop-up ad videos, copy and paste the text or save the web page. The website can instead only allow devices which are factory-configured to block copy+paste, block saving web pages, block screenshots, etc. It's still DRM even with the proposed holdback mechanism because in the best case, a user will still be blocked 9/10 times (or whatever the holdback mechanism is set to). The more likely scenario is a website owner will just refuse to serve content until the client has attested itself. "The requested page can not be provided due to an unexpected problem. Try again in a few minutes."
There are so many flaws with the scheme as currently proposed I feel I could write for days:
Will websites be expected to block and ban users of AMD-SP now that it is broken[1]? Or will whoever conducts ad fraud just buy all the AMD-SP devices they can get their hands on?
As another author replied, are Gentoo users that compile their web browsers and operating systems from scratch just ignored, and the proposal pretends it won't impact these users?
How does the proposal allow users with specialist accessibility software to browse the web without being blocked for being a minority group that is not economically worth website owner's time to support? What prevents abuse of said specialist accessibility software for other purposes?
How would a new start-up developing a competing browser or phone from scratch, and are very much unknown and in a minority position, be able to convince millions of website owners to unblock/allow their new browser or phone? Cloudflare's Friendly Bots program refuses to respond to open source projects, so why would Cloudflare as an implementer of WEI care about new start-ups or small open source software projects?