11 ms·
W3C slaps down Google's proposal to treat multiple domains as same origin
- t0mas88 6y agoWhat 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 6y agoW3C 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.
- EMM_386 6y agoYep, 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."
- dmitriid 6y agoCorrection: 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.
- hnbad 6y agoJust 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.
- dmitriid 6y agoEven 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 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 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".
- cromwellian 6y agoThis 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.
- dmitriid 6y ago> 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.
- pjmlp 6y agoGiven 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.
- 29athrowaway 6y agoChromium is open source, not Google Chrome. And much of the documentation about Chromium and V8 is not public.
- londons_explore 6y ago> 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.
- pjmlp 6y agoCorrect, that doesn't change the arguments that were being pushed around as defence why Chrome isn't IE.
- titzer 6y agoFormer 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.
- foepys 6y agoKeeping 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.
- bryanrasmussen 6y agowell 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.
- jstanley 6y agoWhy do you think Firefox isn't an option? Firefox is great.
- bryanrasmussen 6y agofor the purposes of anti-trust law somewhere around 3% market share isn't really considered an option.
- Jaxkr 6y agoFirefox 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.
- ysavir 6y agoUntil 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.
- Semaphor 6y agoEven 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.
- pfraze 6y agoIsn’t w3c where Apple primarily involves itself? Safari is important
- JeremyNT 6y agoIndeed, and an advertising company also happens to be the dominant browser vendor. We're quickly approaching the third "E" in "embrace, extend, extinguish."
- shadowgovt 6y agoIt would also help a company that grows rapidly by acquisition. It's a real beast to deal with cross-domain synchronized authentication.
- TheChaplain 6y agoHmmm, 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%.
- youngtaff 6y agoDepends 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 6y agoFireFox just follows in the steps of Chrome now. Whatever Google decides Firefox will just go along with it.
- youngtaff 6y agoAs far as consumer usage goes Firefox is effectively dead It's rare that see FF usage above 1% on any of my customers' sites and I think it's only at something like 2% on gov.uk Of course there's a debate to be had over how much FF users blocking analytics affects the numbers but the numbers tie up with the log mining I've done too
- 0xy 6y ago
- random5634 6y agoHow 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)
- dmitriid 6y ago> If users can’t access gmail / YouTube etc, they will be ignoring the w3c. Are users unable to access gmail / YouTube etc now?
- random5634 6y agoUsers 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
- dmitriid 6y agoOnce again: are users unable to access those sites now? Why would they not be able to access them if Google doesn't implement FPS?
- random5634 6y agoFree products are generally supported by advertising. We are being told the W3C has “slapped down” googles attempts around FPS. I am making the point that if google comes up with a workaround to this “slap down” - users will follow - even if you and others are yelling “it’s not W3C”. That could be modifying chrome to allow this, it could be hosting things under one domain etc
- dmitriid 6y ago> Free products are generally supported by advertising. We are being told the W3C has “slapped down” googles attempts around FPS. You were talking about "If users can’t access gmail / YouTube etc, they will be ignoring the w3c". Now it's suddenly "free sites" and "advertising". And don't worry, advertising isn't going anywhere. > I am making the point that if google comes up with a workaround to this “slap down” - users will follow They will not come up with a "workaround", they will just implement it ignoring any objections. However, that's not the point. What was it about users not being able to access youtube etc.?
- bawolff 6y agoDoesn'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.
- jaywalk 6y agoTwo separate domains run by the same entity cannot share cookies, which is what this proposal is mainly about.
- mtrovo 6y 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 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 6y agoYears 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 6y agoHow is this faster? More DNS requests, more TCP connections. At first this is purely slower.
- hoppi 6y agoPretty sure in HTTP 1.1, there was a max amount of concurrent requests per server/proxy. So using different domains allowed more rq/s.
- diggan 6y agoBrowsers used to/still do max number of connections per domain. Adding more domains allows you to do more concurrent requests.
- kevin_thibedeau 6y ago
- p2t2p 6y agoOn 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 6y agoThat'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 6y agoNo. 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-w3c-over-html-and-dom-standards/ https://www.zdnet.com/article/browser-vendors-win-war-with-w...
- jdashg 6y agoBrowser vendor here: We're definitely still in the W3C and collaborating in a number of areas there. The WHATWG situation is complicated, but we have not "left the W3C".
- Ashanmaril 6y agoI 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/ https://www.thunderbird.net/en-CA/ [2] https://i.postimg.cc/rwWmDynk/image.png https://i.postimg.cc/rwWmDynk/image.png
- bilekas 6y agoI'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 ?
- jaywalk 6y agoIt's not just google.com and google.co.uk, but also youtube.com, gmail.com, doubleclick.com, etc. Starting to see the bigger picture?
- bilekas 6y agoAh 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 6y agodoubleclick.com is Google's ad platform.
- mwexler 6y agoIt'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 6y agoThe 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 6y agoThe 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."
- mwexler 6y agoAssuming 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)
- annoyingnoob 6y agoDepending 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 6y agoOf 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.
- stjohnswarts 6y agoThey already have that through fingerprinting anyway. This would just be a little easier.
- wdb 6y agoI thought you have the new Storage Access API for sharing (third-party) cookies between domains? Why can't they use that?
- BlueTemplar 6y 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 6y agoI 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.
- om2 6y agoDespite 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 6y agoThis 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.