Intent to Prototype: Web environment integrity API

[Ben Wiser]

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

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.

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?” 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

https://chromestatus.com/feature/5796524191121408

[Ben Wiser]

The contact email b...@chromium.org was added in error. That should be bew...@chromium.org.

[Morgaine (de la faye)]

This can be sent to websites’ web servers to verify that the environment the web page is running on is trusted by the attester.

I'm not sure how RFC 8890 compliant this proposal is. This seems to create a large power for site owners to dictate & control user behavior. But RFC 8890 says that The Internet Is For End Users. This seems to work against that.

From the explainer:

> For example, this API will show that a user is operating a web client on a secure Android device.

As a user with a rooted phone, it would be highly upsetting & disturb my ability to use the web if you were to create this feature & allow me, a legitimate user, to be locked out of pieces of the web. Trying to narrow down the computing world to only run on attested hardware is the definition of the War Against General Purpose Computing, and it much discussed in intelligent circles as the worst possible dystopian hell that can be brought against users. I hope this feature is abandoned, and if not, I hope it is quickly & readily subverted. This is an indignity to introduce against users.

[Ben Wiser]

> 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.

[Rick Byers]

I've also been worried about this space as there seems to be a fundamental tradeoff with no win-win solutions. As with other debates around tradeoffs with privacy, I think it would be naive to think that we can know the ideal balance ahead of time, or that it won't need to change over time. Anything we might decide would ultimately be influenced by the larger  societal debate around privacy (regulations etc.) since perfect privacy means perfect immunity for criminals. Perhaps then a productive line of discussion for this forum is what is the apparatus that we should try to design into chromium and our processes to enable the balance to be effectively tuned over time? Such an apparatus would include both the output metrics (eg. theoretically perfect measures of fraud rates, rates of legit users being locked out) and the knobs we can tune to adjust the balance between the output metrics.

The chromium project has a history of tackling some seemingly previously intractable tradeoffs with apparatus like this. For example, we designed origin trials to let us tune the balance between efficiency and velocity of evolving the web platform with the risk of "excluding vendors" (sites working only in Chrome). We used knobs like how long do we allow a feature to be in an OT state for and what are the page usage limits to try to prevent a repeat of "vendor prefix" hell web developers faced and I think it's fair to say that it's largely been effective. We started conservatively but gradually relaxed some of our OT rules as we've learned about the effect of the ecosystem dynamics in practice and I'd hope we could do the same here. If we found instances of sites unreasonably locking out non-Chrome browsers, we'd adapt our OT rules to try to compensate. IMHO this has been extremely empowering in removing all the fear and uncertainty we used to face around experimental web APIs. Autoplaying audio and Chrome's media engagement system is another example where we finally resolved polarizing fights by a probabilistic system we worked hard to tune to maintain a good balance.

I like the discussion of holdback groups in the explainer as a key knob we could design to permit tuning the balance. I don't think we'll be able to get consensus on a binary question of holdback groups as phrased, but perhaps we could agree on the apparatus around them? Perhaps chromium should have a knob for holdback group size that starts relatively large but plans to fall as long as we see evidence of the value along with absence of evidence of the harms in practice?

Ben, the explainer says holdback groups are problematic because of the desire for "deterministic" solutions, right? But aren't the existing solutions (like fingerprinting) all probabilistic in some way too? Do deterministic solutions really exist at all? At the extreme, even for a fully attested device, I can just plug in a bot-controlled monitor, keyboard and mouse that uses AI to simulate a human, right? It seems to me that this problem space gets a lot more tractable if we give up any pretense of "deterministic solutions" and just focus on providing probabilistic signals to risk engines, because then we can hopefully keep the debate to largely the setting of the position of those knobs based on the outcomes we see, rather than in the intractable space of just guessing at very complex game theory?

Rick

--
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.

[Michaela Merz]

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

[Ben Wiser]

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.

[Michaela Merz]

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

[Rick Byers]

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. Do uses of this API seek to end that tradition or solve it in some other yet-to-be-described way?

Thanks,

   Rick

--

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.

[Ben Wiser]

@Rick, yes this might be what ultimately leads to the holdbacks being the enforcement mechanism to protect non-attested traffic. The hesitancy in my answers is just in case there is an awesome technical solution or approach that we haven't thought of yet that could also help counter some of the cons of holdbacks. We will ultimately have to commit to something that protects against these core concerns and I definitely won't be surprised if we land on holdbacks.

