101–110 of 166 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
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
Earlier quoted context omitted.
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 curre…
Sniffing the user agent is fundamentally web-hostile!
Earlier quoted context omitted.
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 curre…
> 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 use…
Okay, but this thread is about the right use of them.
Earlier quoted context omitted.
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 curre…
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.
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
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…
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…
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)
Earlier quoted context omitted.
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…
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…
* 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.
Earlier quoted context omitted.
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…
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…
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.