W3C slaps down Google's proposal to treat multiple domains as same origin

What a weird coincidence that this would really help let's say a company that used google.com as well as google.co.uk and doubleclick.com as their "first party" set. Good that W3C stopped it.

(googler here, but this is my opinion)

I think there's a big abstraction gap between what we use domains for and what they were supposed to be used for, in a way that we shouldn't assume any ownership only based on the domain itself.

For instance you can have a number of sites that use separate domains but are owned by the same entity (N domains for 1 party). You could also have the same base domain being used for several unrelated parties, think hosting a store on Shopify (1 domain for N parties). This is so ambiguous that even inside the browser you have two different implementations on the way you handle this attribution, one for cookies and one for Single-Origin Policy.

There's a good write up about this problem at https://github.com/sleevi/psl-problems. Sometimes I wonder how the web got here with the amount of kludge that we have to carry.

Hmmm, what stops Google from doing it anyway? Chrome is the de-facto standard nowadays with every other browser being under 10% market share except Safari holding out around 20%.

The title is a bit misleading. The TAG simply noted this hasn't been thought all the way through, having all reasonable use cases covered. They didn't strike down the idea per se, just noted it hadn't been completely thought out. This is pretty much par for the course in the standards process.

Of course they want to. This way if I accept a cookie on one site, they can track me on all the sites without having to ask. It will make the ubiquitous google account unique ID even easier to set.

But I'm sure they'll say it's to lake shared login policies easier.

On one hand, W3C doesn't matter anymore. Google is the internet. On other hand there's Apple with their Safari and I have high hopes that even if Chrome implements that, Safari won't so Google will have to play by Apple's rules in the end of the day. Weird power play we are to observe.

Despite the extended verbal slap down, it's likely Google will ignore most of this feedback and ship anyway. That way, youtube.com, google.com, and double-click.net will be able to freely share third party cookies amongst themselves in Chrome even after Chrome supposedly removes third-party cookies.

Doesn't seem that different from how the web works currently, just less hacky then existing solutions. Am i missing something?

Its not like the status quo is that two separate domains run by same entity can't talk to each other.

Depending on how we define 'owned' and 'entity', Cloudflare could represent many many domains. Very anti-consumer, a situation where the biggest players win by buying up domains.

Assuming a domain name as a hard boundary for information is a disaster, imho. All of our fights over "1st party" and "3rd party" based on arbitrary names for a service is just specious, and the continued emphasis of "origin" as a "load-bearing" pillar is only due to legacy, not due to utility. The First Party Set proposal reflects a real need of enterprises and services, though the edge cases of the current solution, and complaints about the proposal, really reflect the competing demands of those who want freeflow of information vs. those fearing an expansion of the privacy violations bad actors have created. Because these extremes exist, these edge cases, the whole proposal should get shut down?

We've evolved into this silliness. Even as we see domains fading from view (address bars are really just search bars, who actually types a full domain anymore?), we are now forced to have multiple domains to reflect "relevance" of our content, thanks to SEO, naming conventions, etc. A company may have 6-10 domains, some reflecting regional customs, some reflecting a specific content focus, and some for specific segments of their customer base. While no company or publisher really _wants_ to manage all these domains (and certificates and payments), it's often forced by external requirements. First Party Sets nicely solved for some of these problems, by allowing entities to treat these various names as one surface for their own use, while still restricting external entities from access in client, allowing SEO to function as expected, etc.

Yes, some companies have managed to keep almost everything under one domain (apple.com), and some appear to not worry about how many domains they manage, as they all seem to get search relevance and share information (google.com)... but in the real world, we are now in a place where, at a certain scale, multiple domains are often helpful, and in some cases, necessary.

The First Party Sets proposal gave companies the ability to treat their interactions consistently no matter the domain name, which is exactly what any user would expect, and it also protected privacy, by revealing that multiple entities are under one roof (in case you didn't know that Verizon owns AOL sites like TechCrunch). Users shouldn't have to care what domain name they are on, it's the entity that matters, both for good (happy to not have to login AGAIN) and bad (What? These jerks control this site? I'm outta here!).

The comments in the proposal highlight some edge cases where bad actors could permeate privacy protections, but a) they are solvable with revisions, and b) highlight the bluntness of many of our current attempts at privacy protection via "domains".

I expect some aspect of "cross-domain" entity identification will continue to be proposed, and I expect the browsers will add it, even if W3C doesn't accept it as a standard. This corner we've created has some benefits, and controls on rampant data-spewing are welcome. But we don't need to keep building on every legacy aspect of the web: Flash is gone. We don't use the <blink> tag. We don't use RealAudio for streaming anymore. And we don't need to assume that a domain should be a boundary for the entity owning it.

(minor edit: I really need to do better with where I put commas)