Ps: Thanks for that timeline link; I enjoyed looking at the graphical timeline with a cup of coffee.

[Morgaine (de la faye)]

How does this feature interact with users trying to use DevTools to understand how a site works ? There's notably not really any discussion of what an attestable environment is. This specification seems entirely open ended for how locked down a system might be or what might be permitted.

It seems all too likely that anyone using DevTools to look at or twiddle with a site has already broken the "Environment Integrity" seal. Is that the case? How do we maintain RFC 8890 in the face of this open ended specification which seems to have no limits on what it can do to restrict users?

[Michaela Merz]

It would be my suggestion that a "broken" integrity should result in a browser warning (like an invalid TSL certificate) allowing the user to continue if he/she so chooses. That would allow "twiddling" while also giving a normal user an amount of security that nobody else has "twiddled" with the code.

m.

 

--
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.

[A. M.]

This is literally 1984. Stop the war against general purpose computing. I am not willing to give up privacy for added security.

> 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."

Here's the problem: Once it's implemented, what will stop websites to block users who disable it? You can't use most banking apps (or even the McDonalds app, Snapchat, ...) on phones because they require passing SafetyNet. It's fundamentally the same thing.

It's my device, and I have the right to do what I want to do with it. Not somebody else.

[Michaela Merz]

There are a number of things to consider:

It's my device, and I have the right to do what I want to do with it. Not somebody else.

While I am 100& supporting this statement, this ship has sailed a long time ago. Our friends @Google already control many things that especially influence the life cycle and functionality of PWAs. But that is a completely different discussion I am having on different channels.

As to the topic here: We can implement integrity in different ways. IMHO the best way would be to not load failed resources at all. Kind like it is today with subresource integrity. Once the resource has been loaded, you may do whatever you want with it as there is no more integrity checking.

M.

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.

[Chris Palmer]

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.

[Michaela Merz]

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.

--

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.

[Reilly Grant]

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, which attempt to solve exactly the problem you're discussing.

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.

[Alex Russell]

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 "detect 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, 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

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.

[Dana Jansens]

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

[Ludwig GUERIN]

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

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.

[Yoav Weiss]

/* with my API OWNER hat on */

Examining this proposed change, it seems to me that the most risky part in the signed attestation information is the part about "application identity". Providing that information to the server seems to go against our past efforts to GREASE UA-CH and will prevent Chromium browsers from identifying themselves as Chrome, something they are (unfortunately) often required to do for compatibility reasons.

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.

[Dominic Farolino]

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.

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.

[Tom Jones]

Perhaps it is a good thing for user choice to have a browser that is fully open to any use and allows anonymous user actions.

The result of such open-ness is that an entire series of services that need to trust the client(used in the oauth sense of the word) are not available to web apps.

Consider the effort in IETF Remove Attestation Services (RATS https://datatracker.ietf.org/wg/rats/about/)  to get web trusted client apps. Without knowing the operating environment (ie the sandbox) such a statement loses most of its value.

I have recently worked on a fork of Chromium that is designed to have this functionality and on Native Wallet apps to get it. The lack of this functionality in Chrome will drive developers away from Chrome and fragment the user experience. We already have the problem of directing users away from Chrome to a secure wallet and being unable to bring the original user session back to Chrome. Of course Google and Apple get to solve this problem with their own wallets, but that will not fly in Europe and now the US DHS is asking for solutions that are more open as well.

Something needs to change. If this solution is not available, then the change will be outside the browser. ..tom

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.

[Lauren Liberda]

this message got me to write down my thoughts and a little case study of the last year's Big Mac exploit (not an exaggeration). https://liberda.nl/weblog/trust-no-client/

[Justin Schuh]

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, 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 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.

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.

[Rick Byers]

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 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, 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. 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

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.

[Rick Byers]

On Fri, Jul 28, 2023 at 9:19 PM Lauren N. Liberda <liber...@gmail.com> wrote:

>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.

FWIW I agree with you personally. The web is special because it's open and can be reached by anyone, not just some whitelisted set of UAs. That's a core property of the web that I'll personally always fight for. I appreciate that Google doesn't have a lot of trust with the community here, and people are going to assume bad intent. I've come to terms with that and hope to combat it primarily not through promises, but through helping drive positive actionin Chrome. Eg. I initiated our interop efforts years ago to reduce the risk of the web getting locked into chromium.

>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.)

