Enable third party cookies for google drive

This is wrong: try downloading something with Safari, which blocks third party cookies by default, and it works fine.

Instead, the problem is that downloading from Google Drive is using User-Agent sniffing to determine whether third party cookies are expected to be enabled, and choosing between implementations.

(Disclosure: I used to work at Google, but I don't know anything internal on this)

Oh wow - so while there was a non-malicious explanation in another comment (https://news.ycombinator.com/item?id=32149130), this clearly looks like malicious behavior.

They're relying on the fact that most browsers lack per-domain cookie controls to force Google Drive users to allow third-party cookies knowing full well the majority won't remember (or bother) to disable them after.

The explanation in the other comment is also correct. When you go from drive.google.com to googleusercontent.com to download a file, this historically worked by using third-party cookies to verify that you were authorized to download the file. When Safari dropped support for third-party cookies they added a new flow which uses link decoration instead, but only use this flow when they think the browser doesn't support third-party cookies. Their "does this browser do third-party cookies" logic isn't very good, and doesn't handle Chrome without third-party cookies.

I'm not sure why they don't use the new flow for everyone. My guess is that it's less secure? Maybe that if the link they generate is shared it gives access beyond what the original owner chose to share?

>I'm not sure why they don't use the new flow for everyone.

It's less secure, slower (more round trips), and more server side intense - likely considered a hack. Effectively it does the same what a cookie would. The 3rd party cookies are not a bad thing per se, it's just that they have been abused to hell and back, is what causes their reputation.

I don't think it has to be. They could make the request as an ajax request with an Authorization header. Of course that makes the frontend more complex as it as to do some gymnastics to treat the response as a download.

Tried it, wouldn't recommend it. The file data would be stored in the browser tab's memory. It usually ends in crashes.

I don't fully understand why they need to use a separate domain for this at all. There is infinite URL space available on drive.google.com, even if Google just used a proxy behind the scenes to route those requests to whatever load balancer normally services googleusercontent.com, and that would solve the issue with third party cookies entirely... as well as several other issues, like potentially confusing users with their own files coming from a domain that isn't drive.google.com.

It's not about url space or load balancing, but security. You do not want to serve user content from your primary domain:

* Even if you serve it with the correct content type and no-sniff headers some browsers can be tricked into running JS, and then you have XSS.

* Even in modern browsers it's defense in depth, in case you mess up your configuration or they have a bug.

* If malware gets past your scanners then your primary domain can get flagged.

* It looks like it's coming from a trusted domain: a PDF that claims to be from Google Drive and where the URL bar says drive.google.com looks legit in a way that one where the bar says googleusercontent.com does not.

I guess that’s all fair, but to be clear, I’m not proposing to host public-facing content. Only private content that can be viewed by authorized users who have the right first party cookie to allow it.

Public facing content could easily be hosted on the other domain for all of the reasons you listed, and third party cookies won’t matter then.

I appreciate you outlining the arguments. I know some other sites like Dropbox do the exact same thing with a user content domain.

Content that's limited to specific users can still be used for targeted attacks, so it doesn't help very much.

It would still say “drive.google.com”, not “google.com”, and if that isn’t enough of a hint for the target, googleusercontent.com won’t be either. In fact, people have heard of Google Drive. They know that means it isn't from Google. "googleusercontent" could be "Google content intended for users" for all someone knows.

So, I disagree here. The well-known name of Google Drive as a user file sharing service is much more meaningful as a warning at a glance.

There are also mitigations that could be put in place for file sharing, like requiring the user to have accepted a file sharing request from that account before (via Google sent notification email) for a direct link to actually work. This would be a great thing to have in place regardless of domain, for defense in depth. Unsolicited links to private files arguably should not work.

Obviously people may have different opinions on this stuff.

> There are also mitigations that could be put in place for file sharing, like requiring the user to have accepted a file sharing request from that account before (via Google sent notification email) for a direct link to actually work.

That sounds pretty annoying? I upload something, give access to coder543, and ping you a link in Slack or whatever tool we use. But you can't open it until you go into your email and click through?

Maybe my phrasing was awkward, but I said you would only have to do this once for a given account. So, if I've never accepted a share from you before, your links won't work. When you share something with me for the first time, I would have to accept it via a Google-sent email containing a link that only Google knows (not something that can be sent via slack), and then all your future share links would work for me on slack. The error page denying access could even indicate that the user should check their email for additional verification.

You can think of it as the equivalent of a friend request. "This person tried to share a file with you. Do you know this person? Are you sure you want to receive files from them?"

This is not some outlandish solution. This should not be "pretty annoying". Based on my own experience, most people would go months or years between seeing these emails, since people tend to share files with (and receive files from) the same people over and over.

Moreover, in a work context, you would probably be sharing links to files that are on a shared google drive that I have equal access to already, so that would not require additional verification. It's not an unsolicited link to someone else's Google Drive... it's a link to a drive that I already have read/write access to.

Do people want to have friend requests in Google? If I wanted to share a file to your Google account, would you like to trust the future shares automatically as well? It doesn't seem like the superior alternative to just using 3rd party cookies—other than that it works if 3rd party cookies are disabled.

It also provides a new attack vector (your friends) if such people are able to create more credible documents (e.g. due to an attack, not due to a deliberate intent to mislead you).

The alternative is trusting all shared links, which is currently what Google does. Third party cookies have nothing to do with it. Having some form of revokable authorization to be able to click on links from a person is superior to "all sketchy links working instantly."

If you get a Google Drive link by someone claiming to be a friend you know, you could download malware right now, because Google trusts all of these links equally. With this mitigation in place, you would be stopped: “hey, this isn’t someone you’ve ever received files from before.” Because they aren’t actually your friend using your friend’s account which you’ve received files from before. It would add a serious obstacle to a lot of these impersonation attacks, and I see impersonation attacks all the time.

My comment awhile ago said that this mitigation would be nice regardless of whether Google kept using their separate domain or not.

It absolutely doesn’t provide a new attack vector. It strictly serves to reduce the attack surface, not to increase it.

It’s not security for the end user

It’s security for Google

Back in the day, you could upload, for an example, a specially-crafted HTML file with your own malicious JS code to, for an example, an image hosting service and basically use them to serve your attack upload. You could more or less abuse any website upload form to host any file that that you wanted. It was bad.

Browsers have drastically improved but why risk it? Using a separate domain makes a lot of scary scenarios completely impossible.

Using a separate domain for user generated content is usually done for security reasons. For example, if a user-generated chunk of JavaScript was executed from drive.google.com, then it could potentially gain access to your drive.google.com, or maybe even *.google.com, authentication cookies. Scripts running on an unrelated domain have no such access.

This usually isn't the only thing protecting against this, and is instead used as an additional safeguard.

I believe Google's use of this practice also predates widespread support of Content Security Policy, which isn't to say that this is a useless practice, but perhaps it isn't as important as it used to be.

Native browsers tend to flag any files they download with information on what domain the file came from, so it's also relevant in that case. Windows and OS X will pop up a warning when opening untrusted files, so whether the user sees 'google.com' or not could be important.

> I believe Google's use of this practice also predates widespread support of Content Security Policy, which isn't to say that this is a useless practice, but perhaps it isn't as important as it used to be.

Perhaps not, but I still think it's quite worthwhile to defend against CSP-related browser bugs, or even a botched infra change on Google's side that accidentally drops the CSP header.

Yes, that's exactly what I mean by it not being useless. If everything is working perfectly, then perhaps ends up not doing anything, but it's good to have another line of defense for when things go wrong. It's the safety net for when someone messes up CSP.

> I believe Google's use of this practice also predates widespread support of Content Security Policy, which isn't to say that this is a useless practice, but perhaps it isn't as important as it used to be.

I agree completely.

I'm no fan of google but I have an inkling it was set up like this before Safari decided to block 3rd party cookies and for your answer why they didn't immediately consolidate into one domain? Google operates at a scale you probably can't even comprehend.

Embedding the authentication in the link is both a security risk and more complex than simply relying on the cookie.

They could have opted to do what Twitter does: Leave everything accessible wide open even if the file was created in a private context such as Twitter DM:s

Locking down access to static files that you ideally would like to serve and cache straight from storage is a tricky thing in regards to performance, security and maintenance complexity.

It seems obvious to me why they don't use that for everyone, and it has nothing to do with security.

I don't really agree (and I'm happy to bash on Google).

This is basically the poster child for a case when someone should be using 3rd party cookies: A single entity manages multiple domains and shares cookie auth across them.

It's not like the other flow is somehow making you less identifiable - they're literally just passing the same information in a more round-about, less usable manner.

I genuinely think the current approach of blacklisting everything with essentially no recourse to enable a fine-grained whitelist related to cookies going to an alternate domain is fundamentally web-hostile.

The web worked because you could link to 3rd parties. We're currently throwing the baby out with the bath water because our government is dysfunctional and unable to regulate tech privacy.

> This is basically the poster child for a case when someone should be using 3rd party cookies: A single entity manages multiple domains and shares cookie auth across them.

If everyone would use 3rd party cookies like you're describing, there'd be no issue with users enabling them. Instead, they're frequently used to track users across domains, and the alternate flow used for Safari should be the pragmatic option used for everyone.

You're right to complain about how we're basically unable to use an otherwise-useful feature because of bad actors. It's a signal that core web technologies need to be created with potential abuses first and foremost.

> It's a signal that core web technologies need to be created with potential abuses first and foremost.

No. This is how absolutely everyone ends up with the shittiest version of everything.

We need recourse and a general legal expectation that you DON'T abuse your users.

Honestly - that attitude is exactly the problem: You're letting bad actors literally ruin the web, because the US government is unable to pull its fucking mouth out of the feed trough (or honestly do much of anything at all, right now).

We don't take that stance for literally ANY other industry: You can buy a gun, but guns can kill people. You can buy a car, but cars can crash. You can get a dog, and that dog can bite people.

The answer is not "Ban it because it might be bad". The answer is to properly set expectations that abuse will be met with heavy penalties.

This is not fucking Minority Report, and we shouldn't be trying to "precognition" all the bad out of the world. We should address it head on, and fucking burn the bad actors to the ground.

It is possible the US government lacks the reach to do what you've described, given how much organized crime is centered in other nations.

But I agree with you overall... Much of the web's concept of privacy and security is baked in with the assumption that it must be technologically enforced because it can't be legally enforced. Change that math and you change the model.

While I agree that we direly need privacy legislation to stop openly chartered surveillance companies from tracking us through whatever means, your position doesn't work for computer security in general. The only way "accountability" works for computer security is if every node on the network carried an inescapable real world identity that is responsible for its network traffic, which would be much more of a draconian regime than you are arguing against.

> If everyone would use 3rd party cookies like you're describing, there'd be no issue with users enabling them

Okay, but this thread is about the right use of them.

> A single entity manages multiple domains and shares cookie auth across them.

The issue is we (the users) really want a more nuanced concept of "third party": something like "different domain that's controlled by the first party."

Unfortunately, any declaration that relies on the first party will immediately be abused to hell ("All these tracking domains are controlled by me, so plz allow them!"), and we'd be right back here.

It feels like a problem that needs something like DNS (query & response), but probably just needs a fundamental rethink of what a cookie is.

Neat! It feels like cryptographic attestation by the child/secondary site would be less subject to abuse.

I.e. proving they have access to the same private key used to sign the parent, which would by definition not be something the parent would willingly share with random third parties

I think you're falling into the same trap.

Some things are not solved in the appropriate manner through a technological solution.

They are misuses (and abuses) of a perfectly acceptable system. Don't undo the system, address the misuse.

Take your example:

>Unfortunately, any declaration that relies on the first party will immediately be abused to hell ("All these tracking domains are controlled by me, so plz allow them!"), and we'd be right back here.

The only reason this is the case is because this misuse has zero consequences.

Make them declare their domains, if they choose to include tracking domains, fine the ever-loving shit out of them. Not the ".05% of yearly profit" bullshit - I'm talking 200% of daily revenue for the top controlling company for every day that domain was on the list after it was declared a bad actor. If the company can't pay? Fucking nationalize them, remove the tracking domain, sell it to the highest bidder.*

Watch how fucking fast these companies will scramble to fix the problem when the stakes are real.

When the stakes are trivial - it doesn't matter what technology you try to put in place to block this, they will just work around it.

* I understand this is ridiculously extreme, but I'm done playing with these fucks. We've had the gloves on for the last 20 years, it's time they come off.

What is the definition of what is "really" "my" domain?

If I put a custom domain on an S3/cloudfront that's part of my system, so it appears as `storage.mysystem.com`, is there something nefarious going on?

Who decides what is allowable declaration of a domain to be mine? And who enforces this with fines? Is there currently any way to fine someone on the internet for violating a rule? What would you imagine this looking like, an organization that has the ability to fine people globally, and enforce the payment of those fines (by... taking domains back I guess?), and who would control it? (and who would pay for it, how?) It's a lot of global legal infrastructure we don't really have now, I think. It would be a pretty huge step.

> Who decides what is allowable declaration of a domain to be mine?

Basically, there is a list included in all browsers: https://wiki.mozilla.org/Public_Suffix_List. That's why you.github.io can't read other github.io cookies, but if you make your own domain, you can share cookies between a.example.com and b.example.com. (Also why example.com can't read .com cookies.)

> Is there currently any way to fine someone on the internet for violating a rule?

Many governments do this. In the US, the FTC has fined a number of companies for things like supercookies: https://www.ftc.gov/business-guidance/blog/2012/08/milking-c...

I don't think we're talking about the same thing.

I understood that the conversation was about attesting that, for instance, googleusercontent.com was owned by the same entity as google.com so could share cookies.

A) I don't see any way that the list included in browsers of public suffixes makes it possible to decide that google.com really owns googleusercontent.com. If it did, we would already be there and woudln't be discussing this.

