6 ms·

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 b

by jefftk 4y ago

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?

workingon 4y ago
It seems obvious to me why they don't use that for everyone, and it has nothing to do with security.
- jefftk 4y ago
  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?
  - dataflow 4y ago
    > 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.
    - horsawlarway 4y ago
      Except their instructions are specific to whitelisting the exact subdomains in question - they aren't telling you "Enable 3rd party cookies".
      - dataflow 4y ago
        Yeah I'm not agreeing with it, just think that's what he was thinking of.
      - Nextgrid 4y ago
        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.
        jefftk 4y ago
        The article we're commenting on has specific instructions for how to do this in Chrome: https://support.google.com/drive/answer/2423534 https://support.google.com/drive/answer/2423534
        horsawlarway 4y ago
        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
  - api 4y ago
    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.
  - rndgermandude 4y ago
    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.
- horsawlarway 4y ago
  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.
  - ascagnel_ 4y ago
    > 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.
    - horsawlarway 4y ago
      > 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.
VoxPelli 4y ago
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.
xxs 4y ago
>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.
- thayne 4y ago
  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.
  - cuddlecake 4y ago
    Tried it, wouldn't recommend it. The file data would be stored in the browser tab's memory. It usually ends in crashes.
coder543 4y ago
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.

by jefftk 4y ago

workingon 4y ago

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

jefftk 4y ago
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?
- dataflow 4y ago
  > 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.
  - horsawlarway 4y ago
    Except their instructions are specific to whitelisting the exact subdomains in question - they aren't telling you "Enable 3rd party cookies".
    - dataflow 4y ago
      Yeah I'm not agreeing with it, just think that's what he was thinking of.
    - Nextgrid 4y ago
      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.
      - jefftk 4y ago
        The article we're commenting on has specific instructions for how to do this in Chrome: https://support.google.com/drive/answer/2423534 https://support.google.com/drive/answer/2423534
      - horsawlarway 4y ago
        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
- api 4y ago
  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.
- rndgermandude 4y ago
  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.
horsawlarway 4y ago
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.
- ascagnel_ 4y ago
  > 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.
  - horsawlarway 4y ago
    > 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.

VoxPelli 4y ago

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.

xxs 4y ago

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

thayne 4y ago
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.
- cuddlecake 4y ago
  Tried it, wouldn't recommend it. The file data would be stored in the browser tab's memory. It usually ends in crashes.

coder543 4y ago

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.