It's been pointed out to me that my wording could be taken to suggest that I think folks who oppose WEI are criminals. That was absolutely not my intent and I apologize for not being more careful in my wording. I'm also the kind of person who likes to run rooted devices (used to compile my own NetBSD kernel from scratch weekly), custom browser builds, etc. and so I sympathize heavily with that use case myself and don't see how I could support a proposal which seriously risked the outcome you describe - users of such devices / niche browsers being locked out of important parts ot the web. AFAIK there is no serious debate as to whether such an outcome would be acceptable for the web (it's not), the debate is whether this proposal could possibly achieve it's aims without causing such an outcome. There's been lots of strong words saying it's impossible to reduce fraud risk without threatening the openness of the web and perhaps that's right, but I, for one, am always willing to be shown that something I thought was impossible was in fact doable with sufficient ingenuity and care. If I've learned anything from my tiny forays into the W3C anti-fraud community group it's that there's a lot of complexity and expertise in this space of which I know almost nothing, so I'm open to new ideas. I'm thrilled to see anti-fraud experts actually collaborating openly and publicly for, perhaps, the first time in Internet history. 

My primary intent with the word "criminal" was to take a strong stand against physical threats and doxxing - IMHO that is criminal activity and is inexcusable. To be consistent with our code of conduct we need to be absolutely clear that any change in direction here will come from the respectful and thoughtful comments on this thread and elsewhere (including your blog, which I quite enjoyed), not the intimidation tactics occurring on the GitHub repo and elsewhere. Sorry for not being more careful to clearly separate these things in my response. 

Rick

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.

[Billy Bob]

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 disappointingly similar to what occurred with Google’s AMP technology: more democratic discussions and open governance were offered only after AMP had become ubiquitous.

https://www.eff.org/deeplinks/2021/11/manifest-v3-open-web-politics-sheeps-clothing

Let’s start with some background.

First, over the years, Chrome has dramatically increased in market share to >65% of users, with the only notable competition coming from Safari. The EU has investigated and fined Google for antitrust actions. Suffice it to say that Google’s actions have an outsized influence on the web.

Second, Google has implemented user-hostile actions in the past. Whether you agree with the headlines or not, Google has been under fire for:

• Google AMP: how Google tried to fix the web by taking it over

• Google Says It Isn't Killing Ad Blockers. Ad Blockers Disagree

While there are many more, I think these examples highlight why users are concerned and do not trust you, despite your best intentions. Google as a company has not always acted in the users’ best interests. So when you propose the Web Integrity API in a way that many view as fundamentally altering the web, please imagine how users may be terrified that you will kill off something they love and can never be replaced. Plus, based on your past actions, you have already lost a significant amount of user trust. I understand that the motivation behind this API is to help protect user privacy and replace measures implemented with cross-site cookies, but please understand the background and motivation your users and developers have when engaging with this proposal.

So let’s talk about concerns about the Web Integrity API. Please do not think dismiss these as not understanding the proposal. Some points are relevant technical details, other points are relevant fears. Whether real or imagined, it’s important to address all of them.

These are not intended in the spec as written, but they are what users think your next steps could be. Many are taken straight from your closed and locked GitHub issues:

• Remove user choice and lock out users. If websites only allow users with a cryptographically signed token with chrome on a modern Apple computer, Windows computer, or smartphone, then that means that all flavors of linux, alternate browsers, and old phones are severely limited. Imagine being locked out of your own hardware.

• Lock-in Google’s monopoly. Open-source operating systems and browsers are locked out. If web crawlers and alternative web browsers are blocked, then new browsers and search engines have no chance to challenge the status quo. Plus, the antitrust process is painful and slow.

• Turning the web into Google’s App Store. The web is fundamentally different, and if companies want something akin to the Play Integrity API and App Attest, then they should build apps, not destroy the open web.

• If the Web Integrity API makes it even easier to fingerprint users, it will hurt users in authoritarian countries. Identity should not be required to connect with the open web.

• Prevent all web scraping. Web scraping is legal in many places and helped fuel the rise of LLMs like ChatGPT, Bard, and Bing as well as text-to-image models like Stable Diffusion, MidJourney, and Dalle. It’s important for all of these open-source AI communities.