B) Who do you think makes the public suffix list in the first place, where do you think it comes from exactly?

> This is basically the poster child for a case when someone should be using 3rd party cookies

It is kinda funny that Google, among others, are the reason why we can have 3rd party cookies. Now they have a services that has a legitimate use-case and can't rely on 3rd party cookies being available and have to revert to work-around.

> fundamentally web-hostile.

Sniffing the user agent is fundamentally web-hostile!

From my understanding of how these decisions were made inside Google, it's very likely to be one of:

* Security: as described above

* Efficiency: the method used for Safari requires more server resources

* Performance: the method used for Safari is slower

What is the reason that seems obvious to you?

> What is the reason that seems obvious to you?

The reason he's thinking of is that they want to annoy people into enabling 3rd party cookies for tracking purposes, with security/performance/etc. as the excuse.

Except their instructions are specific to whitelisting the exact subdomains in question - they aren't telling you "Enable 3rd party cookies".

Can you whitelist third-party cookies for a specific set of domains in any mainstream browser? To the best of my knowledge you can’t.

You can absolutely do this in any Chromium based browser.

Go to settings, check "block 3rd party cookies"

scroll down to customized behaviors, click "Add" next to "sites that can always use cookies"

Enter the domain you want. Before saving, make sure to check "Including third-party cookies on this site".

