I'd like to add something I haven't seen discussed yet. I've looked at the RFC here: https://rupertbenwiser.github.io/Web-Environment-Integrity/. I looked at the example, and my first impression was: wow, this is worthless. This seems to introduce some sort of device/browser/session identifier (might say hello to GDPR), which basically turns this into browser fingerprinting (how convenient coming from google, and ironic with section 1.1), but more importantly: it's just an added useless identifier.
This also poses a certain number of problems: - Either you won't be able to use any extension, or the proposal is rendered useless by the fact that extensions can have access to this API - Since the browser and server are two very distincts environment, there's no way for the server to validate anything besides anything that wouldn't be redundant after the TLS handshake - Lastly, this is an IDENTIFICATION method, not an AUTHENTICATION method - Full chain integrity checks requires non legal methods to inspect other people's machines' current state (memory, disk, etc...) This feels like a traditional google move to drive away extension users and developers (we know which ones they especially don't like), or for pushing for a DRM-ization of the web. Both are obvious no-nos. As is, and after reading it, the RFC doesn't make any attempt at explaining how to use said tokens, what problems they solve and how. It also doesn't And also, section 6.2 title "Privacy concerns" being currently "TODO" is both extremely funny and worrying, but could also indicate the true motives. If they care about security, why is this section one of the only TODOs? It also reminds me of that one infamous talk that features the now very infamous line: "We'll leave the morality aspects to the side". Sincerely, A deeply concerned Engineer Le samedi 22 juillet 2023 à 19:26:05 UTC+2, Alex Russell a écrit : > Hey folks, > > I think it's worth lowering the temperature here a bit, so to Chris' > point, we probably need to re-evaluate some of the choices in this design, > and signpost any redesign or iteration quickly. But backing up a bit, it > would be extremely helpful for y'all to reach out to the TAG ASAP; this is > a complex space with lots of tradeoffs, and you'll want their guidance. The > "spelling" of this API is good (CBOR, Promises, an API on `navigator`, > etc.), but the intent and ecosystem choices will need a lot attention. > > As for the Explainer, there are things that I'd expect to see improved > before anything could move forward, including (but not limited to): > > - More focus on specific use-cases. There are several listed, but > they're high-level, and aren't met with example code that explains how > this > design will address those specific needs. For example, a sample use-case > like "d*etect social media manipulation and fake engagement*" needs a > conversation later in the document about: > - The extent to which such an API can actually perform that role. And > is that something this design will take on? Or leave to passthrough > underpinnings? What are the risks there? And how can developers know > about > about them without making unwise assumptions? > - Alternatives and complementary technologies sites might use today > (fingerprinting is mentioned in passing, but not in detail, and forcing > users into native apps isn't brought up). > - Sample code to that shows how the problem is addressed using > features this API provides. > - A conversation in the design around if (or how much) this delegates > to OS or platform-specific attestation. My quick read of the spec suggests > that this is, roughly, a passthrough to lower-level APIs that have their > own constraints, and that making them web-aware is a non-goal (presumably > in the interest of broadest reach). Those tradeoffs deserve a discussion > in > the doc, as do alternatives to this approach. If the plan *isn't* to > passthrough directly to system attesters, that probably needs to be called > out more visibly. > - Interop risks. Can this be plausibly implemented by other vendors > and engines in a fully interoperable way? > - The ways that a passthrough risks further entrenching a duopoly in > mobile computing. E.g., if this API is wildly successful and heavily used, > and requires that the `contentBinding` use pre-arranged, OS-level > side-agreements, what does that do to the ecosystem? Does it make things > harder for new OS vendors? For AOSP users? > - User consent. I know we don't put UI in our specs > <https://infrequently.org/2020/07/why-ui-isnt-specified/>, but if the > async nature of the API is designed to enable user control of this sort of > capability, it isn't obvious from the design sketch. Likewise, I'd expect > to see integration with the Permissions API (and Feature Policy > delegation) > as part of the design if user control or consent are goals. This also > shades into a conversation about <iframe>s and delegation, which also > needs > a look. > > The intro suggests massive-scale use as a success state, with a majority > of transactional, social, and gaming use-cases (at least by volume) as > users. This suggests an *extremely* high bar. > > I'll fight to the hilt to maintain the space for y'all to iterate on > addressing these problems, and a good first step might be to restate them > in a user-focused way that takes on individual use-cases end-to-end, > showing your work as you go, including the way this will (likely) interact > with other systems that are roughly hewn in this draft. > > Best, > > Alex > > On Thursday, July 20, 2023 at 10:41:45 AM UTC-7 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+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/c99f59c6-86ef-49f4-a1fc-cd4355c333efn%40chromium.org.