• Prevent data archival. Nonprofits like the Internet Archive and the Common Crawl provide vital services to the community at large. Preventing bots prevents both good actors and bad actors. Imagine losing your internet heritage, along with important tools and resources.

• A DRM for the web necessitates disabling extensions. If you look at the goal of client trust and the use cases presented, a natural conclusion is that is necessitates disabling extensions and serves as a DRM for the web.

• Without extensions, the web becomes inaccessible to many users with disabilities. Users with disabilities of all kinds require all kinds of extensions to navigate the web. You are taking away their ability to live and accomplish their tasks independently. Users with disabilities should never be second-class citizens.

• Without extensions, it is the end for adblockers. Ads fingerprint devices to track users, slow down webpages, spend battery life, create obnoxious popups, and more. Websites can already detect and block Adblock users, do not disable them at the system level. I do not normally block ads, but when I do, it’s truly needed.

• A DRM for the web also means no developer tools. Developer tools are so important for users to tinker to fix websites, inspect websites, and get people into web development. Don’t block this important tool and learning resource. Invite users into web communities, don’t lock them out of it.

• All attesters may be run by major corporations like Google, Apple and Microsoft with no real or meaningful differentiation. Can any established open-source Linux groups ever be attesters?

• Destroys user trust. User trust is a two-way street. If you lock users out of making changes, they cannot trust you to act on their behalf. One example would be how Google tracks you in Incognito Mode and creepily collects and links personal information, despite users explicitly trying to avoid it.

• Opportunities ripe for abuse, such as shutting out marginalized groups who may not be able to use the latest version of a program. Or, again, users with disabilities. You may not be in a disadvantaged or marginalized group today, but can you say that you and your children never will be?

• The backbone of the open internet is the fact that any client from any vendor can access any website, as long as they implement all of the open standards a given website depends on. By giving the ability to exclude certain vendors and users to operators of a website, you are destroying the open web.

• Simply put, DRM for the web is fundamentally counter to an open web. Destroying the open web we all love and hold so dear is a tragedy. Stop the war on general purpose computing.

If we look back at the latest example of the Manifest V3:

According to Google, Manifest V3 will improve privacy, security, and performance. We fundamentally disagree. The changes in Manifest V3 won’t stop malicious extensions, but will hurt innovation, reduce extension capabilities, and harm real world performance.

https://www.eff.org/deeplinks/2021/12/googles-manifest-v3-still-hurts-privacy-security-innovation

Many users have commented explaining how the extensions do not improve privacy (extensions can still be as nosey as ever by tracking requests), but instead neuter adblockers.

In the same way, users are rightfully concerned that the Web Integrity API will not improve privacy, but further fingerprint devices and ultimately shut down the open web.

Because users do not believe that this proposal can achieve its goals and do not trust you, many want to nip this proposal in the bud. They do not want to help you improve it, because no amount of improvement can save it. People see unmitigated risks and questionable benefits for users—benefits for Google, advertisers, and developers, sure, but not for users. An open web and DRM for the web are fundamentally opposing goals that can’t be reconciled. As they put it:

"Constructive" involvement is not ethical when the goal is harmful

There are real user, ethical, and technical concerns about this proposal. Please stop work on the implementation until you have collected and addressed our concerns. Please engage in official W3C discussions, address responses from other browsers like Firefox and Vivaldi, and live up to the Chromium and W3C mission statements of an open web. Please read the mission statements.

Finally, I am giving you the benefit of the doubt. You are attempting to address some concerns. Do more of that. However, no matter what you say, you are judged based on what you do:

• Locking down all discussion and ignoring all feedback

• Moving forward with the implementation despite widespread pushback

Please try to understand why people would be freaking out, why people are scared of the proposal, why it seems you’ve lit a powder keg, and why the feedback is so negative, so harsh, and so swift. Please break down point by point how each of the fears (reasonable or not) listed above can be satisfied. Please don’t ask websites not to abuse the Web Integrity API, design it so that they cannot abuse it.

You are trying to solve real issues. Let’s solve them together, not create new ones.

Please listen to us—we want to be heard. Thank you for reading.

[Lauren N. Liberda]

>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.)

On 28/07/2023 21:08, 'Rick Byers' via blink-dev wrote:

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.

[Jake Rarisma]

