Don't. #28

This is DRM infrastructure for websites and fundamentally counter to an open web.

So yeah, don’t.

100% agree. This proposal offers far too many opportunities for abuse. The authors have clearly tried to mitigate this, but their measures are insufficient and always will be, because the underlying idea is flawed. Lets leave this one in the past - it will only ever cause more harm than good.

Almost every reasonable use case of this proposal is something that makes the web worse for users. It opens another front in the War On General Computation, and continues the trend of web browsers ceasing to be user-agents, and becoming the property of the website owners. It's a straight-up attack on the open web.

I would add myself to the points above, this is not a good idea and opens up so much potential abuse, and shutting out of marginalised groups who may not be able to use the latest version of a program.

The world is also dividing along ideological lines that could see this used to perpetrate a shutdown of information to a select few.

tl;dr Don't

Please just withdraw this horrible idea.
"Web Environment Integrity" is when you, as developers, show integrity and dump this.

Have you lost your fucking minds? DRM never was and never will be a good idea. Just stop.

No. Either no one else than you can build browser engines anymore, or this won't work anyways.
This is against OpenSource. How would my homebrew-browser be forced to be honest?

The entire premise of this proposal is completely flawed. To quote the authors,

Users often depend on websites trusting the client environment they run in.

If the security of your web service depends on a specific client environment, your web service is designed wrong. Period. If something is security-critical, you should not ever delegate that computation to client side and you should not ever blindly trust any client-side input, even if you can attest to any digital signature from the client. Are you sure you are going to be able to maintain an up-to-date list of all the vulnerabilities of all "trusted" clients? And how are you going to mitigate all of them in time? Even with Android, a lot of known vulnerable devices are still "trusted" under SafetyNet / Play Integrity. The only way for any service to be secure is to not trust client input blindly.

This trust may assume that the client environment is honest about certain aspects of itself, keeps user data and intellectual property secure, and is transparent about whether or not a human is using it.

Your proposal has exactly nothing to do with whether a human user is interacting with the device. All you can ever do is attest to the fact that the client uses software with a signature trusted by the server. An automated program does not have to actually execute within this environment -- it can be a device outside of the control of the client-side operating system entirely. Are you then going to authenticate all peripherals connected to the device?

This trust is the backbone of the open internet, critical for the safety of user data and for the sustainability of the website’s business.

Let's make this very clear: 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 the open standards a given website / application depends on. By giving the ability to exclude certain vendors and users to operators of a website, you are destroying the open internet, not the other way around.

^^ what they said. There is no compelling argument for any of this other than "policing the content/services I provide on the internet WITH humans, in order to maintain a productive service FOR humans, is expensive and I don't wanna; so lets add more complexity to an already complicated and impossible to understand/maintain tech stack and add even more hurdles a user has to go through rather than just sending a browser to a URL.."

Plus if you add yet another thing I have to 2FA just to read the instructions on how to repair my dishwasher, I may start to get nasty.

Hello! I'm hoping to help with potential workarounds, in case this issue is closed without action.

In the United States it might be possible to request a workaround through the involvement of the United States Department of Justice Antitrust Citizen Complaint Center at https://www.justice.gov/atr/citizen-complaint-center — as observers have noted, if we end up with website DRM everywhere and whitelisted entries for browsers like Chrome and agents like Googlebot, the net effects will be radically anti-competitive.

Please remember:

When contacting the Antitrust Division about a possible antitrust violation or potential anticompetitive activity, please provide as much of the following information as possible:

• The names of the companies, individuals, or organizations involved
• How do you believe they have violated the federal antitrust laws? (For details on federal antitrust laws, see Antitrust Laws and You.)
• Examples of, or details about, the conduct that you believe violates the antitrust laws
• The product or service affected by the conduct, including where the product is manufactured or sold or where is the service is provided
• The major competitors that sell the product or provide the service
• Your role in the situation
• Who is being affected and how they are being affected

