To download from Google Drive, you must enable third party cookies?
support.google.com
support.google.com
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)
[1]: https://addons.mozilla.org/en-US/firefox/addon/google-contai...
[2]: https://addons.mozilla.org/en-US/firefox/addon/cookie-autode...
Browser (and features, especially privacy ones), absolutely. Renderer, not so much.
Straight up lack of competition examples are the easiest: DMV, airport food court, buying beer at a sports stadium etc.
If you work in tech then you’ve probably had to use software over whose purchase you had no control: Jira, PeopleHR, Taleo, Concur. There’s no competition there because you, the end user, don’t have the option to choose from a free market. For the vendor, the software doesn’t have to be any good as long as the sales pitch to you boss is amazing.
Without competition, software rots and/or never gets better. What examples are there of monopolies in Free software that caused a product to languish? OpenSSL, Python’s logging module, systemd since it was locked in as the only properly supported Debian/Ubuntu init, pre-Chrome Firefox/Mozilla, post-GMail Thunderbird.
What examples are there of corporate-sponsored software that languish without competition? Internet Explorer is the classic example but if you think Google are better than Microsoft, at heart, then how’s Android working out for us all in terms of excellence-in-the-void-of-competition?
FWIW I am typing my response to you in Graphene.
Ultimately the issue is: what is the harm in using a library maintained by Google to do the webview rendering in a non-Google browser? I just don't see it.
It looks pretty similar to what MS was doing with IE, just with a dash of "here you can skin this thing". The biggest differences being that Google has a strong interest in ensuring the web is the app platform of choice, rather than a desktop OS. On the other hand, Google needs to sell targeted ads, so it's unlikely to be the standard bearer for web privacy.
To be fair, systemd was rotten to the core from day one (literally - namely, the core concept of shoving as much crap into pid 1 as possible to abuse the special semantics that are supposed to only allow for reaping of orphan processes), so you can't really blame that on lack of competition.
Your overall point is spot on, though. (And I suppose you could blame lack of sufficiently direct/credible competition for Debian being able to shove systemd down everyone's throats, rather than being forced to support multiple init systems.)
If a private party can do as they please and have such a strong say, why bother with standardization bodies?
If Blink decides to support a feature, it becomes a de-facto standard even if the feature solely serves Google (think FLoC, AMP ...) or is hard to replicate.
It's also an issue because now the web is at risk to become only usable from devices that are physically able to run Blink/Webkit which means nobody in the future will be able to create a new useful device/os that cannot run Blink or Webkit.
It's also an issue with the good ol' technical debt : what happens when Blink/Webkit become a total mess full of hard to patch vulnerabilities or google/chrome specific code ? You basically cannot rewrite it from scratch unless you have the engineering power of a GAFAM.
There are tons of reasons why having a monoculture of rendering engine is an issue.
If Google were trying to leverage the renderer to assert Chrome over say Brave or Edge, sure, but they're not, and if they do, it will be forked.
Do we have the same concerns over type layout engine monoculture?
Google has already asserted that. Brave and Edge are a footnote to a footnote to a distant appendix, and are almost entirely reliant on Google to provide the rendering engine.
If the rendering engine bit-rots, goes the way of the original Netscape, Internet Explorer, etc., you don't want the internet to break.
If the US Dollar goes to zero or the only rendering engine bit rots, other things are happening such that I won’t be too concerned about not having money or not being able to browse the web.
In general, if I have a modular abstraction barrier in my code, I try to have at least two implementations. For example, if I have a generic key-value store so I can switch databases later, I'll make an implementation for e.g. PostgreSQL and redis. That way, I don't accidentally couple to one or the other. Otherwise, I'm fooling myself.
That's just basic software engineering, but for open industry standards, it's really critical. You don't want CSS rendering depending on some browser bug or quirk. It's critical to have multiple implementations, or it's not a standard.
The flip side of allowing multiple implementations also means it's possible to build things like web crawlers, screen readers, and other technologies without spending millions of dollars re-engineering IE or Chrome to be identical, bug-for-bug. It's also possible to build new things we never imagined. Indeed, we had a lot more diversity in HTML 2.0 days, when things were simple enough that anyone could build a novel web technology over a weekend (with full HTML 2.0 parsing).
(Before I get accused of over-engineering, I usually don't have these types of modular abstractions; if I don't expect to ever swap databases, I'll e.g. code to PostgreSQL directly
Web 2.0 was based on some IE extensions that were introduced when Firefox was the viable other game in town.
Concretely, Google Maps (the poster child for AJAX) launched in 2005, and Chrome launched in 2008.
Remember IE6 ? That's what we get with a monoculture.
Given the complexity and feature set of a modern rendering engine I don't think it's to fare fetched. I like the entire Internet not being vulnerable all at once.
This attitude is why people dismiss Firefox: “well if FF doesn’t implement it, it must be bad. Other browsers surely have glaring security holes”
(Source: I implemented the file system integration for vscode.dev)
I'd still prefer to see a mainstream Gecko based browser, of course! I think outside of the tech crowd FF is pretty niche.
When doing so, an attacker can steal cookies, and/or invoke APIs for the user.
Now, there are of course ways to avoid that, but in the end, if every other system fails, being on a domain without any API and without any sensitive content allows reducing the blast of the impact.
Real-world example: https://gitlab.com/gitlab-org/gitlab/-/issues/200094
GitLab has APIs under their main domain. Due to a misconfiguration, it was possible to render in the browser user-generated `.svg` files. Thus, a malicious crafted SVG file could bring to a XSS, and accessing a lot of personal user data on the main domain.
There are technical reasons for the shared domain, but if that particular API call was on another domain, the impact of the vulnerability would have been way smaller.
The point is: if for any reason (0-day, misconfiguration, bug, whatever) the content uploaded from the user is executed by the browser, instead of being "just" rendered or downloaded, it must execute in a different domain. Given domains are sandboxed by the browser, a vulnerability on domain A cannot affect domain B.
Of course, there are still way to shoot you in the foot (e.g., having the same access token in the cookies for both domains), but it's one measure more. This is why security should be layered, and you shouldn't rely on just one defense: https://en.wikipedia.org/wiki/Defense_in_depth_(computing)
Having a total different domain help highlighting that it is not official content.
There's probably some benefits around blacklists too.
For example if a user uploaded questionable content to assets.example.com/uploads, such as pirated content then someone could submit that to search engines and other lists to get your domain blacklisted. It's quite possible these blacklists could be related to the apex domain, not necessarily the sub-domain. A separate domain guarantees your apex domain won't get penalized.
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)
"Type chrome://settings/cookies in the browser address bar"
I love how they assume everybody uses Chrome.
When the user clicks a file download link it should be possible to generate a short lived token that authenticates the user against googleusercontent.com.
Some companies are requesting permissions for more or less valid reasons and later using these permissions for their own goals as well.
You're screwed on iOS though.
Whois data are heavily redacted, and not really checked upon, so you have two problems:
* you have access only to redacted data;
* and also if you had access to original data, they are basically free form text;