W3C doesn't really have any real power over what happens in the internet today. It's browser vendors associated with WHATWG that draw the straws now.

Given Chrome's market share, that is mostly Google.

The irony that IE fighters are the same that helped Google reached their position, because "developer tools" and "don't like FF UI changes".

Now don't complain, how is it again? Ah, Chrome is available as open source so it isn't comparable to IE.

Chrome is obviously better than IE. Not just based on open source Chromium but generally easier to work with.

I use Firefox because the addons are superior but even if we traded a downright terrible browser dominating the web for a somewhat crappy browser dominating the web, it was still a good move.

Chromium is open source, not Google Chrome.

And much of the documentation about Chromium and V8 is not public.

> And much of the documentation about Chromium and V8 is not public.

Nearly all the documentation is public... Private stuff is mostly accidentally created google docs where the engineer has selected "anyone within google.com with the link" instead of "anyone with the link". Anytime I request one of those documents be opened up, it has been done within a matter of hours.

Former V8er. We moved the vast majority of V8 documentation to public sites. What is non-public is mostly design docs, proposals, strategy, experiments, etc, i.e. the inner workings of the team mechanics. The technical details of V8 are not secret in any way. They may be radically complex, but not secret.

Keeping proposals and design documents private is essentially the same as making a project "source available". It prevents people from participating in the extension of functionality and limits them to being bug fixers.

What Microsoft is doing with .NET is true open source where all proposals are being discussed in public with volunteers improving proposals and suggesting new ones.

> Keeping proposals and design documents private is essentially the same as making a project "source available".

Nah. There are plenty of contributors to V8 that are not part of Google. IBM and MIPS and ARM all contributed significantly to specific machine ports, and we had no trouble keeping them abreast of changes and plans. There are several people who have contributed from Igalia as well. And that's just the people I can think of.

It is harder to contribute to V8 than other open source projects. You have to accept a contributor agreement and use the Chromium code review tools. V8 is a big codebase and slow to build, but it's nothing like what you say.

Correct, that doesn't change the arguments that were being pushed around as defence why Chrome isn't IE.

Indeed, and an advertising company also happens to be the dominant browser vendor.

We're quickly approaching the third "E" in "embrace, extend, extinguish."

Yep, Google had already gone ahead with this anyway.

> Google has already implemented both First Party Sets and SameParty cookies in Chrome 89, the current version, where they are included as an "origin trial" to "allow developers to try out new features and give feedback."

well I mean if Google shipped something in the browser that is now pretty much the only option that really helped their other business interests without getting standards imprimatur that might end up being anti-trust fodder.

Why do you think Firefox isn't an option? Firefox is great.

for the purposes of anti-trust law somewhere around 3% market share isn't really considered an option.

Firefox when combined with Safari are a formidable opponent to Google’s monopoly. The First Party Sets standard couldn’t be forced through because Firefox and Safari wouldn’t accept it.

Until Google implements the behavior and applies it to their sites. Then Google services stop working smoothly on Firefox and Safari because the shared session on those sites is only functional on Chrome. Imagine having to log into gmail, calendar, drive, etc. individually each time. In theory it's not that big of a deal, but in practice could end up driving the casual users to Chrome since the tools they use work better in that browser, and ultimately they don't care which icon they click to check their email.

And it'll be worse if other services decide to apply the new cookie strategy to their services, though they are definitely less inclined to do so than Google would be.

Even Google probably doesn’t want to fuck over 33% of users in Germany. And considering iPhone market share in the US, the same might go there.

And as a fun fact: Edge (12.62%) moved past Safari (11.24%) on Desktop in Germany.

Hopefully! But I also have to look at how well Google Hangouts works in Firefox, and how well Zoom meetings work in browsers at all, and consequently limit my faith that marketshare is a heavy determinant in client behavior.

Google doesn't care if Safari and Firefox don't accept something. See https://webapicontroversy.com

They will release it and then will engage their network of developer advocates and business representatives to try and make developers pressure Apple and Mozilla.

Just some examples of one such rhetoric: https://twitter.com/slightlylate/status/1191027005342404608 and https://twitter.com/slightlylate/status/1369773901610250240 and don't forget, what's missing is your advocacy: https://twitter.com/slightlylate/status/1360364259088027655

These are add-on features, not core cookie functionality.

I’m glad Google pushed a Web USB and Web Bluetooth. I use Web USB / Serial for a browser based microcontroller debugger. I use Web Bluetooth through the Bluefy app to control some Bluetooth devices without App Store apps.

Firefox’s excuse that “security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent” is infantilizing its users.

I’m a Firefox user, but I have Chrome installed for Web USB. I’d rather a feature exist controversially than not at all.

> "excuse", "infantilizing users"

Where have you been for the past decade? Users provably don't understand security implications of their choices

The entire ad industry in its current form, the entire tracking industry exist solely because of that. Users routinely allow malicious apps full-system access just because those apps ask nicely.

I'd rather not have features than have them rammed through by a company whose only claim on profitability is running ad networks in a web they increasingly control.

And yes, the "core cookie technology" that Google proposes only makes tracking easier.

They have a low market share now, but there's really not much of a barrier to switching. So if Chrome does still go through with implementing this, people can hop right on over to Firefox.

The barrier isn't just on the user side. The initial phase of government sites – i.e. web sites where the vast majority of the public are required to use to do official things — were designed with Internet Explorer in mind exclusively. Now many gov sites officially support Chrome as the default, and sometimes mobile Safari. Right now Firefox is at 2.7% [0] of us.gov visitors, almost half that of Microsoft Edge.