--

Or, ya know, read the instructions in the link on this post telling you to do exactly this for drive.google.com :P

I saw the efficiency/performance claim a bunch of times now. How is using a cookie over say the same data embedded in the requested URL or transmitted as form-data supposedly more efficient? The server still has to check the auth, no matter what part of the request it extracted the auth data from. Or am I missing something here?

As for security, yeah, there are some good reasons for not embedding auth info in the link (tho one could still POST the same data instead without a third party cookie, etc), as well as for having a dedicated domain for user content.

The assumption is that every single thing Google does is a dark pattern to track you.

In this case you are probably right, but surveillance is Google's business model.

Not sure if it's still the case, but a while back google docs complained that because I wasn't using chrome some features weren't supported. After changing my UA to chrome, the banner dissapeared and as far as I remember the features it said were "unsupported" worked fine.

I'm not sure if blocking third party cookies is the cause, but I have had difficulty downloading files under Firefox. Disabling third party cookies is one of the first settings I enable after installing Firefox.

I would not be surprised if Apple makes an exception for Google.

> I would not be surprised if Apple makes an exception for Google.

Apple doesn't, which you can verify with developer tools in Safari.

No point disabling them now due to Total Cookie Protection by the way. All 3rd-party cookies are isolated to the 1st-party domain they're obtained from.