Honestly your proposal scares me and it clearly scares other people too. I've saw this proposal from its first day and yet I am unable to find anyone online who supports this that isn't being paid by Google/Alphabet.  

I fear that this will be abused to further cement chrome(ium)s already rather egregious monopoly. I own a computer and everything runs as I'd like it, yet my phone deems me unworthy of accessing certain applications when i access the my phone's root account. For example my banking says that because my pixel rooted I am no longer able to access and control my own money.  

This will be used to force people to run stock chrome or other atteser approved browsers whether you (the guys developing WEI) wanted it to or not, this could be a death blow to open source browser development if this becomes wide spread.  I have no faith in Google as company or you as developers to serve the interests of the internet and humanity itself over Google's because there is a long history of Google doing and implementing unethical practices that actively go against the users wishes.  WEI feels like an extension of Mv3 to tear away consumer control and further erode a user's ownership over their own device.  

WEI is also unlikely to achieve many of your set out goals such as stopping bulk account creation from anyone who is a serious enough i.e a nation-state misinformation campaign. I'd also note how the advertising is the second use case and is before other more serious use cases i.e bulk account creation and comprised device detection.  

Also WebKit, brave and Mozilla have also said they are against implementing WEI and this poses several problems for implementing WEI across the web and could make chrome into an actual monopoly.

The road to hell is paved with good intentions, please take a long hard look at what this leads to.

[Mike Taylor]

Hi Billy Bob,

On 7/29/23 1:11 AM, Billy Bob wrote:

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.

You've found a great place to be part of the discussion and provide feedback (here on blink-dev, within the relevant Intent threads for a feature). And the folks working on the feature will take your feedback into account.

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. [snip]

Please take some time to familiarize yourself with the Blink process - which is how we prototype, experiment with, and eventually ship features (or decide to _not_ ship them), once approved by the Blink API Owners: https://www.chromium.org/blink/launching-features/. Prototyping features in the open (disabled, behind feature flags) is how we work.

thanks,
Mike

[Adam Norberg]

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

[Alex Russell]

Sorry for the slow follow-up here.

On Friday, July 28, 2023 at 10:26:25 PM UTC-7 Lauren N. Liberda wrote:

>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.

Chromium is forkable, and we (Microsoft) participate in this project with a big community of folks who are investing to improve the codebase. Google pays most of those bills, and as a result, enjoys the most influence. That's how OSS is supposed to work. Android is a different question (MADA is...not great), and to the extent that what we're talking about here is inflicting some of the closed properties of the Android ecosystem onto a much more open, standards-based userland, we can differentiate those interests and influences.

Simply saying "there's a lot of influence from Google in Chromium" attempts to prove far too much.

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.

That's a statement of intent that isn't exactly clear from the original explainer that was published. We should absolutely be asking for much more clarity around the goals and concrete use-cases. Obviously, this is what Apple is *already* doing, and it's very directly what you're worried about:

    https://httptoolkit.com/blog/apple-private-access-tokens-attestation/

 

The opportunity here, if we can avoid asserting malintent, is to seek clarification on the user and developer needs and make sure the design meets them with the minimum of risks and downsides.

So let's collectively interrogate needs and goals, assuming good faith.

Best,

Alex

To unsubscribe from this group and stop receiving emails from it, 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/b5f5a252-a0fc-4c37-8ae8-9a460d20373an%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 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.

--
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 view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-uykBNk1Vpd85sEzRXrKTroxcy5wowspF0hmSkugX4dEw_qg%40mail.gmail.com.

--
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 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.

--
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+unsubscribe@chromium.org.

[Feedi Maili]

I think solving the problems attestation has already caused on Android, which are the same users are afraid of with WEI, such as being locked out of crucial banking apps if you un-google, would invoke a lot more trust and co-operation than an attestation proposal for the web without first having concrete solutions to the problems.

Perhaps there isn't as much interest in doing that, because the problems are beyond difficult, and solving them would only benefit the users, not any other stakeholders.

Of course the other way around is also possible, but what I mean is that saying "we want to do this thing you consider 'bad', would you help make it less bad?" will more likely result in "just don't do it" than "this established thing you consider 'bad', would you help make it less bad?". Although I guess you could call that a hostage situation, but I digress.

I feel the prior art in the exact same problems is being looked over too much. The explainer even seemed to be pointing to the Play Integrity API as successful prior art, without considering the problems. Sure, it is a successful example of abusing the power you have when only a marginal group of users are using Android without Google services.

