Thanks Ben, I see your point about holdbacks. But all the arguments against holdbacks also apply to any user of any browser which doesn't support this API (too old, brand new, philosophical objection, etc.), right? I guess what I'd most like to understand is what exactly would the implication be for a new browser developer or someone who wants to build their own browser from source? The whole history of browsers is about new browsers cloning established ones <https://en.wikipedia.org/wiki/Timeline_of_web_browsers>. Do uses of this API seek to end that tradition or solve it in some other yet-to-be-described way?
Thanks, Rick On Wed, May 17, 2023 at 11:55 AM 'Michaela Merz' via blink-dev < blink-dev@chromium.org> wrote: > Ben: I must have read the explainer incorrectly. Yes I am proposing a an > integrity check for user agents to run against websites. > > Here are my thoughts: > > Web-environments are used to transport and process critical data. In order > to protect the integrity of the web-environment, we have mechanisms like > subresource integrity. However - none of the available mechanisms protect > the integrity of the web-environment against malicious interference when it > happens directly on the host of the pages and scripts. Additionally, > developers may be coerced to change code to circumvent certain mechanisms. > This is because the subresource hash can easily be re-calculated by anybody > with access to the source code or even removed from the calling/loading > page or element. The user(-agent) would thus be unaware of the code changes > and may provide data to a now possibly dangerous or unsafe environment. > > It is my suggestion that methods are implemented that allow user agents to > verify if the elements have been tampered with - even if it happened on the > most basic level - the hosting website itself. This could be done by > creating a "hash of hashes" from all subresource integrity hashes within > the user-agent. On subsequent visits, the user-agent would try to match the > stored "hash of hashes" with a newly calculated "hash of hashes" and warn > the user if the hashes don't match. Ideally, the warning to the user would > be clickable and lead to a well-known page which allows the website to > explain why the code has changed. The user may then choose to continue > (which will update the hash of hashes to its new value) or to stop the > usage of the site. > > Thank you for your thoughts and consideration. > > Michaela > > > > On Wed, May 17, 2023 at 8:56 AM Ben Wiser <bew...@google.com> wrote: > >> Hey Michaela, if I understand correctly, you’re proposing an integrity >> check for user agents to run against websites? Let me know if I got that >> right. It sounds like you’re proposing an integrity check in the opposite >> direction from what the explainer >> <https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md> >> is proposing: communicating user agent integrity to web servers. It sounds >> like an interesting space, but I’d recommend possibly creating an explainer >> with your thoughts as that doesn’t sound like it is in the same scope as >> Web Environment Integrity. >> >> @Rick, regarding the probabilistic vs deterministic problem in the >> explainer, I think there would be a threat regarding bad actors hiding in >> the holdback. Bad actors who would definitely report an “untrustworthy” >> signal are able to simply not report attestations from their devices. Web >> developers would be forced to treat them the same as a user agent that >> decided to holdback an attestation verdict. I think we’d effectively be >> lowering the probability of catching bad actors. We’ve already gotten >> signals >> <https://github.com/RupertBenWiser/Web-Environment-Integrity/issues/5> >> from anti-fraud providers that the value add will be smaller if holdbacks >> are provided. >> >> Having said all that, I do think there would definitely still be utility >> with web environment integrity in a world where we have holdbacks. I’m also >> a huge fan of your approach of having configurability and measuring impact >> on the web over time and think that could be a very effective way to >> progress responsibility. We are currently fleshing out some ideas for >> holdbacks and should be able to share some more ideas soon. >> On Tuesday, May 16, 2023 at 10:20:50 PM UTC+1 misc...@googlemail.com >> wrote: >> >>> I am a *big* fan pf everything that helps to protect the integrity of a >>> web/javascript environment. Not necessarily to make a site or web/app >>> unusable, but to inform the user that an evironment has changed. It is up >>> to the user to decide to continue to use it or not. To that end I am >>> proposing to be able to sign some hash (e.g. integrity hashes) with a key >>> pair or token that can be downloaded by the user during his first visit. >>> Should the hashes not match, the user will be informed and may select to >>> terminate the session. >>> >>> This would protect the complete environment against any form of change >>> or manipulation even if it is done directly on the server. >>> >>> My two cents. >>> Michaela >>> >>> >>> On Monday, May 8, 2023 at 9:30:30 AM UTC-6 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 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%2By7Y5ZR7m4XtNgS2RTad2z0zqp%3D5T3DZRi%2BbO_4n_4_aMg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKDb%2By7Y5ZR7m4XtNgS2RTad2z0zqp%3D5T3DZRi%2BbO_4n_4_aMg%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/CAFUtAY_f-wguq5Own%2BDcyS_2bcK9eeNZKxtPB7b0OzBU5GJaFg%40mail.gmail.com.