I don't think this is the issue. I use Vivaldi, blocking third party cookies by default, and I was unable to download before I disabled third party cookies temporarily.

How is it wrong? And if safari does it without cookies, why not chrome?

Chrome is used by 65% of people, safari ~15% (<10% on desktop)

I believe they're suggesting some code is executed based on the user agent. So Safari gets treated differently. Safari is defacto zero 3rd party cookies but Chrome isn't which is possibly why that site is treating them different.

Honestly anyone concerned about a Chrome / WebKit browser monopoly needs to use Firefox now if you already are not.

At this stage, I think we can draw a line between WebKit and Blink, so even having more WebKit based browsers would be a welcome change.

I'd still prefer to see a mainstream Gecko based browser, of course! I think outside of the tech crowd FF is pretty niche.

What are your thoughts on brave browser? I’ve used it over firefox for about two years now and I really enjoy it.

Brave is just chrome underneath so you’re definitely not helping to browser diversity.

I'd love to, but it's simply unusable compared to Chrome when it comes to web development.

I have not found any shortcomings in Firefox for web development, so I'm wondering if you could you elaborate on what features are missing, or what killer features for web development Chrome has that Firefox doesn't?

Development console in Firefox is lacking compared to Chrome's. Also, the whole Firefox browser is massively slower. There have been benchmarks that prove what I'm typing here, I can't give you a definite list and I see that people started jumping on the downvote hammer so I'm not inclined to defend my opinion. It's my experience, and if someone else's experience differs - I'm glad for them.