[Lauren N. Liberda]

On 04/08/2023 19:28, Alex Russell wrote:

Sorry for the slow follow-up here.

On Friday, July 28, 2023 at 10:26:25 PM UTC-7 Lauren N. Liberda wrote:

>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.

Chromium is forkable, and we (Microsoft) participate in this project with a big community of folks who are investing to improve the codebase. Google pays most of those bills, and as a result, enjoys the most influence. That's how OSS is supposed to work. Android is a different question (MADA is...not great), and to the extent that what we're talking about here is inflicting some of the closed properties of the Android ecosystem onto a much more open, standards-based userland, we can differentiate those interests and influences.

Simply saying "there's a lot of influence from Google in Chromium" attempts to prove far too much.

I talked about Google here because I think this is specifically relevant in case of WEI - risk of lock-in benefiting biggest operating systems (including Android with Google proprietary parts), role of Google Play Services in Android, Google becoming/being an authority for what an accepted user agent is. 2/3rds of this can easily apply to Microsoft as well.

But my point here was more about a single project being this big, having this much impact on what the web looks like. WEI aside, much smaller decisions like image formats or media codecs supported by Chromium, have impact on over 70% of the web users. The web is already Chromium-shaped.

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.

That's a statement of intent that isn't exactly clear from the original explainer that was published. We should absolutely be asking for much more clarity around the goals and concrete use-cases. Obviously, this is what Apple is *already* doing, and it's very directly what you're worried about:

    https://httptoolkit.com/blog/apple-private-access-tokens-attestation/

This is based on the current proposal. Explainer mentions Play Integrity API and Apple's App Attest as inspirations for WEI. Android prototype uses Play Integrity API to produce the attester verdict.

This is also what I talked about previously. Apple just introduced it to the users of their walled garden only, with no similar intents from other browsers. Yes, this is a bad thing, but nobody else got impacted, because nobody's thinking "I'm gonna effectively unplug 80% of the internet users from my website". With something like this getting implemented in Chrome, the story becomes completely different.

 

The opportunity here, if we can avoid asserting malintent, is to seek clarification on the user and developer needs and make sure the design meets them with the minimum of risks and downsides.

So let's collectively interrogate needs and goals, assuming good faith.

What I've seen here so far is a discussion on how the consequences of deploying a Torment Pixel can be limited, so a number of platforms is not straight up killed for general purpose use. I don't think the measures described in the explainer are preventing any of the risks, and introducing WEI as it is would create more harm than any fraud prevention it can bring. Don't create the Torment Pixel.

I'm not questioning if you do this in good faith, but as people say, the road to hell is paved with good intentions.

[Alex Russell]

Hey Lauren,

Sorry for the slow follow up; inline:

On Saturday, August 5, 2023 at 8:26:24 AM UTC-7 Lauren N. Liberda wrote:

On 04/08/2023 19:28, Alex Russell wrote:

Sorry for the slow follow-up here.

On Friday, July 28, 2023 at 10:26:25 PM UTC-7 Lauren N. Liberda wrote:

>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.

Chromium is forkable, and we (Microsoft) participate in this project with a big community of folks who are investing to improve the codebase. Google pays most of those bills, and as a result, enjoys the most influence. That's how OSS is supposed to work. Android is a different question (MADA is...not great), and to the extent that what we're talking about here is inflicting some of the closed properties of the Android ecosystem onto a much more open, standards-based userland, we can differentiate those interests and influences.

Simply saying "there's a lot of influence from Google in Chromium" attempts to prove far too much.

I talked about Google here because I think this is specifically relevant in case of WEI - risk of lock-in benefiting biggest operating systems (including Android with Google proprietary parts), role of Google Play Services in Android, Google becoming/being an authority for what an accepted user agent is. 2/3rds of this can easily apply to Microsoft as well.

But my point here was more about a single project being this big, having this much impact on what the web looks like. WEI aside, much smaller decisions like image formats or media codecs supported by Chromium, have impact on over 70% of the web users. The web is already Chromium-shaped.

The scale of the impact of the project is a large part of why the Blink Launch Process is so much more open, deliberative, and iteration-focused than the processes of other engines. It's also why non-Googlers like me can be API OWNERS.

