serg...@chromium.org, pb...@chromium.org, ryan...@google.com, b...@chromium.org, erict...@chromium.org
https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md
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.
Not filed yet.
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.
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.
https://github.com/antifraudcg/proposals/issues/8
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?” 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” 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?
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
This can be sent to websites’ web servers to verify that the environment the web page is running on is trusted by the attester.
> This seems to create a large power for site owners to dictate & control user behavior.
I want to be forthright in saying that I have the same concerns. For this reason, it is an explicit goal in the explainer to "Continue to allow web browsers to browse the Web without attestation." (ref).
This is of course easier said than done. One idea is to introduce a holdback mechanism (ref) that only allows a portion of traffic to be attestable so that web developers are not able to enforce any particular request on the attestation verdicts. In the rooting example, this would ensure that a web author could not prevent you from browsing without also locking out a sizable number of potentially attestable (but held back) users.
Regarding how this addresses user needs, I think there are many legitimate reasons why users do not want fraud on the services they use. For example, fake engagement can be used to promote spam and disinformation to unsuspecting users. In other cases, real users may compete to buy concert tickets, but lose out to innumerable instances of fake users. There are a few more examples in the explainer’s introduction (ref).
Another user-facing consideration is that these same inferences are made today using highly identifiable information from the browser, and inadvertently allow for widespread tracking of users. Given the deprecation of third party cookies and other privacy efforts, we recognize an urgency to create a well-lit path for anti-fraud use cases that does not rely on widespread collection of re-identifiable signals. My north star is for these existing approaches to be dropped for a more reliable, and more private alternative.
--
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/1e2f3a79-3e73-4994-bcbd-40388e1ed64an%40chromium.org.
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 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 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.
--
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%2By7Y5ZR7m4XtNgS2RTad2z0zqp%3D5T3DZRi%2BbO_4n_4_aMg%40mail.gmail.com.
--
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/baef87c2-92ee-4175-8b04-9d229a4043b9n%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6158a8cb-1de4-4b38-9a5b-068d43dc1054n%40chromium.org.
--
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.
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.
To unsubscribe from this group and all its topics, send an email to blink-dev+unsubscribe@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.
--
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+unsubscribe@chromium.org.
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.
--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/b5f5a252-a0fc-4c37-8ae8-9a460d20373an%40chromium.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.
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-uykBNk1Vpd85sEzRXrKTroxcy5wowspF0hmSkugX4dEw_qg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BYmkXcj1eb5tbwrWNi_Y9pZ%2BcHn1CiBYZM9b8Nnpze5bWnOGQ%40mail.gmail.com.
>I have encouraged the team working on this to ignore feedback in any forum in which something like Chromium's code of conduct is not being maintained as anything else would be creating an unsafe working environment. It's somewhat ironic to me that some folks arguing passionately for the openness of the web (something I and many of the proposal contributors are also passionate about) are relying on physical threats and other forms of abuse, which of course means we must limit the engagement on this topic such that their voices are ignored completely (the antithesis of the openness they are advocating for).
I'm gonna say this as politely as I can. Google has got into hugely dominant positions with Chromium and Android. I don't think I have to explain here how much these 2 projects dominate the web and mobile spaces. They are both under Google's governance, and treated by Google as its backyard. Chromium comes up with whatever Chromium wants to implement, and can ignore everyone else. Android keeps getting moved from AOSP to Google Play Services. Nobody can stop this. Nobody can stand up against this.
This, in a direct consequence, means whatever Google does with these projects *will* be watched closely and with little trust, like a government is. If this is a problem for you, maybe suggest to the more important people to stop that. I don't know, turn them into independent non-profit projects, separate from Chrome and Google Play? Request Firefox is shipped by OEMs on some Android phones instead of Chrome? Send some bigger one-time donations for Servo and Ladybird development, with no requests made? I'm not getting paid to give you advice.
WEI is also an especial, highly flammable combo, because it touches (risks of) all of: anti-end user practices, setting Google as an authority to trust with decisions about user's faith, reinforcing user reliance on Chrome specifically and Google Play Services, fight on ad blockers, scraping, and unofficial clients. If I continue with the government analogy, Google is here an unelected official whose death would start street parties. I know, I know, this is just "an experiment", "not a goal", and actually "for privacy".
Currently, as I'm on Android, my banking apps will refuse to enable some features, Snapchat will refuse to log in, and the McDonald's app will refuse to launch if I don't get Google to sign some magic string these apps get from a server. I'm, according to the Play Integrity API documentation, supposed to not get it signed, because I have access to my own device's root user. I want to update apps from my F-Droid as easily as those from Google Play, stop traffic to some domains by editing /etc/hosts, and have a possibility to backup some of my installed apps with their data, but I guess that's too much freedom to have a McDonald's equivalent of a loyalty card. Maybe I'll self-report here now that I also have access as an Administrator to my Windows machine.
The current proposal is to extend this to the web. Apparently if I have root access on my phone, this means I must be a robot that shouldn't see the website that has ads (referring to the first example from the explainer's introduction). That's correct, I don't want to be human. Especially if my humanity is reduced to "advertisement watcher". The left-over crumbs of humanity that used to be in this body are only here to check the "I'm not a robot" boxes.
>Attacks and doxing make me personally MORE likely to support stronger safety features in chromium, as such acts increase my suspicion that there is significant intimidation from criminals who are afraid this feature will disrupt their illegal and/or unethical businesses, and I don't give in to criminals or bullies.
If wanting to see the news, watch some user-uploaded videos, or scroll some social media feed on the internet is gonna side me with criminals, then at this point maybe I should simply become one. This makes "unethical businesses" sound like they might actually be a moral choice. Torrents actually give me movies, not "The WidevineCdm plugin has crashed". The site you probably know well wants, at worst, 2,80 Euro for a thousand checked boxes, while I'd need half a minute to fill each myself. With mass use of attestation (availability on web *will* increase it on all platforms), APIs returning tokens signed by Google will only become a matter of the price per 1000, not of a fact. If the "strong safety features" mean making it annoying enough to cost 15 Euro instead of 1, while a genuine Huawei user will not be able to get any, and actual criminals already send phones to package lockers as a way of selling bank account access, then maybe this is not safety. (Just kidding. I would never do cybercrime.)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-p5%3DG7fpjWVFA_5Z2saAUWdZcfjqG1CJJ6s9yUYsHRZA%40mail.gmail.com.
I have thoughtfully and respectfully written this comment. Please review it!
But then I'm grateful that the blink-dev community remains a place where we can disagree respectfully and iterate openly and publicly on difficult and emotionally charged topics, backing us away from thinking and acting in an "us-vs-them" fashion. I also want to point out that while open to anyone, this forum is moderated for new posters. Moderators like myself approve any post which is consistent with chromium's code of conduct, regardless of the specific point of view being taken. The thoughtful comments here over the past few days have been educational and overall calming for me, thank you!
I have watched the Web Integrity API unfold from Hackernews, the GitHub repo, and now the news. I want to be part of the discussion, not be informed of decisions after-the-fact.
It's somewhat ironic to me that some folks arguing passionately for the openness of the web (something I and many of the proposal contributors are also passionate about) are relying on physical threats and other forms of abuse, which of course means we must limit the engagement on this topic such that their voices are ignored completely (the antithesis of the openness they are advocating for)
And, unfortunately, as a developer and well-meaning user, I’ve found that my avenues for giving feedback are closed. I want to share my voice and not be ignored completely. Yes, there is vitriol surrounding this topic, but it’s too important to shut out all dissenting voices. Doxxing and threats are wrong. Period. But so is silencing your community, your users, your developers, and all discussion and debate surrounding the Web Integrity API. Even the discussion here has been a bit heated with misunderstandings.
While you are say you are “looking for a better forum and will update when we have found one”, you have begun adding these changes to chromium. Again, despite wanting to treat this as an early proposal for new web standards, you are already prototyping it in Chromium! It’s a bad look, bad PR, and against your own W3C code of conduct. It’s not just that you’re ignoring or leaving feedback unaddressed, it’s that all feedback is rejected in the first place too. By the time it’s implemented, it may be too late. To quote this article about past Google actions:
But this move for greater democracy would have been more powerful and effective before Google’s unilateral push to impose Manifest V3. This story is disappointin