/* with my API OWNER hat on */ Examining this proposed change, it seems to me that the most risky part in the signed attestation information <https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md#what-information-is-in-the-signed-attestation> is the part about "application identity". Providing that information to the server seems to go against our past efforts to GREASE UA-CH <https://wicg.github.io/ua-client-hints/#grease> and will prevent Chromium browsers from identifying themselves as Chrome, something they are (unfortunately) often required to do for compatibility reasons.
On Mon, Jul 24, 2023 at 1:02 AM Dana Jansens <dan...@orodu.net> wrote: > 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 < > blin...@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 > > serg...@chromium.org, pb...@chromium.org, ryan...@google.com, > b...@chromium.org, erict...@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+...@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+...@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/b5f5a252-a0fc-4c37-8ae8-9a460d20373an%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b5f5a252-a0fc-4c37-8ae8-9a460d20373an%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/CAL5BFfW0ztZ-R%2BA995PSVB6vh7tzszw8%2B%2BxE-6%2Bfnt_CLmHN%3DQ%40mail.gmail.com.