You may submit your concern by e-mail, regular mail, or phone.

By email to [email protected].

By postal mail to:
Citizen Complaint Center
Antitrust Division
950 Pennsylvania Ave., NW
Room 3322
Washington, DC 20530

By phone at 1-888-647-3258 (toll free in the U.S. and Canada) or 202-307-2040.

In the European Union you want the DG Competition:

If you are directly affected by the practice which you suspect restricts competition and are able to provide specific information, you may want to lodge a formal complaint, which must fulfil certain requirements. The complaint form (“Form C”) is available on the Commission Regulation (EC) No 773/2004 of 7 April 2004 relating to the conduct of proceedings by the Commission pursuant to Articles 81 and 82 of the EC Treaty [1]. Official Journal L 123, 27.04.2004, p.18-24 (see the form on the last page “Annex”).

Information on how the Commission handles complaints is available on the Commission Notice on the handling of complaints by the Commission under Articles 81 and 82 of the EC Treaty (Articles 101 and 102 TFEU) (Official Journal C 115, 9.5.2008, p. 88–89).

You can provide information on a specific market where you may have concerns regarding compliance with EU competition rules by e-mail to [email protected]. Please indicate your name and address, identify the firms and products concerned and describe the practice you have observed. This will help the Commission to detect problems in the market and be the starting point for an investigation. We invite you to read our e-services privacy policybefore contacting us. You can also send your complaint by post:
You can also send your complaint by post:

European Commission
Competition DG
B - 1049 Bruxelles

If the situation you have encountered is limited to one country or area, or involves no more than three EU Member States you may want to contact a national competition authority. The competition authorities of all EU Member States now apply the same competition rules as the European Commission and very often they are well placed to deal with your problem. If you think that a larger number of Member States are concerned, you may primarily chose to contact the European Commission. If you are not sure about the scope of the problem, do not hesitate to contact either the European Commission or the national competition authority because the authorities cooperate among them and will allocate the case as appropriate.

"so preoccupied with whether they could, they didn't stop to think if they should"

how about no

