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

https://www.theregister.com/2021/04/08/w3c_google_multple_domains/

by kiyanwang • 5 years ago

212 126 5 years ago

t0mas88• 5 years ago

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.

Woung1938• 5 years ago

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.

dmitriid11• 5 years ago

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.

pjmlp3• 5 years ago

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.

bryanrasmussen2• 5 years ago

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.

pfraze• 5 years ago

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

JeremyNT• 5 years ago

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

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

EMM_3862• 5 years ago

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

shadowgovt• 5 years ago

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

TheChaplain• 5 years ago

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

youngtaff2• 5 years ago

Depends what sites you look at - for many consumer sites in the UK Chrome / Safari split on mobile is close to equal and 60%+ of visitors are on mobile

Chrome not being available on iOS is good from an anti-monoculture perspective but not so good from a browser feature perspective

gscott• 5 years ago

FireFox just follows in the steps of Chrome now. Whatever Google decides Firefox will just go along with it.

twobitshifter• 5 years ago

The article says that it’s already implemented in chrome but is disabled for the time being.

ThrowawayR2• 5 years ago

"Hmmm, what stops Google from doing it anyway?"

The fear of getting a smackdown for being anti-competitive and too dominant, hopefully, much like the one Microsoft got during IE's dominance a couple of decades ago.

Microsoft adopting Chrome's code for its Edge browser is a brilliant bit of jujutsu; not only do they get to join the chorus of voices that say "Google's so powerful and anti-competitive that we had no choice but to adopt their browser engine", they also cut their engineering costs dramatically for their built in browser by having a competitor pay for it.

aasasd2• 5 years ago

Exactly: I can see Chrome implementing a slightly different approach where all sites function as they do now, except anything coming Google which is allowed to do what it wants.

aasasd2• 5 years ago

(from Google, of course.)

EMM_3862• 5 years ago

They are doing it 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."

random56346• 5 years ago

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)

dmitriid11• 5 years ago

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

Are users unable to access gmail / YouTube etc now?

random56346• 5 years ago

Users will use / do what is required to access YT. Google could proxy through a google.com domain so same site cookies could be set, they could implement this in chrome and users would follow along

Daho0n2• 5 years ago

Users can't ignore W3C. Browser makers can.

This "feature" would open up for tracking using today's modern analysis systems with year 2000 privacy protections.

random56346• 5 years ago

And google hosting everything under a google.com domain wouldn’t?

mwexler3• 5 years ago

I'm not sure I understand. In the year 2000, we let any domain get access to it's cookie. In this proposal, an entity can let domains it controls have access to a shared cookie, all others are still blocked. But fair point: if I am allowed to say that I have a "relationship" with eviltracker.com, then they could get the shared cookie... But it's easy to add requirements like ownership vs partnership, or purpose-based access, or other enhancements.

So, not really as bad as you suggest, but true, some problem cases can arise.

bawolff• 5 years ago

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.

jaywalk2• 5 years ago

Two separate domains run by the same entity cannot share cookies, which is what this proposal is mainly about.

mtrovo3• 5 years ago

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

bigth• 5 years ago

Years ago, webpages loaded faster by using domain sharding. A big website I had used one domain as its primary, but images were on another domain, and there was yet another domain for resources like css and js.

gsich• 5 years ago

How is this faster?

More DNS requests, more TCP connections. At first this is purely slower.

stjohnswarts6• 5 years ago

That's an infrastructure problem. Sure you can solve it with domains, but you can also easily use other current technologies for it with no issues as well and never change the domain name at all.

hinkley• 5 years ago

NCSA was using regional DNS for load balancing in '95. I don't know who invented it but it's at least 25 years old.

swiley• 5 years ago

That's a good point, the domain should have to match exactly.

1shooner• 5 years ago

in a way that we shouldn't assume any ownership only based on the domain itself.

I probably have a naive understanding of this, but why not? In your Shopify example, users should certainly be taught that Shopify does have ownership of mystore.shopify.com (in at least the 'security' and 'privacy' areas of concern from the write-up). Likewise, entities proxying resources controlled by others through their own domains (e.g. CNAME cloaking) should take responsibility for what they are serving and how they are exposing their clients.

mtrovo3• 5 years ago

mystore.shopify.com is definitely hosted by Shopify but it's content is a totally isolated entity. You can trust laptops.shopify.com but this trust should not automatically transfer to fakestore.shopify.com. In the same way if you have a valid account on laptops.shopify.com, the browser shouldn't allow fakestore.shopify.com to emit a request and buy something on laptops.shopify.com with your valid session on your behalf, even though they're on the base domain.

You have also the parallel problem of how do you transfer the trust you have on google.co.uk to youtube.co.jp only based on the domain info you have.

This all to say that using only domain names to resolve ownership is a hard problem, since ages browsers use a crowdsourced list [1] to get around this issue but recently it proved not to scale very well, specially after Apple's move to use this list as part of their "Limit Ad Tracking" solution.

[1] https://publicsuffix.org/

dylan6042• 5 years ago

Sometimes I wonder how the web got here with the amount of kludge that we have to carry.

Really? Um, MS led the way with IE6 and all of the baggage they brought. Google took the mantle with Chrome. Ultimately, it is the browser vendors and their "interpretations" on how to handle things. Rather than working with the governing bodies (yes, they are slow), they forged ahead with their own implementations and forced everyone to follow. No browser is perfect, but the travesty that IE left us with should have been the glaring example of what not to do, but yet Google went and did it again.

