* 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.
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.
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.
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?
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.
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).
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 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.
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.
I agree completely.
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.