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 < blink-dev@chromium.org> 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 <pal...@chromium.org> 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 bew...@google.com wrote: >> >>> Contact emails >>> >>> serge...@chromium.org, pb...@chromium.org, ryanka...@google.com, >>> b...@chromium.org, erictrou...@chromium.org >>> 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 >> blink-dev+unsubscr...@chromium.org. >> 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 blink-dev+unsubscr...@chromium.org. > 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMYNThJ7nDMWUCkuesYs-Eq02jm%2B2MvxkBe0s3u%2BmD%2BOCQ%40mail.gmail.com.
