There's been a lot of strongly worded negative feedback for this proposal in the Github, and I don't agree with how that feedback was delivered but I do agree that this proposal if followed would not be good for the web.
The proposal talks about trust, but the server does not need to trust the client. Like palmer said, they can never trust the client, this doesn't allow them to trust the client in a way that could be considered a security boundary. That is a fundamental design choice of client-server with open user agents, in place of closed apps/walled gardens. This is an intentional property of the web. But this proposal provides a mechanism for web sites to force their ideals and preferences onto user agents, which takes away user autonomy and choice, and damages the trust held by Chromium as the dominant user agent today. Let's push the world to be more open, to give more user control, not more controlled and closed. Dana On Thursday, July 20, 2023 at 1:41:45 PM UTC-4 Reilly Grant wrote: Michaela, I think you are misunderstanding this proposal. This is not a proposal for a site to prove its integrity to the user. It is a proposal for the user agent to prove its integrity to the site, and that it is acting on behalf of a real user. These are two largely independent problems. I recommend looking at Isolated Web Apps <https://github.com/WICG/isolated-web-apps>, which attempt to solve exactly the problem you're discussing. On Thu, Jul 20, 2023 at 8:18 AM 'Michaela Merz' via blink-dev < [email protected]> wrote: Thanks @Chris Palmer for your input. Nobody is more opposed to DRM than I am. Even today I refuse to load DRM extensions into the browser. I think that DRM is wrong and the open web is the way to go. But providing provenance and integrity to a resource is not DRM. TLS is not DRM. If you hit a page with an invalid TLS certificate, you are free to continue. If the power to be would decide to NOT allow us to continue to sites without a valid TLS certificate, you'll find me on the barricades right along with you. Browsers already include a protection mechanism called "Subresource Integrity" (SIR) . If the provided resource doesn't match the hash, the browser refuses to load the resource. Together with "content security policy" we can already create hardened web resources. But we're missing one crucial element: If the web site has been modified on the server. If a malicious attempt to modify a web environment is successful right at the source, we (and our users) have no way to protect us and our users. That's why I think it is important to extend the SRI with a "master key" or certificate that can not be recreated without the knowledge of the author of the web site. We can and must discuss the details of such a mechanism of course. I am with you and don't want DRM through the back door. But I think it's crucial for the web environment's credibility to have tools that can be used to protect the integrity of the environment. m. On Thu, Jul 20, 2023 at 7:05 AM Chris Palmer <[email protected]> wrote: Speaking as a recent former Chromie who wants you to succeed: retract this proposal. * The web is *the* open, mainstream application platform. The world really, really needs it to stay that way. * Whatever goals publishers might think this serves (although it doesn't), extensions and Dev Tools (and other debuggers) neutralize it. Extensions and Dev Tools are incalculably valuable and not really negotiable. So if something has to give, it's DRM. * The document claims WEI won't directly break content blockers, accessibility aids, et c. But: (a) this will be used as part of an argument to not bring extensions to Chrome for Android; and (b) assume/realize that publishers will start rejecting clients that support extensions. Chrome for mobile platforms already doesn't support extensions, and mobile is the largest platform class. So publishers might even have a decent chance of getting away with such a restriction. * DRM will always be cracked and worked around, but that doesn't mean that implementing this will be harmless. DRM still shuts out legitimate use cases (accessibility comes foremost to mind, but not solely), even when it is broken. Everybody loses. * DRM misaligns incentives: the customer is now the adversary. This is a losing move, both from a business perspective and from a technical security engineering perspective. (Do you want an adversarial relationship with security researchers? No, you do not.) WEI enables publishers to play a losing game, not a winning one. * In ideal circumstances, WEI would be at best a marginal, probabilistic, lossy 'security' mechanism. (Defenders must always assume that any given client is perfectly 'legitimate' but 'malicious'. For example, Amazon Mechanical Turk is cheap.) Holdbacks nullify even that marginal benefit, while still not effectively stopping the lockout of particular UAs and yet not effectively upholding any IP-maximal goals. * Chromium has a lot of credibility in safety engineering circles. Don't spend it on this. On Monday, May 8, 2023 at 8:30:30 AM UTC-7 [email protected] wrote: Contact emails [email protected], [email protected], [email protected], [email protected], [email protected] Explainer https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md Specification We do not have a specification yet, however we expect to publish in the near future both the considered implementation options for the web layer in an initial spec, which we suspect are not very controversial, and an explanation of our approach for issuing tokens, which we expect will spark more public discussion, but is not directly a web platform component. We are gathering community feedback through the explainer before we actively develop the specification. TAG Review Not filed yet. Blink component Blink>Identity <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EIdentity> Summary This is a new JavaScript API that lets web developers retrieve a token to attest to the integrity of the web environment. This can be sent to websites’ web servers to verify that the environment the web page is running on is trusted by the attester. The web server can use asymmetric cryptography to verify that the token has not been tampered with. This feature relies on platform level attesters (in most cases from the operating system). This project was discussed in the W3C Anti-Fraud Community Group on April 28th, and we look forward to more conversations in W3C forums in the future. In the meantime, we welcome feedback on the explainer <https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md> . Motivation This is beneficial for anti-fraud measures. Websites commonly use fingerprinting techniques to try to verify that a real human is using a real device. We intend to introduce this feature to offer an adversarially robust and long-term sustainable anti-abuse solution while still protecting users’ privacy. Initial public proposal https://github.com/antifraudcg/proposals/issues/8 Risks Interoperability and Compatibility We are currently working on the explainer and specification and are working with the Anti-Fraud Community Group to work towards consensus across the web community. The “attester” is platform specific so this feature needs to be included on a per platform basis. We are initially targeting mobile Chrome and WebView. Ergonomics See “How can I use web environment integrity? <https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md#how-can-i-use-web-environment-integrity>” in the explainer. Note that we are actively looking for input from the anti-fraud community and may update the API shape based on this. We also expect developers to use this API through aggregated analysis of the attestation signals. Security See the “Challenges and threats to address <https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md#challenges-and-threats-to-address>” section of the explainer to see our current considerations. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? We initially support this only for Android platforms (Android, and Android WebView). This feature requires an attester backed by the target platform so it will require active integration per platform. Is this feature fully tested by web-platform-tests <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%2F%2B%2Fmaster%2Fdocs%2Ftesting%2Fweb_platform_tests.md&data=04%7C01%7CAmanda.Baker%40microsoft.com%7C84c5e8a01bc1471e348f08d7c6b940f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637196371372857279%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C-1&sdata=M79bBRPkECK4YmZwW1JAdcqHCofWo6qpz3TFFwnvqB8%3D&reserved=0> ? Web platform tests will be added as part of this work as part of the prototyping. We will then feed those tests back into the specification. Requires code in //chrome? True Feature flag (until launch) --enable-features=WebEnvironmentIntegrity Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5796524191121408 -- You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group. To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/Ux5h_kGO22g/unsubscribe . To unsubscribe from this group and all its topics, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/28a637ff-682c-4a38-b3a9-f2bfa2b48c44n%40chromium.org <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/28a637ff-682c-4a38-b3a9-f2bfa2b48c44n%40chromium.org?utm_medium=email&utm_source=footer> . -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKDb%2By7gDGdiWTKR832P7m2hH0p1VtxXqvnBxwYnAZ0AQjo4jQ%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKDb%2By7gDGdiWTKR832P7m2hH0p1VtxXqvnBxwYnAZ0AQjo4jQ%40mail.gmail.com?utm_medium=email&utm_source=footer> . -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b5f5a252-a0fc-4c37-8ae8-9a460d20373an%40chromium.org.