The average user, especially those in business/professional settings, are going to keep Chrome as their default for a long time, even if FF becomes equivalent or even superior.

[0] https://analytics.usa.gov/

So is Opera

Unfortunately Opera is also Chromium-based now, as are a growing number of browsers (edge was the nail in the coffin)

It's also owned by a Chinese company so no guarantee about backdoors for the CCP since it's not fully open source.

Chrome is owned by a US company, so no guarantee about backdoors for the NSA since it's not fully open source.

Correction: it's the single browser vendor that draws the straws now. And it's Google. They've literally stopped caring about any objections to any of their proposals and just ship them.

Just look at Project Fugu. Google is putting the implementation first, the spec to "standards wash" their implementation comes later. And if WHAT WG doesn't want to play along (and why wouldn't they? most browser vendors are now downstream from Chromium so they get the implementation by default) they can just leave it in as "experimental" with a "draft" spec. W3C doesn't really get a say in this.

This isn't any different than most of the internet standard development. "Rough consensus and running code". Most of the internet-drafts and RFCs start out life as prototype implementations, instead of writing specs first, experimental prototypes are developed, and the spec is extracted out of the winners.

People are acting like internet and web specs start life as a standards doc, it's iterated on until finalized, and then vendors start implementing it. That's very far from the truth, and I'd actually say harmful, as design by committee without real world experience often turns out terrible.

The difference is Chrome moves ahead anyway. This is why I'm calling it "standards-washing" -- if you take away the RFC it's no different from the browser wars era or Apple's proprietary CSS extensions for Safari back in the day.

How the standards process is supposed to work is something like this:

1. Someone creates a rough proposal. Discussion happens.

2. Someone creates a proof of concept toy implementation. Discussion happens.

3. Consensus is reached, a spec is written.

4. Other vendors implement the spec. Spec stabilizes with implementers' feedback.

How it now happens is like this:

1. Google writes feature proposal.

2. Google implements the feature behind a server-side flag.

3. Google creates training materials for developers to use the "upcoming" feature.

4. Optional: Google writes an actual spec.

5. Google either scraps the feature or makes it available without the flag.

Of course they "gather feedback" and "ask for input" but concerns from Mozilla routinely get ignored and implementation progresses regardless. It's entirely up to Google and they'll ship it if they like it. The "standard" just becomes a fig leaf.

This isn't entirely new, but the "standards-washing" gives it the appearance of being consensus-driven when in reality it's just more proprietary vendor extensions with marginally better documentation.

Google has an explicit agenda of what the future of the web should look like and they're taking Chrome down that route regardless of whether other vendors agree or not. There's nothing necessarily wrong with this, but consensus-driven or "open standards" this is not.

Contrast this with WHAT WG's promise in the early HTML 5 days: user concerns trump author concerns trump implementer concerns trump academic concerns. Google has decided that it is the sole authority on what users want and uses that to justify ignoring anyone else's concerns or objections.

This generally happens when committees are too far away from the actual development. It happens all the time at companies too with non-coding architects too. Standard setting bodies need to understand the pace of modern development, they spend way to long in the discussion phase. Once their is running code a lot of the discussion is basically over, and it's a choice of writing the spec to match what happens or browsers documenting the "quirks" with the standard.

That's not to say chrome isn't busing their market share. Even if there were more players though, it's a matter of Google gets MS/Apple/Mozilla to agree and nothing else really changes.

Right now Google does not feel the need to get any other browser vendors or really any other party besides Google to agree. They ship things that they don't even agree on internally! Their process has review points but actually acting on that feedback is totally up to the preferences of the person driving a given feature.

Do you have know of a writeup or blog post from someone involved in such actions that cites actual situations where this happened when google railroaded a new standard through?

Unfortunately, no. The closest to a writeup is this: https://webapicontroversy.com/

Chrome has running code, but generally skips the "rough consensus" step.

> That's very far from the truth, and I'd actually say harmful, as design by committee without real world experience often turns out terrible.

Google, however, actively ignores a lot of input, including full-on objections from other browser vendors (who do have real-world experience).

Designed by IE, sorry, Chrome, alone is just as bad.

Even the washing is so bad now, that it doesn't even matter:

- The spec we're discussing was "proposed" sometime in 2019. Here's a comment from WebKit on March 27 2020:

--- quote ---

I notice that this proposal still exists only in a random personal repo. Could it please be contributed to an appropriate standards or incubation group?

--- end quote ---

At sometime they did move it to the appropriate group

- WebHID that is now shipped in Chrome. They asked for Mozilla's position, and Mozilla couldn't even understand the proposal: https://github.com/mozilla/standards-positions/issues/459

And this keeps happening over and over and over and over again.

Their reaction when they are called out? When Mozilla and Safari flat-out refused to implement Constructible StyleSheets as they were spec'ed, Chrome still released them (because their own devs from lit-html relied on them), and said https://twitter.com/slightlylate/status/1220451799032877057

--- quote ---

We often lead, balancing risk/reward rather than demanding a particular point in an arbitrary process.

Leadership is rather the point of having an engine team, after all.

--- end quote ---

That is what they call "leadership".

Isn’t w3c where Apple primarily involves itself? Safari is important

It would also help a company that grows rapidly by acquisition. It's a real beast to deal with cross-domain synchronized authentication.