First, thank you for providing this moderated forum -- I appreciate the work folks are doing to keep this important discussion going.
I suggest we update the explainer and proposal to describe, right at the top, that the proposal is on hold. Such a statement, especially if it refers to "not meeting the bar for Chromium's values", might restore some lost trust and reduce the hostility your team is facing. I suggest that future variations on this proposal consider risks to users from website operators. Website operators could choose to intentionally harm the ability of some of their users to browse the Web by maliciously reporting them to attesters as spambots. This risk scales with the size of the website operator; for example, imagine a large country that owns many Web properties targeting a dissident, or members of an opposition party. Future proposals would benefit from reviewing pitfalls in the history of consumer credit reporting agencies, because attestation providers have many risks of abuse in common. They estimate and attest to reputations, using reports they receive along with observations they make about how their own services are accessed. --Adam B. Norberg On Friday, July 28, 2023 at 12:09:04 PM UTC-7 Rick Byers wrote: > As one of the API owners and chromium community leaders, I'd just like to > chime in on this personally with a meta-point: > > Thank you all for the thoughtful and constructive debate in this forum. As > I'm sure you know, this topic has gotten a lot of disrespectful, abusive > and overly-simplified criticism in other public forums which IMHO has made > it hard to get any useful signal from the noise there. I have encouraged > the team working on this to ignore feedback in any forum in which something > like Chromium's code of conduct > <https://chromium.googlesource.com/chromium/src/+/HEAD/CODE_OF_CONDUCT.md#:~:text=Be%20respectful%20and%20constructive.,condescension%2C%20whether%20blatant%20or%20subtle.> > > 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). 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. > > 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 > <https://chromium.googlesource.com/chromium/src/+/HEAD/CODE_OF_CONDUCT.md>, > 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! > > This community and moderation practices represents the sort of balance > between openness and safety which I believe the WEI proposal authors are > striving for. At the same time, I believe it's clear to many of us that the > tradeoffs being struck by the current proposal do not yet meet the minimum > bar necessary to uphold chromium's values > <https://www.chromium.org/blink/guidelines/values/>. That's OK - that's > the whole point of designing in the open and having public debate is to > find reasonable compromises between stakeholders with very different > perspectives, and creating a safe place to experiment (as we expect most > experiments to fail!). In order to start even an origin trial in Chrome, > this proposal would need approval from API owners like myself, and the > current state of the proposal is not something I'd personally approve due > to many of the concerns being raised. At the same time I do think there's > an urgent opportunity for chromium to do more to help with the problem of > inauthentic traffic, and (like everything we do) some amount of > experimentation seems essential to that. I believe the team working on this > proposal is taking some time to regroup (and recover from all the stress) > and rethink at least the framing, if not some of the core design properties > of this feature. I'm sure we'll get an update from them when they feel > ready and sufficiently recovered to engage in public again. In the interim, > please keep the constructive and respectful criticism coming. Bonus points > if you also have suggestions or data on how to actually make meaningful > progress on the problem of inauthentic traffic in a way that's fully > consistent with the openness of the web :-). > > Cheers, and I hope you all have a stress-free weekend, > Rick > > On Fri, Jul 28, 2023 at 11:48 AM Justin Schuh <jsc...@chromium.org> wrote: > >> Hopefully I'm not adding to the noise, but I wanted to call out a few >> things as an independent observer with some background in the problem >> space. (My comments are beyond the process and structure things, which Alex >> already addressed.) >> >> First, I suggest that anyone commenting on this explainer as currently >> written should also read the initial public proposal linked in Ben's >> email <https://github.com/antifraudcg/proposals/issues/8>, which gives >> more context on the problem space. To use the terminology from that >> discussion, this proposal is about detecting/blocking IVT (invalid >> traffic), which encompasses things like fraud, spam, coordinated >> disinformation, etc. that originate from inauthentic users (e.g. bots, >> farms). Site operators have historically relied on fingerprinting and other >> tracking signals to identify IVT, but as browser makers eliminate >> fingerprinting/tracking surfaces, site operators need privacy preserving >> ways to detect/block IVT. >> >> That context sort of comes across from the explainer and linked >> resources, but IMHO it really needs to lead with plainly stating this. >> Because the CG discussions show broad consensus on the nature of the >> problem and the importance of addressing it, but the explainer is written >> in a way that largely assumes understanding of all the context (which is >> clearly not the case). >> >> The next big thing that jumps out at me is that the only solution even >> considered for IVT seems to involve wrapping device attestation APIs (e.g. >> Android Safety Net and iOS App Attest). This is a common enough approach >> for native apps dealing with IVT (it basically repurposes a DRM mechanism, >> with all the baggage that entails). However, it also seems to ignore the >> fundamentally different privacy and security considerations of the Web >> platform. Most concerningly, it tightly couples user authenticity to device >> integrity. I have my doubts that this is necessary, and I think most of the >> concerns arise from conflating these two concepts. >> >> My recollection is that there was a lot of work done with PrivacyPass >> <https://privacypass.github.io/> to explicitly decouple user >> authenticity from other ambient state. I also see from the CG discussions >> that PrivacyPass was not considered adequate for addressing IVT. If I were >> in a position of assessing this proposal, I know that I'd need more detail >> in the explainer on specifically how PrivacyPass was lacking, and why a >> narrower extension of the protocol is insufficient. >> >> I also see questions about holdback, but I feel like that's a bit >> backwards. I appreciate the need to detect ever evolving adversaries, but >> IVT is a problem that happens at scale. So, if more signals are needed to >> stay ahead of the threats, then a conservative sampling rate should be more >> than adequate to detect new patterns and identify coincident signals. >> Something like that could mitigate many of the concerns around sites >> misusing this sort of thing. >> >> Perhaps these sorts of discussions took place in the CG and I just didn't >> find them. But it certainly isn't captured in the explainer, and the CG >> discussion read to me like everyone started with the assumption that the >> solution was to just wrap the Android/iOS native approach. >> >> >> >> P.S. This may be total bikeshedding, but I really don't like the term >> IVT, since invalid traffic is too broad of a concept. The problem space >> here is concerned with inauthentic traffic at scale, so I'd suggest zeroing >> in a term that better conveys that reality. >> >> >> On Tue, Jul 25, 2023 at 7:32 AM Dominic Farolino <d...@chromium.org> >> wrote: >> >>> At the very least, an explicit commitment to a holdback would seem to >>> quell *some* of the concerns about this feature. But one thing I'm >>> concerned about is if there'd be a difference in holdback between Chrome >>> and WebView. Since WebView isn't always considered a "real browser" I could >>> see this as an opening to try and not implement holdbacks on WebView. I'm >>> not sure how API OWNERs would evaluate that, but the risks there seem >>> pretty interesting, as I imagine it'd force some sites to aggressively >>> UA-sniff to determine whether they're in a WebView and can interpret the >>> absence of attestation as a perfect signal, vs. a possible holdback user in >>> a browser where lack of attestation is "OK". Having the adoption of an API >>> hinge on that kind of ugly practice seems unfortunate. >>> >>> On Mon, Jul 24, 2023 at 12:10 PM Yoav Weiss <yoav...@chromium.org> >>> wrote: >>> >>>> /* 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+...@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+...@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 >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfW0ztZ-R%2BA995PSVB6vh7tzszw8%2B%2BxE-6%2Bfnt_CLmHN%3DQ%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+...@chromium.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 >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-uykBNk1Vpd85sEzRXrKTroxcy5wowspF0hmSkugX4dEw_qg%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+...@chromium.org. >> > 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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BYmkXcj1eb5tbwrWNi_Y9pZ%2BcHn1CiBYZM9b8Nnpze5bWnOGQ%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/04eed145-f4b7-48cf-bd8b-9f66cd693917n%40chromium.org.