What you're seeing in this thread is a team being much more open, much earlier, than other efforts would have been. That's the essential feature of our process that allows for early correction. I'm optimistic that the team that proposed this will integrate (civil, thoughtful) feedback soon.

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.

That's a statement of intent that isn't exactly clear from the original explainer that was published. We should absolutely be asking for much more clarity around the goals and concrete use-cases. Obviously, this is what Apple is *already* doing, and it's very directly what you're worried about:

    https://httptoolkit.com/blog/apple-private-access-tokens-attestation/

This is based on the current proposal.

Perhaps I misunderstand the status of these systems?

What Apple announced in 2022 and shipped last year allows attestation based on underlying system factors, in exactly the way proposed here. As you note, both are reflections of underlying system mechanisms that were previously introduced to combat fraud in the Android and iOS proprietary ecosystems, but it isn't my understanding that this proposal is the basis for PAT. Do I misunderstand?

 

Explainer mentions Play Integrity API and Apple's App Attest as inspirations for WEI. Android prototype uses Play Integrity API to produce the attester verdict.

This is also what I talked about previously. Apple just introduced it to the users of their walled garden only, with no similar intents from other browsers. Yes, this is a bad thing, but nobody else got impacted, because nobody's thinking "I'm gonna effectively unplug 80% of the internet users from my website".

You're right that scale gates opportunities, but it's worth noting that developers, including CDNs, lockstepped introduction of support for this with Apple's announcements. Apple's relative monopoly on wealth (~all wealthy users carry iOS devices) creates a much larger impact than device shipment would imply. Being able to change things for 89% of *revenue* generation is a big deal, and for many businesses, that's what Apple has already done here.

 

With something like this getting implemented in Chrome, the story becomes completely different.

 

The opportunity here, if we can avoid asserting malintent, is to seek clarification on the user and developer needs and make sure the design meets them with the minimum of risks and downsides.

So let's collectively interrogate needs and goals, assuming good faith.

What I've seen here so far is a discussion on how the consequences of deploying a Torment Pixel can be limited, so a number of platforms is not straight up killed for general purpose use. I don't think the measures described in the explainer are preventing any of the risks, and introducing WEI as it is would create more harm than any fraud prevention it can bring. Don't create the Torment Pixel.

I'm not questioning if you do this in good faith, but as people say, the road to hell is paved with good intentions.

Pejorative language is not super helpful here, given that this is an engineering forum. It's enough to note that this proposal isn't clearly outlining needs to be solved, and isn't highlighting the risks effectively, which means that it's not possible to greenlight it under the rubric of the Blink Launch Process.

[Daniel Shumway]

I'm not certain how relevant Private Access Tokens are to the current discussion of Web Environment Integrity; I feel like the proposal should be considered on its own merit.

But given that Private Access Tokens have been brought up as a point of comparison, and given that Private Access Tokens have been brought up as an explanation as to why WEI is either not as dangerous as its critics suggest or as an explanation as to why it feels like Blink is getting an undue amount of attention about this proposal -- I think it's important to present the idea that Private Access Tokens are dangerous to the Open web if implemented widely as a general standard across multiple browsers for many of the same reasons why WEI is dangerous.

There's a discussion being had about whether or not PATs are exactly as dangerous as WEI, and I fully agree with Lauren that the risks from Safari and Chrome are different. There is no way to get around the fact that most websites can not rely on Safari-only features, but that they often can rely on Chrome-only features and would definitely be able to rely on features implemented in both Chrome and Safari. But that doesn't mean there are no risks at all from PATs or that they wouldn't impact accessibility, user agency and autonomy, and browser competition if implemented widely. So discussions about exactly how dangerous PATs are in comparison to WEI run the risk of masking the underlying reality that trusted user environments enforced by websites through attestation have significant downsides and should be rejected, period.

I want to keep the thread technical, but if I can praise the Blink development process itself for a second, there is a massive benefit to Blink being more open and transparent about its standards process and we're seeing that benefit right now. It is precisely that ordinary users are more skeptical of Google than they are of Apple and that they pay more attention to web API proposals that come out of Google groups. The increased scrutiny that developers pay towards Blink proposals is a feature, not a bug. It means that changes that might have gone unnoticed and under-discussed can instead be given the serious attention they deserve.