I have a reverse problem. My platform has multiple forums represented as domain/forumname, each owned by different users. Now because most integrations go off domain, it is impossible for individual forum owners to plug-in 3rd party services (analytics, ad networks etc.) for themselves.

I'm not sure why this would be such a big deal for Google.. I know they might be communicating between .co.uk <-> .com etc.. But apart from that, why would Google benefit so much from this ?

I thought you have the new Storage Access API for sharing (third-party) cookies between domains? Why can't they use that?

This is a massively misleading headline.

First the issue is some recent changes by browser vendors that break the semantics of the web in the name of privacy:

What safari did was to ban cookie loading in framed origins if they weren't sub-origins of the parent. Basically they are forcing a frame-ancestors policy that is impossible to opt-out of, so if you are running a mashup, say on foomarket.com and you want to have different vendors vendorA.com, vendorB.com each have an iframe, then this will no longer work in safari as vendorA.com iframe wont send cookies back to vendorA if the site is framed.

The justification for this was the invented term of calling vendorA's cookies "third party", even though a framed site has its own window, it's own document and is a first party origin in the browser. Safari then decided if the framing origin is not a parent of the framed origin, then the framed origin will be labelled "third party" and it will not be able to send cookies back to its own origin. In other words, they crippled iframes, breaking websites that rely on iframes and the same origin policy for content isolation, especially for content isolation of authenticated domains. This is used in mashups for dashboards, vendors, multi-tenant pages, etc.

What Google is trying to do is to have a list of origins that the framing page can publish for which web-semantics would be preserved and iframes could do all the things we expect iframes to be able to do: run scripts, load cookies, etc, respecting the same origin policy of the frame rather than having the origin of the parent applied to it. This is iframe behavior since iframes were created up until 2019 when Safari redefined iframes to not be first party origins in the browser. Google's proposal is a completely reasonable solution that restores the viability of iframes as content isolation security mechanisms - presently the only content isolation security mechanism available in the browser that allows two origins to coexist without interfering with each other in the same browser tab.

The alternative is to force vendorA and vendorB to become subdomains of foomarket, so they would be vendorA.foomarket.com, etc. In the case of subdomains, apple does allow the cookies to be sent. But then you have cookie overwriting attacks in which vendorA could attack vendorB by setting cookies on the parent which would be read by all the children.

Thus sub-domains do not have the clean isolation of full-fledged separate origins, which is what iframes were designed to be, and which privacy advocates at Safari decided needed breaking because they saw that a lot of public sites used iframes for advertising. But that is not a good reason to destroy the semantics of iframes as there are many sites on the internet today that have nothing to do with advertising, and which rely on these features for secure isolation. Indeed the obsession of the Safari team with fighting advertising at the expense of breaking existing corporate intranets, PAAS/SAAS offering and mashups involving multiple tenants hosted on the same parent origin is pretty stunning. You'd think their only experience with the web was browsing public ad-based sites, and that this was the only use case they designed their browser to serve. You want to have a dashboard with different data providers serving their own data in their own isolated origin? But you don't want those data providers to send data anonymously but only if you are authenticated to their origin? Too bad, Safari thinks you are the Buzzfeed front page with one pixel trackers and that is the only use case they are designing their browser to support. You want to have a site studio where you load a website you are building in a frame and have it still run properly, without being able to interfere with your studio? Too bad. You want a municipal site where city vendors or authorities frame in various monitoring/reporting sites in a central command center, all framed in but with strong site isolation? Too bad. Want a content origin for html content to render but have it not be able to affect your own origin? Too bad.

There are many business sites, secured sites, multi-vendor sites that have nothing to do with advertising and rely on iframes for security isolation of authenticated data, and these sites no longer work with safari. Google is trying to make sure that these sites still work. And the Register -- another advertising based site -- is enraged by this.

HTML is no longer an advertising-first technology, and breaking existing frame-origin semantics in order to wage a war on advertising is not going to fly, regardless of the army of privacy warriors who have no interest in supporting more advanced use cases beyond front-page blogs. What will happen is we'll go back to the old days of all non-advertising sites requiring Chrome to work, much like corporate/government sites were built in IE in the 90s. And the sad thing is that this is because the other browser vendors are intentionally breaking existing web-semantics, not because Chrome is embracing/extending with new semantics.

"One Cookie to rule them all, One Cookie to find them, One Cookie to bring them all and in the domain bind them. In the Land of Google where the Browsers lie [to you]."

From "Don't be evil." to "Are we the baddies ?" in less than a decade - most impressive !

How did w3c get such power to “slap down” google.

If users can’t access gmail / YouTube etc, they will be ignoring the w3c.

Another workaround if google can’t try this in chrome (it can) do cookies on a google sub domain (yt.google.com etc)