Also a massive vulnerability surface letting arbitrary websites write whatever they want to your disk.

Definitely not. You have to explicitly select a directory from a native file system UI then confirm both read and write access for each directory, across each domain, typically each session. And system directories are blocked outright with no way to override.

This attitude is why people dismiss Firefox: “well if FF doesn’t implement it, it must be bad. Other browsers surely have glaring security holes”

(Source: I implemented the file system integration for vscode.dev)

AFAIK Firefox is the only browser that does 'persist logs' in dev console right. i.e I get to see the responses of all requests whereas Chrome only shows the current page responses. Chrome has also refused to acknowledge this as a bug.

Can't do that when Firefox simply isn't good enough. Vivaldi beats it in features and what I need from browser as a power-user.

I don't see any problems with a monoculture of rendering engine.

Browser (and features, especially privacy ones), absolutely. Renderer, not so much.

Have you ever used a service in life where there is no competition?

Straight up lack of competition examples are the easiest: DMV, airport food court, buying beer at a sports stadium etc.

If you work in tech then you’ve probably had to use software over whose purchase you had no control: Jira, PeopleHR, Taleo, Concur. There’s no competition there because you, the end user, don’t have the option to choose from a free market. For the vendor, the software doesn’t have to be any good as long as the sales pitch to you boss is amazing.

Without competition, software rots and/or never gets better. What examples are there of monopolies in Free software that caused a product to languish? OpenSSL, Python’s logging module, systemd since it was locked in as the only properly supported Debian/Ubuntu init, pre-Chrome Firefox/Mozilla, post-GMail Thunderbird.

What examples are there of corporate-sponsored software that languish without competition? Internet Explorer is the classic example but if you think Google are better than Microsoft, at heart, then how’s Android working out for us all in terms of excellence-in-the-void-of-competition?

> Without competition, software rots and/or never gets better. [...] systemd since it was locked in as the only properly supported Debian/Ubuntu init

To be fair, systemd was rotten to the core from day one (literally - namely, the core concept of shoving as much crap into pid 1 as possible to abuse the special semantics that are supposed to only allow for reaping of orphan processes), so you can't really blame that on lack of competition.