The internet is nothing without the browsers. If the browsers didn't do bad things, we'd be in a lot better situation.

ampdepolymerase• 5 years ago

The standard and governing bodies has no right to demand anything. The internet is not a democracy. If they want something put the money where their mouth is. Until W3C ships their own browser engine and gets it into the hands of customers, relevance is nothing more than a nice-to-have.

zdragnar2• 5 years ago

IE6 also brought us AJAX, so there is something to be said for browser vendors implementing experimental features on their own.

The difference between nice and awful, of course, is when developers and vendors treat such features as a given without providing graceful degradation (or progressive enhancement, if you prefer) for users of other browsers.

marcosdumay• 5 years ago

That's a valid point, but as an internet user the domain is the only attribute visible to me that can determine a site's identity. So, I am pretty happy that the W3C insisted on setting the privacy rule based on plainly visible attributes, not on hidden predetermined or site informed data.

You call the current policy ambiguous, but the proposal wouldn't even ensure that all browsers block or allow the same sets of domains.

Anyway, I am aware that people use multiple domains on the most diverse ways. But it's important to have the technical behavior simple and predictable, and if Google doesn't like the consequences of the way they decided to organize their domains, well, it's their problem for them to fix, not a reason to push complicated unreliable standards on everybody.

stjohnswarts6• 5 years ago

In my opinion that's something the website owner should handle and it's a tractable problem. It shouldn't be pushed to the browser other than as you mentioned through capabilities like SOP and cookies. The way it is is fine.

parliament32• 5 years ago

you can have a number of sites that use separate domains but are owned by the same entity

Why is this even a thing? There's nothing wrong with storeA.shopify.com, storeB.shopify.com... The only valid use case is if you're somehow trying to hide the shared ownership/platform, in which case it's up to you to deal with the downsides.

mtrovo3• 5 years ago

AFAIK there are big security risks on hosting user generated content on the same domain of your parent website. That was the main reason github.com migrated individual repo pages to github.io [1]. Also shopify doesn't serve their shops on the domain of their main website, they use *.myshopify.com, I suppose for the same reason.

[1] https://github.blog/2013-04-05-new-github-pages-domain-githu...

mdoms• 5 years ago

Nothing's stopping you from using the one domain as it was initially intended.

om25• 5 years ago

Even when multiple domains are controlled by the same party, there is often no good way for users to be aware that seemingly unrelated sites with unrelated-looking brands are the same, and therefore (under this proposal) you can be tracked across them.

p2t2p• 5 years ago

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.

timw4mail• 5 years ago

That's not how it works. W3C has generally been the codifer of standards with member agreement, W3C generally has not made a standard ahead of an implementation.

Granted, XHTML was probably an example, an exception that proves the rule.

will4274• 5 years ago

No. The browser vendors left the W3C. When the final browser vendor (Microsoft) left and joined the other vendors in WHATWG, the vendors collectively sent a letter to W3C asking W3C to please stop copying and introducing errors into the standards WHATWG wrote. See e.g. https://www.zdnet.com/article/browser-vendors-win-war-with-w...

Ashanmaril• 5 years ago

I don't know how much pull Safari has. Seems like a lot of web devs don't test on Safari.

I know this isn't damning evidence or anything, but I noticed recently that the header image on front page of Thunderbird's homepage[1] has an image of the app (in a Mac window, funnily enough) that doesn't size properly on Safari[2]. It squishes horizontally, I assume due to some weird CSS implementation difference.

[1] https://www.thunderbird.net/en-CA/

[2] https://i.postimg.cc/rwWmDynk/image.png

bilekas2• 5 years ago

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 ?

jaywalk2• 5 years ago

It's not just google.com and google.co.uk, but also youtube.com, gmail.com, doubleclick.com, etc. Starting to see the bigger picture?

bilekas2• 5 years ago

Ah okay, I see.. If anything I see the potential for more domain certifiation fraud, expired domains still being attatched somhow o an entity.. but makes sense now why they would push for it.

ocdtrekkie• 5 years ago

doubleclick.com is Google's ad platform.

mwexler3• 5 years ago

It's Google's proposal, but it actually affects any entity having multiple domains. Think of publishers like Conde who have multiple magazines, or a company with regional domains (company.co.uk, company.com) or a content site set up for specific company-driven event (thecoolshow.com)... All of these would enable the entity to manage user experiences better, instead of having to do hacks, multiple logins, or other user hassles.

taylodl• 5 years ago

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.

tyingq• 5 years ago

The language quoted in the article sounds a bit stronger than that.

"we consider the First Party Sets proposal harmful to the web in its current form... this proposal undermines the concept of origin, and we see origin as a load-bearing structural pillar of web architecture."

mwexler3• 5 years ago

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)

hansel_der• 5 years ago

address bars are really just search bars, who actually types a full domain anymore?

recently found myself pasting an (local) ip(v4) address in the address-bar and being taken to a search engine - strange times

annoyingnoob• 5 years ago

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.

BiteCode_dev• 5 years ago

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.

stjohnswarts6• 5 years ago

They already have that through fingerprinting anyway. This would just be a little easier.

wdb• 5 years ago

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

BlueTemplar• 5 years ago

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

riantogo• 5 years ago

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.

om25• 5 years ago

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.

rsj_hn• 5 years ago

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.

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

Related Stories