[xenomachina]

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.

[kevingadd]

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.

[kelnos]

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

[xenomachina]

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.

[coder543]

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