Mozilla should call for Google's removal from the W3C over this implementation of Web Environment Integrity. "But Chrome has 65% market share, what good is the W3C without them?” If Google can take unilateral action to fundamentally change the basic principles of the web, then the W3C is already useless. This will give Google a clear choice: if they want to maintain the idea that the W3C matters, they should withdraw this implementation.
It is unbelievable that over the course of 3 days, the potential future of the web has been put in such dire straits. There's already an existing, far less troubling (while still bad), proposal in the form of Private Access Tokens going through a standards committee that Google chose to ignore. They presented this proposal in the shadiest way possible through a personal GitHub account. They immediately shut down outside contribution and comments. And despite the blowback they are already shoving a full implementation into Chromium.
What we need is real action, and this is the role Mozilla has always presented itself as serving. A "true" disinterested defender of the ideals of the web. Now is the time to prove it. Simply opposing this proposal isn't enough. This is about as clear and basic an attack on what fundamentally differentiates the web from every walled garden as possible. If someone drafted a proposal to the W3C that stated that only existing browsers should be allowed to render web pages, the correct response would not be to "take the stance that you oppose that proposal," it would be to seriously question whether the submitting party should even participate in the group. Make no mistake, that is what is happening now.
> If Google can take unilateral action to fundamentally change the basic principles of the web, then the W3C is already useless. This will give Google a clear choice: if they want to maintain the idea that the W3C matters, they should withdraw this implementation.
It's pretty generally accepted that the correct way to do web standardization is for proponents of some new thing to implement that thing and deploy it and then once it has been shown to actually work bring a spec to the the standards folks for standardization.
That usually works fairly well, although sometimes if that first pre-standard implementation does too well the original implementor may have trouble replacing theirs with something that follows whatever standard is eventually approved, because there are often significant changes made during the standardization process.
An example of that would be CSS grid layout. That was a Microsoft addition to IE 10, behind a vendor prefix of -ms-. Nearly everyone else liked it and it was standardized but with enough differences from Microsoft's original that you couldn't just remove the -ms- prefixes from your CSS and have it work great with the now standard CSS grid.
It was 4.5 years between the time Microsoft first deployed it in IE 10 and it appearing in other browsers by default (Chrome had it within a year of Microsoft, and Firefox had it about two years after that, but both as an experimental feature the user had the specifically enable). In that 4.5 years enough sites that only cared about IE were using the -ms- form that Microsoft ended up stuck with that on IE 10 and 11 instead of the standard.
> It's pretty generally accepted that the correct way to do web standardization is for proponents of some new thing to implement that thing and deploy it and then once it has been shown to actually work bring a spec to the the standards folks for standardization.
- Behind dev flags
- And then wait for consensus
- And then there have to be at least two independent implementations
And only then does this become a standard.
Chrome doesn't care. They create a semblance of the spec, create a semblance of a discussion, and then enable it APIs in Chrome. And then pretend it's a standard.
This links to the chromium repo where it is behind a dev flag.
They do origin trials (behind flags) for all new features. They still release a bunch of them later without any consensus etc.
Sure, but not all (or even most) chrome features are web standards, so it makes sense that those are deployed without consensus, because there isn't anyone to get consensus with.
https://news.ycombinator.com/item?id=36884155
And this particular feature? They want to pretend it's s standard. You don't create a spec proposal for a feature you don't just develop internslly
Yes and the standard development process starts by designing a spec proposal and testing it! That's the first step. If the proposal ends up not being implemented, the implementation may be removed, but you still need the implementation to write the spec, that's more or less how WHATWG works.
All of the following are true statements:
- Not all chrome flags are related to spec proposals
- Not all spec proposals are related to chrome flags
- Not all chrome-led proposals are finalized
- At least one browser must implement and test the proposal before the proposal can really be considered, and multiple other browsers must implement it before it can be accepted.
And yet, we've seen many such proposals go through this process because Chrome is paying lip service to it. Whatever Google wants it ships. And Google wants this.
As an adjacent (ads- and tracking-related) example: Google's FLoC flopped, hard. So they immediatey shipped the replacement Topics API [1] despite there being no consensus. E.g. Firefox is against [2] (but Chrome presents Firefox's position as "No signal" in the feature status). And despite the fact that its status is literally "individual proposal, not accepted" [3]
Do not assume any good intent on Google's part when it comes to Google's business interests. Their intent is always malicious until proven otherwise. And there have been fewer and fewer cases when they have been proven otherwise.
[1] https://chromestatus.com/feature/5680923054964736
[2] https://github.com/mozilla/standards-positions/issues/622