Instead, the problem is that downloading from Google Drive is using User-Agent sniffing to determine whether third party cookies are expected to be enabled, and choosing between implementations.
(Disclosure: I used to work at Google, but I don't know anything internal on this)
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.
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?
* 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?
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.
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
In this case you are probably right, but surveillance is Google's business model.
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.
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.
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.
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.
But I agree with you overall... Much of the web's concept of privacy and security is baked in with the assumption that it must be technologically enforced because it can't be legally enforced. Change that math and you change the model.
Okay, but this thread is about the right use of them.
Sniffing the user agent is fundamentally web-hostile!
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.
Some things are not solved in the appropriate manner through a technological solution.
They are misuses (and abuses) of a perfectly acceptable system. Don't undo the system, address the misuse.
Take your example:
>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.
The only reason this is the case is because this misuse has zero consequences.
Make them declare their domains, if they choose to include tracking domains, fine the ever-loving shit out of them. Not the ".05% of yearly profit" bullshit - I'm talking 200% of daily revenue for the top controlling company for every day that domain was on the list after it was declared a bad actor. If the company can't pay? Fucking nationalize them, remove the tracking domain, sell it to the highest bidder.*
Watch how fucking fast these companies will scramble to fix the problem when the stakes are real.
When the stakes are trivial - it doesn't matter what technology you try to put in place to block this, they will just work around it.
* I understand this is ridiculously extreme, but I'm done playing with these fucks. We've had the gloves on for the last 20 years, it's time they come off.
If I put a custom domain on an S3/cloudfront that's part of my system, so it appears as `storage.mysystem.com`, is there something nefarious going on?
Who decides what is allowable declaration of a domain to be mine? And who enforces this with fines? Is there currently any way to fine someone on the internet for violating a rule? What would you imagine this looking like, an organization that has the ability to fine people globally, and enforce the payment of those fines (by... taking domains back I guess?), and who would control it? (and who would pay for it, how?) It's a lot of global legal infrastructure we don't really have now, I think. It would be a pretty huge step.
Basically, there is a list included in all browsers: https://wiki.mozilla.org/Public_Suffix_List. That's why you.github.io can't read other github.io cookies, but if you make your own domain, you can share cookies between a.example.com and b.example.com. (Also why example.com can't read .com cookies.)
> Is there currently any way to fine someone on the internet for violating a rule?
Many governments do this. In the US, the FTC has fined a number of companies for things like supercookies: https://www.ftc.gov/business-guidance/blog/2012/08/milking-c...
I understood that the conversation was about attesting that, for instance, googleusercontent.com was owned by the same entity as google.com so could share cookies.
A) I don't see any way that the list included in browsers of public suffixes makes it possible to decide that google.com really owns googleusercontent.com. If it did, we would already be there and woudln't be discussing this.
B) Who do you think makes the public suffix list in the first place, where do you think it comes from exactly?
Chrome was playing with an idea like that: https://developer.chrome.com/docs/privacy-sandbox/first-part...
I.e. proving they have access to the same private key used to sign the parent, which would by definition not be something the parent would willingly share with random third parties
It is kinda funny that Google, among others, are the reason why we can have 3rd party cookies. Now they have a services that has a legitimate use-case and can't rely on 3rd party cookies being available and have to revert to work-around.
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.
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.
* 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.
I would not be surprised if Apple makes an exception for Google.
Apple doesn't, which you can verify with developer tools in Safari.
Ideally they would be using feature detection to check whether third-party cookies are supported, but I think it's UA sniffing (possibly because this is a slow feature to check through behavior?)
Chrome is used by 65% of people, safari ~15% (<10% on desktop)