5 ms·

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

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.

xeromal 4y ago
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.
jefftk 4y ago
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.
- coder543 4y ago
  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.
  - jefftk 4y ago
    Content that's limited to specific users can still be used for targeted attacks, so it doesn't help very much.
    - coder543 4y ago
      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.
      - jefftk 4y ago
        > 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?
        coder543 4y ago
        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.
- rediguanayum 4y ago
  This is correct.
xenomachina 4y ago
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.
- coder543 4y ago
  > 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.
- kevingadd 4y ago
  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 4y ago
  > 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 4y ago
    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.

xeromal 4y ago

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.

jefftk 4y ago

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.

coder543 4y ago
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.
- jefftk 4y ago
  Content that's limited to specific users can still be used for targeted attacks, so it doesn't help very much.
  - coder543 4y ago
    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.
    - jefftk 4y ago
      > 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?
      - coder543 4y ago
        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.
rediguanayum 4y ago
This is correct.

xenomachina 4y ago

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.

coder543 4y ago
> 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.
kevingadd 4y ago
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 4y ago
> 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 4y ago
  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.