Your overall point is spot on, though. (And I suppose you could blame lack of sufficiently direct/credible competition for Debian being able to shove systemd down everyone's throats, rather than being forced to support multiple init systems.)

the vast majority of systemd's codebase runs outside of PID 1. what does systemd actually run in PID 1 that you object to?

The argument needs to be more subtle to make sense, since Blink is open-source, whereas IE was not. Contrarily, I see another analogy; Blink being like Linux's dominance in infrastructure.

The Linux Foundation aren’t trying to develop Linux to cement their advertising business. The Linux Foundation are benign, and Google aren’t.

We are talking at cross purposes: your comment is a reasonable refutation of a browser monoculture, something we agree would be bad.

FWIW I am typing my response to you in Graphene.

Ultimately the issue is: what is the harm in using a library maintained by Google to do the webview rendering in a non-Google browser? I just don't see it.

Google can do pretty much whatever it wants when it's the only player in the space. It certainly hasn't been shy about doing things outside of a standards body. Sure, it's open source, but can you meaningfully influence the direction of the project? If you decide to fork and deviate from what stock Chrome is doing, you're apt to be locked out similarly to sites that don't support Firefox or Safari.

It looks pretty similar to what MS was doing with IE, just with a dash of "here you can skin this thing". The biggest differences being that Google has a strong interest in ensuring the web is the app platform of choice, rather than a desktop OS. On the other hand, Google needs to sell targeted ads, so it's unlikely to be the standard bearer for web privacy.

If Google has a monopoly on the rendering engine, who decides what the future of web rendering looks like? Google, and nobody else.

The problem is that you are giving full power for creating de-facto standards to the rendering engine.

If Blink decides to support a feature, it becomes a de-facto standard even if the feature solely serves Google (think FLoC, AMP ...) or is hard to replicate.

It's also an issue because now the web is at risk to become only usable from devices that are physically able to run Blink/Webkit which means nobody in the future will be able to create a new useful device/os that cannot run Blink or Webkit.

It's also an issue with the good ol' technical debt : what happens when Blink/Webkit become a total mess full of hard to patch vulnerabilities or google/chrome specific code ? You basically cannot rewrite it from scratch unless you have the engineering power of a GAFAM.

There are tons of reasons why having a monoculture of rendering engine is an issue.

Neither FLoC nor AMP are part of the renderer. AMP isn't even clientside, it is a feature of the Google search webapp.

If Google were trying to leverage the renderer to assert Chrome over say Brave or Edge, sure, but they're not, and if they do, it will be forked.

Do we have the same concerns over type layout engine monoculture?

> If Google were trying to leverage the renderer to assert Chrome over say Brave or Edge, sure, but they're not, and if they do, it will be forked.

Google has already asserted that. Brave and Edge are a footnote to a footnote to a distant appendix, and are almost entirely reliant on Google to provide the rendering engine.

We have the same concerns over any lower level components, yes. I don’t think a type layout engine is comparable to a web render.

I would prefer that an advertising company does not have majority control over the rendering engine

In general, I like to have at least two implementations to make sure multiple implementations are possible.

If the rendering engine bit-rots, goes the way of the original Netscape, Internet Explorer, etc., you don't want the internet to break.

Eh. That’s kinda like “don’t put all your money in dollars”

If the US Dollar goes to zero or the only rendering engine bit rots, other things are happening such that I won’t be too concerned about not having money or not being able to browse the web.

No, it's really not. It's more like "don't put your money in one stock," but it's much more like "architect your code sanely."

In general, if I have a modular abstraction barrier in my code, I try to have at least two implementations. For example, if I have a generic key-value store so I can switch databases later, I'll make an implementation for e.g. PostgreSQL and redis. That way, I don't accidentally couple to one or the other. Otherwise, I'm fooling myself.

That's just basic software engineering, but for open industry standards, it's really critical. You don't want CSS rendering depending on some browser bug or quirk. It's critical to have multiple implementations, or it's not a standard.

The flip side of allowing multiple implementations also means it's possible to build things like web crawlers, screen readers, and other technologies without spending millions of dollars re-engineering IE or Chrome to be identical, bug-for-bug. It's also possible to build new things we never imagined. Indeed, we had a lot more diversity in HTML 2.0 days, when things were simple enough that anyone could build a novel web technology over a weekend (with full HTML 2.0 parsing).

(Before I get accused of over-engineering, I usually don't have these types of modular abstractions; if I don't expect to ever swap databases, I'll e.g. code to PostgreSQL directly

> I don't see any problems with a monoculture of rendering engine.

Remember IE6 ? That's what we get with a monoculture.

Forget the monopoly part, the reference to IE6, all that stuff. Let's say we don't care about that. What happens when the Chrome rendering engine has a security bug, a big one, a zero-day? That's the issue we had with OpenSSL, suddenly 90% of the Internet er vulnerable and there are no alternatives until Google fixes the bug.

Given the complexity and feature set of a modern rendering engine I don't think it's to fare fetched. I like the entire Internet not being vulnerable all at once.

Chromium is such a big deal, that it also easily twists the arm of standardization bodies like the W3C.

If a private party can do as they please and have such a strong say, why bother with standardization bodies?

So why not just get rid of all browsers and have only Microsoft Edge then? Because that is the problem you end up with a bunch of proprietary features that only whoever maintains the main browser rendering engine has and everyone on Linux and probably Mac has to suffer for it.

I'm not sure how anyone can believe this after seeing Android. Google's modus operandi is to make the open core less and less functional over time after everyone has migrated to it, and then put the useful stuff into their proprietary version (Google Pixel, Google Chrome).

You've forgotten what it was like at the turn of the century. It took a long while for us to break the previous monoculture and clear the way for the innovation we've enjoyed since.

The innovation we've enjoyed since was mostly caused by Google getting tired of waiting for either Microsoft or Mozilla to improve on the browser paradigm and footing the bill to roll their own.

History doesn't really linenup with that:

Web 2.0 was based on some IE extensions that were introduced when Firefox was the viable other game in town.

Concretely, Google Maps (the poster child for AJAX) launched in 2005, and Chrome launched in 2008.

I was referring to the innovations in browser capabilities. Process sandboxing massively improved both the robustness of the browser experience and the boldness with which features could be used (because a crashing site wouldn't take the whole browser with it). It paved the way for the actual "browser is the OS for the web" experience we have today, unlike IE's attempt to wed a crash-prone application to its core OS functionality. As a result, the browser capability specs themselves exploded, which eventually rendered Flash, Silverlight, and ActiveX plugins mostly redundant and allowed browser vendors to make their way towards stripping them out in favor of web-engine-only solutions.

I think it is because they use `googleusercontent.com` for content uploaded by users - that makes sense for security reasons, never ever let users upload content to your main domain.

It's a defense in depth mechanism: when you allow user-generated content uploaded on your main domain, somebody will find a way to break your security system and make that content executable on the user's browser.

When doing so, an attacker can steal cookies, and/or invoke APIs for the user.

Now, there are of course ways to avoid that, but in the end, if every other system fails, being on a domain without any API and without any sensitive content allows reducing the blast of the impact.

Real-world example: https://gitlab.com/gitlab-org/gitlab/-/issues/200094

GitLab has APIs under their main domain. Due to a misconfiguration, it was possible to render in the browser user-generated `.svg` files. Thus, a malicious crafted SVG file could bring to a XSS, and accessing a lot of personal user data on the main domain.

There are technical reasons for the shared domain, but if that particular API call was on another domain, the impact of the vulnerability would have been way smaller.

Similarly, long time ago you could have a personal/project website on <username>.github.com. A few years ago they moved all personal/project websites to <username>.github.io instead.

Is this also another case for hosting your main site on www.example.com instead of example.com? This way you could have cookies only on www.example.com while hosting user generated content on assets.example.com or whatever sub-domain you want that's not www?

Yes and no: one thing I totally forgot to mention is phishing. You don't want to give any semblance of endorsement to user-generated contents: many viewers will check only the main domain, due to how browsers' URL bars hide stuff.

Having a total different domain help highlighting that it is not official content.

Makes sense.

There's probably some benefits around blacklists too.

For example if a user uploaded questionable content to assets.example.com/uploads, such as pirated content then someone could submit that to search engines and other lists to get your domain blacklisted. It's quite possible these blacklists could be related to the apex domain, not necessarily the sub-domain. A separate domain guarantees your apex domain won't get penalized.

How does the configuration look like (very broadly)? Is already a domain redirect helpful here?

Yes, as long as the content is downloaded from another domain, everything is good.

The point is: if for any reason (0-day, misconfiguration, bug, whatever) the content uploaded from the user is executed by the browser, instead of being "just" rendered or downloaded, it must execute in a different domain. Given domains are sandboxed by the browser, a vulnerability on domain A cannot affect domain B.

Of course, there are still way to shoot you in the foot (e.g., having the same access token in the cookies for both domains), but it's one measure more. This is why security should be layered, and you shouldn't rely on just one defense: https://en.wikipedia.org/wiki/Defense_in_depth_(computing)

Also, malware detection algorithms decrease their rating for the google.com domain when they encounter malicious content on this domain. Probably not an issue for google specifically, as they themselves control this list for Chrome, but for other companies this might be relevant too.

The title is tad incomplete.

You need to enable 3rd party cookies ONLY FOR the drive endpoint, *drive.google.com*. You can whitelist which endpoints are permitted.

They way the title is written it gave me the impression that you needed to enable 3rd party cookies globally (which is incorrect)

They specifically need to set a cookie so that googleusercontent.com knows who you are when you click a link on drive.google.com to download a file.

And from their solution:

"Type chrome://settings/cookies in the browser address bar"

I love how they assume everybody uses Chrome.

It's only broken on Chrome, though. In Safari it works fine without third party cookies.

This is interesting, are you sure your browser isn't making an exception for google drive?

You can verify that it isn't by looking in developer tools, and you will see that no third-party cookies are sent

I'm wondering why the information necessary for downloading the file can't just be encoded as a URL parameter.

When the user clicks a file download link it should be possible to generate a short lived token that authenticates the user against googleusercontent.com.

That's quite easy to do with Amazon S3. Maybe Google could just use AWS since implementing this feature seems to be a bit complex for them. /s

As far as I'm aware no browser offers granular third-party cookie permission controls - e.g. allow third-party cookies from `googleusercontent.com` but only on `drive.google.com`.

Or ublock origin, in advanced mode. I took time to transition away from umatrix and i miss the interface but it's fine.

If using linux or mac, just FUSE mount with rclone. If you need more privacy,load the mount with encryption so google has no idea about the files you are working with.

Thanks for that info. Haven't used windows in a long time, so did not want to post of something I'm not sure.

Thank you and thanks wanderingmind for sharing this! I knew rclone, but didn't know you you could pair it with a fuse mount! Looks like an awwwwwesome addition to the toolbelt :))))

Pro tip: If you want to download an image or pdf, Drive will still let you print, so you can print it to file as a PDF.

I've faced this problem in the past and it is really annoying. One of the many reasons why I dislike this service and try to avoid it as much as possible.

Seems like in this particular case, notwithstanding Google's long history of abuse and opportunism, this one is a genuine case when you enable a cookie for technical and not (necessarily) user tracking reasons.

Is it certain that Google will not use these (i.e. cookies enabled for technical reasons) also for tracking?

Some companies are requesting permissions for more or less valid reasons and later using these permissions for their own goals as well.

There's no need to use cookies for this when they control the backend. They know you're accessing a file because their server had to authenticate you.

What about sharing a link with an unauthenticated user? Last I checked, Drive lets you create a public download link for your files.

In other cases - yes. In this one - not necessarily. The content itself is hosted on a different domain and for a good reason. Most importantly though, they don't need another cookie to track you: you are already there, they know who you are, they know you already requested a resource, and they can track you over all Google services and many others anyway. They don't need to use a dirty trick to send you an additional cookie although the very fact that we're having the discussion means Firefox made a good decision and hopefully people will notice this pattern more.

So, could you just spoof your user-agent on Linux/Windows for an Apple one?

Maybe we could categorize cookie's party by domain's whois record?

Unfeasible.

Whois data are heavily redacted, and not really checked upon, so you have two problems:

* you have access only to redacted data;

* and also if you had access to original data, they are basically free form text;

Google pre-emptively setting its services up to fail and be sunset. If they keep this up maybe they can sunset services before they even launch