It's unfortunate that PATs got so little pushback during their proposal and implementation. It's unfortunate that they were implemented at all, but it is fortunate that attestation-based PATs were only implemented in Safari. It would be detrimental to the web if they were standardized and implemented in Android and/or Windows/Linux browsers. So one good thing that might come out of WEI discussions might actually be increased scrutiny on PATs as a web standard, and that might happen because ordinary users are more skeptical of Google and more likely to fully consider the real risks and downsides of an attestation proposal that comes from the Blink team.

Again, I don't think that PATs are totally relevant to the current conversation; I think it's better to focus specifically on the API being proposed. But if PATs are part of the conversation, I would really, really love to see a commitment from Blink developers that attestation-based Private Access Tokens will not be implemented in Chrome and that Google is committed to pushing back on attestation tokens in general as a cross-platform web standard.

Where WEI specifically is concerned, the existence of Private Access Tokens does not make me feel more confident that the intrinsic and unavoidable downsides of Web Environment Integrity will be treated as seriously as they deserve. If anything, PATs make me feel less confident. PAT is a browser feature that (to a lesser degree) has similar downsides to WEI, and  should have prompted similar discussions and similar worries, but it was able to make it into production without significant pushback from people who will also be making decisions about WEI. We are lucky that Blink's development is open enough that issues like this can get caught early, and hopefully that will prompt not only a rejection of WEI but increased scrutiny on similar experimental browser features that also should have been rejected.

[Anton Bershanskyi]

Hello everyone,

has there been any progress on Web environment integrity API since August? In particular:

1. Does Google still have aspirations to prototype this API? The Chrome Platform Status entry specifies that there is "no active development".
2. If there are no plans to prototype this API, are there plans to remove the source code?
3. If there are plans to continue prototyping, are there any plans to address the following concerns?
   1. Permission Policy integration to allow websites to delegate and/or restrict usage of this API to embeds?
   2. Permission API (even without the UI) which wold allow user agents and/or end users to control this API? (Relevant bug for Android)
   3. Choice to partition/key WEI handles based on top-level origin alone or the top-level origin and the embed? (Relevant bug mentions the conflict between handle scarcity and privacy implications of coarse partitioning on top-level origin alone.) Please note that this likely could be addressed via point 1, that is implementing Permission Policy integration with a default allow list of 'self' since then the top-level origin would delegate the access explicitly.

Thank you.

[Ben Wiser]

Hey all,

Thanks for your patience. After carefully considering all your feedback, we’ve decided to no longer pursue the Web Environment Integrity proposal. The Android team will instead be experimenting with a narrowly scoped WebView only feature that won’t make it to web browsers. The full details for that experiment as well as the unique WebView only challenges have been published to the Android Developers Blog.

We've archived the WEI github repository and will revert all WEI code on Chromium.

We’d like to also say thank you for all the feedback on the I2P on such a complex topic.

[Tom Jones]

I appreciate the problems and am disappointed that the project was abandoned.

I come from a different space, the Open Wallet Foundation, where a very similar problem is evolving (see the IETF RATS efforts as an example). In my view the problem is that the client should not need to trust the server, nor to supply ANY DATA to the server, until the server proves itself to the client. Anything else results in leaking user privileged data to a potential adversary.

Somehow the problem of invalid servers needs to be addressed prior to addressing invalid clients.

Thanks for the efforts here.   ..tom

--

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/87ca941d-0eee-40ce-9a2a-65e12ae02437n%40chromium.org.

[Rick Byers]

Thank you for the update and cleanup Ben. Also thank you very much for all your hard work trying to balance very difficult competing goals, engaging openly with constructive criticism and reevaluating the approach.

Personally, I'm still optimistic that we (the open web community) will find ways to reduce the harms of invalid traffic across the whole web. But, in terms of an immediate tractable step forward, the narrow focus for WebView outside Chromium makes a lot of sense to me. Despite the challenge, I welcome further open exploration, experimentation and respectful debate on the problem space. In fact, I expect it will be essential in the long run if we want the web on Android to have access to content available to native apps and browsers like Mobile Safari which already provide device integrity signals.

IMHO It's only through this sort of a public process of exploration, debate and iterating on experiments that we'll ever find our way to healthy balances between conflicting goals of great importance to our user and developer constituencies. We designed the blink API process to be "safe to fail" because we know it's the only way to succeed at the most important hard problems long-term.

Thank,

   Rick

--