TEEs in our phones to attest bootloader lock and SafetyNet (yes it's now Play Integrity) are already way too much

When most ads are malware and most sites are not accessible out of the box, including Google sites, how will this API improve the browsing experience for real users?

If your service trusts the client, you have failed as a developer

Authors: Google, Google, Google and Google

Maybe Google should play in it's sandbox rather than defining what Internet is?

"what if the web sucked as hard as app stores do?"

I would like to respectfully add my suggestion that Ben Wiser (Google), Borbala Benko (Google), Philipp Pfeiffenberger (Google), and Sergey Kataev (Google) all take this opportunity to engage a personal lawyer and seek legal advice, i.e. do not defer to the corporate counsel (Google), who may not have their best interests in mind. Antitrust law is real. Some violations are crimes.

Oh wow, another Google attempt to lock out adblocking in the long run. Absolutely unsurprising.

Knock it off.

This, also quit your jobs at Google.

Users like visiting websites that are expensive to create and maintain, but they often want or need to do it without paying directly. These websites fund themselves with ads, but the advertisers can only afford to pay for humans to see the ads, rather than robots. This creates a need for human users to prove to websites that they're human, sometimes through tasks like challenges or logins.

This is a masterpiece of doublespeak, I have nothing but awe and congratulations for whoever pinched this one off.

This proposal speaks a lot about trust, but seems not to realize that trust happens in multiple directions, often simultaneously.

By locking a user out of changes - possibly even at the configuration level or installing extensions - to their browser, they can no longer trust the browser to behave with their interests in mind. It actively corrodes a user's ability to trust the browser to not spy on them, or perform other malicious behavior such as deleting data without consent.

@RupertBenWiser writes about how frustrating it is to be locked out of your own hardware:

http://benwiser.com/blog/I-just-spent-%C2%A3700-to-have-my-own-app-on-my-iPhone.html

Don't be evil.

This gets a rousing, unequivocal NOPE from me. I'm sure we all understand the challenges of servers fighting against attacks like DDoS and other issues, but in trying to mitigate against bad actors, we can't break the web in the process.

Don't be evil.

@jaredcwhite They dropped that motto a long time ago. Google has accustomed itself to indulge in evil.

This is pure, unmitigated evil. You're basically ensuring a monopoly for your platform.

Each of you should be personally ashamed and likely banned from the industry.

I will be the first person suing your company if you implement this, this is guaranteed to be illegal.

This is very much a love letter to people who engage in phishing and as well as write malware as it makes their job a lot easier.

I would like to respectfully add my suggestion that Ben Wiser (Google), Borbala Benko (Google), Philipp Pfeiffenberger (Google), and Sergey Kataev (Google) all take this opportunity to engage a personal lawyer and seek legal advice, i.e. do not defer to the corporate counsel (Google), who may not have their best interests in mind. Antitrust law is real. Some violations are crimes.

I strongly agree. This is a blatant, willful violation of a bunch of antitrust laws.

Remember that the VW engineers were the only ones who served prison time for the emissions scandal.

I would feel deeply, personally ashamed to have my name associated with an idea as bad as this.

Let's imagine this scenario:

There is a search engine "A" and a search engine "B", both of which uses scrapers capable of executing javascript code.

But the search engine "A" also happens to have some kind of involvement with attester entity called, for example, "Google Play".

The question: what are the chances of attester entity to be more biased towards the scraper of the search engine "A", than search engine "B" when giving their verdict?

Human-facing, client-side platform-state attestation won't and will never be used to secure the agency or well-being of a human.
Particularly when the developers of that attestation process consider "How will we prevent this signal from being used to exclude vendors" to be an "open question" worth considering, and "how will we prevent this signal from being used to exclude or marginalize classes of people" doesn't deserve so much as the "todo" you've granted to lesser considerations like "privacy". This is an attempt to keep humans from being able to make choices that are inconvenient to your business model and that's it.

I'll put a thousand dollars down that everybody involved in drafting this spec uses an ad-blocker, without exception. And yet here you are trying to strip other people of the agency that you enjoy every day, to shelter a failing business model from inconvenient market realities like "people who don't like the product are allowed to not buy it".

Is this the work you wanted to do? Was this the dream, is this the kind of engineer you wanted to be? Because you have agency too, you can still make choices about who you want to be and how you want the world to be different because you were in it, and maybe they can be better choices than this.

Hey folks!

Jumping in here in a chair role, at the request of the team working on this.

I'd like to remind folks that contributions on this repo are subject to GitHub's code of conduct as well as the W3C's Code of Ethics and Professional Conduct. Violations of these codes of conduct will results in bans and reports. Spammy issues will be closed without comment. Duplicates of this issue will be folded into this one.

I understand many folks here are upset about this proposal. I urge you to actually read the proposal, rather than rely on rumors about what it does or doesn't propose. If it's at all helpful, I wrote a few words about ways you can constructively engage with proposals you don't like.

This repo represents an early stage proposal, not a fait-acompli. High quality feedback on the proposal itself is highly welcome. Unprofessional behavior is not.

Thanks!

This is not helpful at all no.

You are violating the basic code of conduct of the entire internet with this proposal.

Tone policing when you are the one suggesting insane things is silly.

You say to apply Occam's razor, which would clearly imply google locking down the internet for their own profit here.

Stop this and delete the repository immediately.

I understand many folks here are upset about this proposal. I urge you to actually read the proposal, rather than rely on rumors about what it does or doesn't propose. If it's at all helpful, I wrote a few words about ways you can constructively engage with proposals you don't like.

While the proposal may not directly be meant to do the things mentioned here, its power dynamics work out that way over time. In the end a solution like this requires power over verifying the client to be given out to the servers, which relies on a hardware root of trust that has been covertly installed by the industry in end-user devices without much thought given to whether society as a whole has consented to this. In fact the wording used around these technologies feels deliberataly technical and becomes a footnote security feature mentioned in marketing material, without the power implications being widely explained. It is an initiative undertaken by corporations without democratic control.

I find the inspiration being taken from native implementions like play integrity to be problematic. These systems have shown us a taste of how this looks like, but thankfully limited to mobile devices. Regardless, I have first hand experience of having to battle with SafetyNet to keep older devices alive and up to date (which has a downgrade attack, so it's not a full use of remote attestation). Ironically using outdated vendor software brings no issues in that case, which makes SafetyNet a obstacle to better security.

The overall effect is that other operating systems cannot interoperate in practice, because 3rd parties would have to explicitly support them, and they simply don't care. Since the user has no option of overriding their hardware, they cannot resort to spoofing.

I don't believe there has to be a conspiracy there, market dynamics will simply ensure that smaller players won't get taken into account and will have a conflict of interest with the industry. Similarly the wide implementation of this technology is simply convenient to big tech players, they get to kill two birds with one stone (CAPTCHAs, 2FA) and they get to ensure their market dominance. It also avoids usual antitrust issues (though I'm not a lawyer, so don't hold me on this), because it distributes the enforcment of this. There are likely to be multiple gatekeepers here that all roughly align themselves with what big platforms want, which dillutes responsibility. They will keep their influence through network effects, as users and browsers will have to accept the standards of those who's attestation is trusted by the most platforms.

I understand this is a convenient solution for some engineering problems, but as it's leading us down a very bad path, we have no choice but to back out of it and do something else. This is where your responsibility comes in, because I think pushing this set of technologies forward in any way should be avoided, it makes it much more difficult to back out of and will enable abuse.

That's why I don't think it's possible to offer constructive criticism of this proposal itself, it comes with the assumption that it and the oppresive technology it's built on itself is valid. But I can offer constructive input on other paths the industry could take.

External hardware tokens are one way, you still get attestation that someone holds a physical object, you get 2FA, but you cannot determine the device state, which is the whole point that makes TC an oppressive technology. Less convenient? Yes, both for users and industry, you'd probably need to manadate it through legal means, but it is 100% worth it to avoid compromising user autonomy on a global scale.

Note here: Integrating that into devices without enabling TC is possible, but presents problems for reselling/giving away used devices and parts, but maybe something could be done about this.

I implore everyone involved in working on this proposal to read Phillip Rogaway's 2015 paper The Moral Character of Cryptographic Work and to think about what kind of world you want to live in.

I implore everyone involved in working on this proposal to read Phillip Rogaway's 2015 paper The Moral Character of Cryptographic Work and to think about what kind of world you want to live in.

Everyone should also watch Cory Doctorow's speech on The Coming War on General Computing from 11 years ago that talks about this concept and it's detrimental effects to humanity as a whole. https://youtu.be/HUEvRyemKSg

They're gonna do it, just like they did manifest v3, and you're not gonna do anything about it, just because they can.

Apologies for my earlier snide remark w.r.t. comment deletion, at least one of those did deserve to be removed.

I just have one more thing to add. Re-reading the proposal, there are multiple places where you point out several Very Bad Things that it could be used for. It appears that your entire plan for "mitigating" those possible uses is 80% "well we'll just tell people not to" and 20% "maybe we can just randomly not present the information sometimes so people can't rely on it?" and I think it's pretty obvious that neither of those will work.

If it is possible for a technology to be abused for oppressive or abusive purposes, it will be.

"telling people not to" (or pointing at "agreements"/"pledges" that companies have made, basically them saying "I swear I won't misuse this" despite being under massive financial pressure to take every single possible commercial advantage they can get their hands on) is laughable.

Anything that involves intermittently not sending the attestation will just result in people seeing errors until they've mashed refresh enough times to trigger a fallback/failsafe, or begin an unending game of cat and mouse between the masking algorithm and enterprises seeking to bypass it.

It is helpful to remember that under our current Western system of economics and government, every single publicly traded business is driven by a single goal: Provide a bigger number on the next quarterly return than the last one. Literally nothing else matters.

Adding functionality with such massive potential for misuse and abuse, without any guard rails against abuse other than "we swear we won't uwu", is not even remotely close to good enough - and I fail to see any way this could be made to achieve any of the stated goals (goals I don't believe are remotely necessary or worthwhile, mind you, but that's beside the point) without it being possible to misuse.

The only way to stop this technology from being misused is to not implement it in the first place.

I understand many folks here are upset about this proposal. I urge you to actually read the proposal, rather than rely on rumors about what it does or doesn't propose.

I found this interesting:

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.

Source:
https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_kGO22g

Great so even the powerful Microsoft gave up on writing a web browser and went Chrome. Everything is Chrome, and now here comes the flex to lock us little people out. I understand that pulling up the ladder, and closing out people is a priority but wow just wow. I wonder if we will even be allowed to host web sites in this brave new world? I left blogger for a reason, namely that Google was beyond inept at running it. What happens when this standard gets pushed, and we get locked out, and this will become the IE6 of the 2030's forever locked us into some AOL land where we have zero freedom to use the open networks?

If you wanted innovation, it should be leveraging AI to augment routing protocols, dns lookups, threat detection & mitagation. I'd love to see some Gibson-esque ICE. Instead all I see is the slamming wall of the 防火长城.

I'd say I was sad, but I'd expect nothing more from an organisation shielding itself from the people, to protect the megacorps.

Shame.

I'd like to remind folks that contributions on this repo are subject to GitHub's code of conduct as well as the W3C's Code of Ethics and Professional Conduct. Violations of these codes of conduct will results in bans and reports.

I don't care about SJW "Codes of Conduct." They have no place in open discussions and should be abolished. Anyone in software laying out a "Code of Conduct" is contributing to the social cancer and should be exiled. Bullies like @scanlime [1] who would open project issues just to accuse people of "abuse" are precisely the reason that both "Codes of Conduct" and remote attestation are horrible ideas. Remote attestation in particular will be used to restrict and silence anyone who disagrees with the narrative of those who have access to the technology or the favor of the people controlling it.

Even Google themselves admit upfront that this can and will be abused by bad actors.

I'd like to remind folks that contributions on this repo are subject to GitHub's code of conduct as well as the W3C's Code of Ethics and Professional Conduct. Violations of these codes of conduct will results in bans and reports. Spammy issues will be closed without comment. Duplicates of this issue will be folded into this one.

Gonna be straightforward in this one. Don't be a coward and and dismiss your peers outrage as "spam". The level of outrage generated is a valid thing to consider, and deleting issues has never ever worked out for anyone PR wise.

I'll also note that abusive comments supporting the proposal so far have stayed up. Just saying...

I understand many folks here are upset about this proposal. I urge you to actually read the proposal, rather than rely on rumors about what it does or doesn't propose. If it's at all helpful, I wrote a few words about ways you can constructively engage with proposals you don't like.

This is a pretty neat sleight of hand trick you've pulled off. Implicitly assuming that the constructive outcome is to improve the proposal. This is of course a bad response when the community consensus is that the proposal is fundamentally bad not in its methods, but in its stated goals.

This repo represents an early stage proposal, not a fait-acompli.

Once again, the fundamental issue here is that nobody trusts Google. You can swear up and down that it's not a fait accompli, but it's not like we've seen Google use their market dominance to force through unpopular standards changes before. Part of the long term consequences of this loss of credibility is that any proposal like this is treated as a nine alarm fire because

1. Nobody trusts google to not abuse this mechanism.

2. Nobody believes that its "just a proposal".

These things would be obvious to you too if you stopped and listened to other people, rather than talking at us.

Google has often proven untrustworthy. Thus, there's no reason to trust this proposal either. Sure you can claim all you want that "content blocking will still work!" but people clearly know what is up.

Do the right thing: It's time to stop this madness just to get people to watch ads or destroy their privacy, for a quick buck.

People also have right to their privacy and right to not connect their computer to addresses they do not wish to connect.

Leaving a husk of "open" internet to future generations is not what anyone wants. It must be preserved as it is. You do not have to do anything.

Or do you really wish your children's and their children's privacy to be invaded? That's the route we're on, once again. And why we're on that route? Because Google has a stranglehold of the internet.

For other users of the internet, I hope that you will very least switch your browser from any chromium based ones.

Or do you really wish your children's and their children's privacy to be invaded? That's the route we're on, once again.

To a megacorp, children are slaves to be bred into good little worker bee CONSOOMERS. This entire "remote attestation" idea is peak corporatism.

I understand many folks here are upset about this proposal. I urge you to actually read the proposal, rather than rely on rumors about what it does or doesn't propose.

The proposal is crystal clear, anybody with the slightest experience in software development can clearly see what you are trying to do here. Have you noticed that you haven't got any defenders, under this issue?

This repo represents an early stage proposal, not a fait-acompli.

Something that you are not willing to withdraw is not a proposal, and given your affiliation with Google it is already a fait accompli.

High quality feedback on the proposal itself is highly welcome. Unprofessional behavior is not.

There is no higher quality feedback than this: show integrity and dump this. Expecting others to even assist you with your nefarious attempt does neither speak for your professionalism nor for your integrity. It just demonstrates that you have already made up your mind and will try to pull this off, at all costs.

@jbruchon it undermines your attempt at taking the high road when you delete the post I was responding to and replace it to obscure the edit history.

Is that whole thing a joke? If something like that gets implemented people will no longer keep dealing with it like it's nothing, a bloody revolution may be the only solution. So just don't implement this

@jbruchon it undermines your attempt at taking the high road when you delete the post I was responding to and replace it to obscure the edit history.

I don't care about "taking the high road." I care about the "open" part of "open source." You pretend to care until someone says something you don't like, then it's "rules for thee, not for me." If you don't like people seeing the shitty things you say then you're free to stop saying those things.

People like you who make it impossible to agree on one thing while disagreeing with something else are the shining example of what I'm talking about in my previous comment. You want a codified method to rules lawyer anyone who disagrees with you out of anywhere you go and a big hammer to enforce it with. Remote attestation is a colossal magic banhammer that can be wielded over the Web. You pretend to be against it until someone disagrees, then it's all "this guy is why authoritarianism is needed, now hand me that banhammer for a minute."

This repo represents an early stage proposal, not a fait-acompli.

I'll just brow beat this a bit. If it's actually a proposal and not a fait accompli, by what mechanism would this be dropped @yoavweiss? Not modified, abandoned. Because if there is not a mechanism by which the entire proposal is scrapped then it is a fait accompli.

Also, it sure looks like Google is already beginning to prototype this on Chromium. Which begins to call into question whether you're being dishonest or merely misled by your peers.

a big hammer to enforce it with

So far all I've done is file an issue on your repo with a link to your (now deleted) comment. No bans, no censorship. You've deleted my issue and deleted your comment. I just can't figure out what angle i'm supposed to view your strawman from for it to make sense.

a big hammer to enforce it with

So far all I've done is file an issue on your repo with a link to your (now deleted) comment. No bans, no censorship. You've deleted my issue and deleted your comment. I just can't figure out what angle i'm supposed to view your strawman from for it to make sense.

@scanlime: Suggestion: Add "anti-code-of-conduct" to solidify this project's pro-abuse position (Issue #1)

Also @scanlime: "All I did was file an issue and link to a comment!"

I can't fix your issue. We can agree to disagree though. Have a great day.

@yoavweiss maybe you could respond to the feedback instead of just closing every issue and saying our feedback is unprofessional?

This is not my proposal. I'm here as chair to make sure this remains a professional working environment. I left open mostly the issues which I think the team working on this proposal should reply on. I closed the issues that were not actionable, spammy, and counter to the code of conduct, or ones that were duplicates.

I'll just brow beat this a bit. If it's actually a proposal and not a fait accompli, by what mechanism would this be dropped @yoavweiss? Not modified, abandoned. Because if there is not a mechanism by which the entire proposal is scrapped then it is a fait accompli.

Presenting unmitigated risks that outweigh the benefits of the anti-abuse use cases, and that go beyond the status-quo of device fingerprinting could be one way of convincing e.g. the Blink API owners not to approve this proposal when it reaches an Intent to Ship stage (quite a long time from now, as it's an early stage proposal).

Also, it sure looks like Google is already beginning to prototype this on Chromium.

Code for this is being prototyped in Chromium behind a flag. That means nothing regarding this feature shipping in the future. Lots of code gets prototyped in Chromium and then modified or scrapped when the feature changes course.

Which begins to call into question whether you're being dishonest or merely misled by your peers.

Let's keep this civil.

Also, it sure looks like Google is already beginning to prototype this on Chromium.

Code for this is being prototyped in Chromium behind a flag. That means nothing regarding this feature shipping in the future. Lots of code gets prototyped in Chromium and then modified or scrapped when the feature changes course.

Which begins to call into question whether you're being dishonest or merely misled by your peers.

Let's keep this civil.

"Diplomacy is the art of saying 'Nice doggie' until you can find a rock."

• Will Rogers

I'll just brow beat this a bit. If it's actually a proposal and not a fait accompli, by what mechanism would this be dropped @yoavweiss? Not modified, abandoned. Because if there is not a mechanism by which the entire proposal is scrapped then it is a fait accompli.

Presenting unmitigated risks that outweigh the benefits of the anti-abuse use cases, and that go beyond the status-quo of device fingerprinting could be one way of convincing e.g. the Blink API owners not to approve this proposal when it reaches an Intent to Ship stage (quite a long time from now, as it's an early stage proposal).

Well, the community sure seems to think that they've provided such unmitigated risks and they have credibly called into question the purported benefits. It'd be nice if the people supporting the proposal engaged with us.

The idea that we have to wait until "Intent to ship" to weigh in seems to tilt the scales more than a tiny bit, don't you think?

Also, it sure looks like Google is already beginning to prototype this on Chromium.

Code for this is being prototyped in Chromium behind a flag. That means nothing regarding this feature shipping in the future. Lots of code gets prototyped in Chromium and then modified or scrapped when the feature changes course.

Yes, it's also exactly what I'd do if I wanted to be able to ram a feature through ASAP the moment it was green lit.

Again, we've seen google do this before. Google implementing features before they're standardized in order to leave other browsers at a permanent disadvantage is hardly new feedback.

Repeatedly google has pulled these tricks to accomplish short term goals, at the cost of community and user trust. You were warned repeatedly that such things were costing organizational credibility, and you did not listen. And now you're surprised that you don't get the benefit of the doubt? Come on.

Which begins to call into question whether you're being dishonest or merely misled by your peers.

Let's keep this civil.

No definition of civility requires that someone who thinks they're being lied to just accept it without comment.

Code for this is being prototyped in Chromium behind a flag. That means nothing regarding this feature shipping in the future. Lots of code gets prototyped in Chromium and then modified or scrapped when the feature changes course.

but it can be activated with an origin trial

Hey all, we plan to respond to your feedback but I want to be thorough which will take time and it’s the end of a Friday for me. We wanted to give a quick TL;DR:

• This is an early proposal that is subject to change based on feedback.

• The primary goal is to combat user tracking by giving websites a way to maintain anti-abuse protections for their sites without resorting to invasive fingerprinting.

• It’s also an explicit goal to ensure that user agents can browse the web without this proposal

• The proposal doesn’t involve detecting or blocking extensions, so ad-blockers and accessibility tools are out of scope.

• This is not DRM - WEI does not lock down content

• I’m giving everyone a heads up that I’m limiting comments to contributors over the weekend so that I can try to take a breath away from GitHub. I will reopen them after the weekend

Hey everyone, thank you for your patience, and thank you to everyone who engaged constructively. It is clear based on the feedback we’ve received that a bigger discussion needs to take place, and I’m not sure my personal repository is the best place to do that - we are looking for a better forum and will update when we have found one. We want to continue the discussion and collaborate to address your core concerns in an improved explainer.

I want to be transparent about the perceived silence from my end. In the W3C process it is common for individuals to put forth early proposals for new web standards, and host them in a team member's personal repository while pursuing adoption within a standards body. My first impulse was to jump in with more information as soon as possible - but our team wanted to take in all the feedback, and be thorough in our response.

That being said, I did want to take a moment to clarify the problems our team is trying to solve that exist on the web today and point out key details of this early stage proposal that may have been missed.

WEI’s goal is to make the web more private and safe
The WEI experiment is part of a larger goal to keep the web safe and open while discouraging cross-site tracking and lessening the reliance on fingerprinting for combating fraud and abuse. Fraud detection and mitigation techniques often rely heavily on analyzing unique client behavior over time for anomalies, which involves large collection of client data from both human users and suspected automated clients.

Privacy features like user-agent reduction, IP reduction, preventing cross-site storage, and fingerprint randomization make it more difficult to distinguish or reidentify individual clients, which is great for privacy, but makes fighting fraud more difficult. This matters to users because making the web more private without providing new APIs to developers could lead to websites adding more:

• sign-in gates to access basic content
• invasive user fingerprinting, which is less transparent to users and more difficult to control
• excessive challenges (SMS verification, captchas)

All of these options are detrimental to a user’s web browsing experience, either by increasing browsing friction or significantly reducing privacy.

We believe this is a tough problem to solve, but a very important one that we will continue to work on. We will continue to design, discuss, and debate in public.

WEI is not designed to single out browsers or extensions
Our intention for web environment integrity is to provide browsers with an alternative to the above checks and make it easier for users to block invasive fingerprinting without breaking safety mechanisms. The objective of WEI is to provide a signal that a device can be trusted, not to share data or signals about the browser on the device.

Maintaining users' access to an open web on all platforms is a critical aspect of the proposal. It is an explicit goal that user agents can browse the web without this proposal, which means we want the user to remain free to modify their browser, install extensions, use Dev tools, and importantly, continue to use accessibility features.

WEI prevents ecosystem lock-in through hold-backs
We had proposed a hold-back to prevent lock-in at the platform level. Essentially, some percentage of the time, say 5% or 10%, the WEI attestation would intentionally be omitted, and would look the same as if the user opted-out of WEI or the device is not supported.

This is designed to prevent WEI from becoming “DRM for the web”. Any sites that attempted to restrict browser access based on WEI signals alone would have also restricted access to a significant enough proportion of attestable devices to disincentivize this behavior.

Additionally, and this could be clarified in the explainer more, WEI is an opportunity for developers to use hardware-backed attestation as alternatives to captchas and other privacy-invasive integrity checks.

WEI does not disadvantage browsers that spoof their identity
The hold-back and the lack of browser identification in the response provides cover to browsers that spoof their user agents that might otherwise be treated differently by sites. This also includes custom forks of Chromium that web developers create.

Let’s work together on finding the right path
We acknowledge facilitating an ecosystem that is open, private, and safe at the same time is a difficult problem, especially when working on the scale and complexity of the web. We welcome collaboration on a solution for scaled anti-abuse that respects user privacy, while maintaining the open nature of the web.