Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

To download from Google Drive, you must enable third party cookies?

support.google.com

Post reply on HN
Print view View original

71–80 of 166 posts

Re: To download from Google Drive, you must enable third party cookies?

#71

Post by jefftk »

Nextgrid wrote: post #64
jefftk wrote: post #33

This is wrong: try downloading something with Safari, which blocks third party cookies by default, and it works fine. 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)

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

Re: To download from Google Drive, you must enable third party cookies?

#72

Post by [deleted] »

Nextgrid wrote: post #64
jefftk wrote: post #33

This is wrong: try downloading something with Safari, which blocks third party cookies by default, and it works fine. 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)

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.

[deleted]

Re: To download from Google Drive, you must enable third party cookies?

#74

Post by jefftk »

mynameismon wrote: post #67
jefftk wrote: post #33

This is wrong: try downloading something with Safari, which blocks third party cookies by default, and it works fine. 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)

I don't think this is the issue. I use Vivaldi, blocking third party cookies by default, and I was unable to download before I disabled third party cookies temporarily.

Vivaldi pretends to be Chrome: https://vivaldi.com/blog/user-agent-changes/

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?)

Re: To download from Google Drive, you must enable third party cookies?

#75

Post by jefftk »

GTP wrote: post #70
jefftk wrote: post #35

Earlier quoted context omitted.

It's only broken on Chrome, though. In Safari it works fine without third party cookies.

This is interesting, are you sure your browser isn't making an exception for google drive?

You can verify that it isn't by looking in developer tools, and you will see that no third-party cookies are sent

Re: To download from Google Drive, you must enable third party cookies?

#76

Post by jakear »

markussss wrote: post #53
zmxz wrote: post #46

Earlier quoted context omitted.

I'd love to, but it's simply unusable compared to Chrome when it comes to web development.

I have not found any shortcomings in Firefox for web development, so I'm wondering if you could you elaborate on what features are missing, or what killer features for web development Chrome has that Firefox doesn't?

The entire local file system api, for one: https://developer.mozilla.org/en-US/docs/Web/API/File_System... , which severely neuters any tooling designed to help you do real work on your own files.

Re: To download from Google Drive, you must enable third party cookies?

#77

Post by workingon »

jefftk wrote: post #71
Nextgrid wrote: post #64

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…

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

Re: To download from Google Drive, you must enable third party cookies?

#78

Post by frognumber »

dwighttk wrote: post #43
frognumber wrote: post #36

Earlier quoted context omitted.

In general, I like to have at least two implementations to make sure multiple implementations are possible. If the rendering engine bit-rots, goes the way of the original Netscape, Internet Explorer, etc., you don't want the internet to break.

Eh. That’s kinda like “don’t put all your money in dollars” 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.

No, it's really not. It's more like "don't put your money in one stock," but it's much more like "architect your code sanely."

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

Post reply on HN