[HN Gopher] To download from Google Drive, you must enable third...
___________________________________________________________________
To download from Google Drive, you must enable third party cookies?
Author : seydor
Score : 359 points
Date : 2022-07-19 07:19 UTC (15 hours ago)
(HTM) web link (support.google.com)
(TXT) w3m dump (support.google.com)
| dethos wrote:
| I've faced this problem in the past and it is really annoying.
| One of the many reasons why I dislike this service and try to
| avoid it as much as possible.
| password4321 wrote:
| The workaround: Preview, [?] > Open in new window, Download
| [deleted]
| ninju wrote:
| The title is tad incomplete.
|
| 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)
| zagrebian wrote:
| Are third-party cookies cross-origin or cross-site?
| iknownothow wrote:
| Pro tip: If you want to download an image or pdf, Drive will
| still let you print, so you can print it to file as a PDF.
| dvfjsdhgfv wrote:
| Seems like in this particular case, notwithstanding Google's long
| history of abuse and opportunism, this one is a genuine case when
| you enable a cookie for technical and not (necessarily) user
| tracking reasons.
| thih9 wrote:
| Is it certain that Google will not use these (i.e. cookies
| enabled for technical reasons) also for tracking?
|
| Some companies are requesting permissions for more or less
| valid reasons and later using these permissions for their own
| goals as well.
| robertlagrant wrote:
| There's no need to use cookies for this when they control the
| backend. They know you're accessing a file because their
| server had to authenticate you.
| bogwog wrote:
| What about sharing a link with an unauthenticated user?
| Last I checked, Drive lets you create a public download
| link for your files.
| robertlagrant wrote:
| Hmm, yes, that's true. I wonder if that works with
| cookies disabled.
| kevin_thibedeau wrote:
| It's just another dark pattern their middle management cooks up
| under the guise of legitimacy.
| dvfjsdhgfv wrote:
| In other cases - yes. In this one - not necessarily. The
| content itself is hosted on a different domain and for a good
| reason. Most importantly though, they don't need another
| cookie to track you: you are already there, they know who you
| are, they know you already requested a resource, and they can
| track you over all Google services and many others anyway.
| They don't need to use a dirty trick to send you an
| additional cookie although the very fact that we're having
| the discussion means Firefox made a good decision and
| hopefully people will notice this pattern more.
| newscracker wrote:
| If you're anyway using Google Drive, you could use Firefox with
| the Google Container extension [1] to limit Google's tracking
| activities across Google tabs to this container. Also install
| Cookie AutoDelete [2] and let the cookies, cache, local storage,
| etc., get cleared soon after you close the tabs.
|
| [1]: https://addons.mozilla.org/en-US/firefox/addon/google-
| contai...
|
| [2]: https://addons.mozilla.org/en-US/firefox/addon/cookie-
| autode...
| [deleted]
| LinAGKar wrote:
| That's not really usable until they fix the issue where it
| wipes the tabs history.
| giancarlostoro wrote:
| Honestly anyone concerned about a Chrome / WebKit browser
| monopoly needs to use Firefox now if you already are not.
| rpastuszak wrote:
| At this stage, I think we can draw a line between WebKit and
| Blink, so even having more WebKit based browsers would be a
| welcome change.
|
| I'd still prefer to see a mainstream Gecko based browser, of
| course! I think outside of the tech crowd FF is pretty niche.
| BolexNOLA wrote:
| What are your thoughts on brave browser? I've used it over
| firefox for about two years now and I really enjoy it.
| jeromegv wrote:
| Brave is just chrome underneath so you're definitely not
| helping to browser diversity.
| BolexNOLA wrote:
| Appreciate it!
| oxff wrote:
| Can't do that when Firefox simply isn't good enough. Vivaldi
| beats it in features and what I need from browser as a power-
| user.
| zmxz wrote:
| I'd love to, but it's simply unusable compared to Chrome when
| it comes to web development.
| krisgenre wrote:
| AFAIK Firefox is the only browser that does 'persist logs'
| in dev console right. i.e I get to see the responses of all
| requests whereas Chrome only shows the current page
| responses. Chrome has also refused to acknowledge this as a
| bug.
| depressedpanda wrote:
| How so? I use Firefox for web dev, and I don't find it
| unusable compared to Chrome.
| markussss wrote:
| 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?
| jakear wrote:
| 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.
| sneak wrote:
| I don't see any problems with a monoculture of rendering
| engine.
|
| Browser (and features, especially privacy ones), absolutely.
| Renderer, not so much.
| ivanmontillam wrote:
| Chromium is such a big deal, that it also easily twists the
| arm of standardization bodies like the W3C.
|
| If a private party can do as they please and have such a
| strong say, why bother with standardization bodies?
| pjerem wrote:
| The problem is that you are giving full power for creating
| de-facto standards to the rendering engine.
|
| 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.
| sneak wrote:
| Neither FLoC nor AMP are part of the renderer. AMP isn't
| even clientside, it is a feature of the Google search
| webapp.
|
| 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?
| grosswait wrote:
| We have the same concerns over any lower level
| components, yes. I don't think a type layout engine is
| comparable to a web render.
| dmitriid wrote:
| > 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.
|
| 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.
| gaius_baltar wrote:
| > I don't see any problems with a monoculture of rendering
| engine.
|
| Remember IE6 ? That's what we get with a monoculture.
| frognumber wrote:
| 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.
| dwighttk wrote:
| 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.
| frognumber wrote:
| 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
| squidbeak wrote:
| You've forgotten what it was like at the turn of the
| century. It took a long while for us to break the previous
| monoculture and clear the way for the innovation we've
| enjoyed since.
| shadowgovt wrote:
| The innovation we've enjoyed since was mostly caused by
| Google getting tired of waiting for either Microsoft or
| Mozilla to improve on the browser paradigm and footing
| the bill to roll their own.
| hedora wrote:
| History doesn't really linenup with that:
|
| 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.
| shadowgovt wrote:
| I was referring to the innovations in browser
| capabilities. Process sandboxing massively improved both
| the robustness of the browser experience and the boldness
| with which features could be used (because a crashing
| site wouldn't take the whole browser with it). It paved
| the way for the actual "browser is the OS for the web"
| experience we have today, unlike IE's attempt to wed a
| crash-prone application to its core OS functionality. As
| a result, the browser capability specs themselves
| exploded, which eventually rendered Flash, Silverlight,
| and ActiveX plugins mostly redundant and allowed browser
| vendors to make their way towards stripping them out in
| favor of web-engine-only solutions.
| mrweasel wrote:
| Forget the monopoly part, the reference to IE6, all that
| stuff. Let's say we don't care about that. What happens
| when the Chrome rendering engine has a security bug, a big
| one, a zero-day? That's the issue we had with OpenSSL,
| suddenly 90% of the Internet er vulnerable and there are no
| alternatives until Google fixes the bug.
|
| 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.
| peanut_worm wrote:
| I would prefer that an advertising company does not have
| majority control over the rendering engine
| shreyshnaccount wrote:
| I see the problem if the monoculture is dominated by for
| profit big tech corpos
| gorgoiler wrote:
| Have you ever used a service in life where there is no
| competition?
|
| 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?
| sneak wrote:
| We are talking at cross purposes: your comment is a
| reasonable refutation of a browser monoculture, something
| we agree would be bad.
|
| 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.
| jackmott wrote:
| nirvdrum wrote:
| Google can do pretty much whatever it wants when it's the
| only player in the space. It certainly hasn't been shy
| about doing things outside of a standards body. Sure,
| it's open source, but can you meaningfully influence the
| direction of the project? If you decide to fork and
| deviate from what stock Chrome is doing, you're apt to be
| locked out similarly to sites that don't support Firefox
| or Safari.
|
| 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.
| bogwog wrote:
| If Google has a monopoly on the rendering engine, who
| decides what the future of web rendering looks like?
| Google, and nobody else.
| jhanschoo wrote:
| The argument needs to be more subtle to make sense, since
| Blink is open-source, whereas IE was not. Contrarily, I
| see another analogy; Blink being like Linux's dominance
| in infrastructure.
| robin_reala wrote:
| The Linux Foundation aren't trying to develop Linux to
| cement their advertising business. The Linux Foundation
| are benign, and Google aren't.
| a1369209993 wrote:
| > Without competition, software rots and/or never gets
| better. [...] systemd since it was locked in as the only
| properly supported Debian/Ubuntu init
|
| 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.)
| tomjakubowski wrote:
| the vast majority of systemd's codebase runs outside of
| PID 1. what does systemd actually run in PID 1 that you
| object to?
| btdmaster wrote:
| yt-dlp works fine last I tried!
| wanderingmind wrote:
| If using linux or mac, just FUSE mount with rclone. If you need
| more privacy,load the mount with encryption so google has no idea
| about the files you are working with.
| wbecher wrote:
| I was going to write just this! rclone is a lifesaver!
| ronjouch wrote:
| Thank you and thanks wanderingmind for sharing this! I knew
| rclone, but didn't know you you could pair it with a fuse
| mount! Looks like an awwwwwesome addition to the toolbelt
| :))))
| haunter wrote:
| That's not limited to Linux or macOS at all, works perfectly
| under Windows too
| wanderingmind wrote:
| Thanks for that info. Haven't used windows in a long time, so
| did not want to post of something I'm not sure.
| jefftk wrote:
| 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)
| dheera wrote:
| Yeah, so all you need to do is ask Chrome to report a Safari
| User-Agent.
| mynameismon wrote:
| 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.
| jefftk wrote:
| 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?)
| [deleted]
| [deleted]
| lelandfe wrote:
| If you mock your UA string in Chrome, does downloading work
| like Safari?
| nottorp wrote:
| Or Safari has an exception for google cookies.
| jefftk wrote:
| If you open developer tools you can see cookies aren't being
| sent.
| ruoranwang wrote:
| Good to know, thanks!
| Nextgrid wrote:
| 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.
| kretor wrote:
| What browsers lack per-domain cookie controls?
| jefftk wrote:
| 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?
| VoxPelli wrote:
| 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.
| coder543 wrote:
| 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.
| jefftk wrote:
| 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 wrote:
| 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.
| thrashh wrote:
| It's not security for the end user
|
| 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.
| jefftk wrote:
| Content that's limited to specific users can still be
| used for targeted attacks, so it doesn't help very much.
| coder543 wrote:
| It would still say "drive.google.com", not "google.com",
| and if that isn't enough of a hint for the target,
| googleusercontent.com won't be either. In fact, _people
| have heard of Google Drive._ They know that means it isn
| 't from Google. "googleusercontent" could be "Google
| content intended for users" for all someone knows.
|
| 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.
| jefftk wrote:
| _> 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._
|
| 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?
| coder543 wrote:
| Maybe my phrasing was awkward, but I said you would only
| have to do this once for a given account. So, if I've
| _never_ accepted a share from you before, your links won
| 't work. When you share something with me for the first
| time, I would have to accept it via a Google-sent email
| containing a link that only Google knows (not something
| that can be sent via slack), and then all your future
| share links would work for me on slack. The error page
| denying access could even indicate that the user should
| check their email for additional verification.
|
| 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.
| _flux wrote:
| Do people want to have friend requests in Google? If I
| wanted to share a file to your Google account, would you
| like to trust the future shares automatically as well? It
| doesn't seem like the superior alternative to just using
| 3rd party cookies--other than that it works if 3rd party
| cookies are disabled.
|
| 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).
| coder543 wrote:
| The alternative is trusting _all_ shared links, which is
| currently what Google does. Third party cookies have
| nothing to do with it. Having some form of revokable
| authorization _to be able to click on links_ from a
| person is superior to "all sketchy links working
| instantly."
|
| 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.
| rediguanayum wrote:
| This is correct.
| xenomachina wrote:
| Using a separate domain for user generated content is
| usually done for security reasons. For example, if a
| user-generated chunk of JavaScript was executed from
| drive.google.com, then it could potentially gain access
| to your drive.google.com, or maybe even *.google.com,
| authentication cookies. Scripts running on an unrelated
| domain have no such access.
|
| 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.
| kelnos wrote:
| > _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._
|
| 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.
| coder543 wrote:
| > 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.
| kevingadd wrote:
| Native browsers tend to flag any files they download with
| information on what domain the file came from, so it's
| also relevant in that case. Windows and OS X will pop up
| a warning when opening untrusted files, so whether the
| user sees 'google.com' or not could be important.
| xeromal wrote:
| 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.
| workingon wrote:
| It seems obvious to me why they don't use that for
| everyone, and it has nothing to do with security.
| horsawlarway wrote:
| 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.
| mrweasel wrote:
| > This is basically the poster child for a case when
| someone should be using 3rd party cookies
|
| 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.
| ascagnel_ wrote:
| > 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.
| yunohn wrote:
| > If everyone would use 3rd party cookies like you're
| describing, there'd be no issue with users enabling them
|
| Okay, but this thread is about the right use of them.
| horsawlarway wrote:
| > 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.
| shadowgovt wrote:
| It is possible the US government lacks the reach to do
| what you've described, given how much organized crime is
| centered in other nations.
|
| 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.
| mindslight wrote:
| While I agree that we direly need privacy legislation to
| stop openly chartered surveillance companies from
| tracking us through whatever means, your position doesn't
| work for computer security in general. The only way
| "accountability" works for computer security is if every
| node on the network carried an inescapable real world
| identity that is responsible for its network traffic,
| which would be much more of a draconian regime than you
| are arguing against.
| ethbr0 wrote:
| > _A single entity manages multiple domains and shares
| cookie auth across them._
|
| 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.
| horsawlarway wrote:
| I think you're falling into the same trap.
|
| 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.
| jrochkind1 wrote:
| What is the definition of what is "really" "my" domain?
|
| 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.
| jrockway wrote:
| > Who decides what is allowable declaration of a domain
| to be mine?
|
| 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...
| jefftk wrote:
| _> 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."_
|
| Chrome was playing with an idea like that:
| https://developer.chrome.com/docs/privacy-sandbox/first-
| part...
| ethbr0 wrote:
| Neat! It feels like cryptographic attestation by the
| child/secondary site would be less subject to abuse.
|
| 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
| pif wrote:
| > fundamentally web-hostile.
|
| Sniffing the user agent is fundamentally web-hostile!
| jefftk wrote:
| 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 wrote:
| > 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 wrote:
| Except their instructions are specific to whitelisting
| the exact subdomains in question - they aren't telling
| you "Enable 3rd party cookies".
| dataflow wrote:
| Yeah I'm not agreeing with it, just think that's what he
| was thinking of.
| Nextgrid wrote:
| 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 wrote:
| The article we're commenting on has specific instructions
| for how to do this in Chrome:
| https://support.google.com/drive/answer/2423534
| horsawlarway wrote:
| 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 wrote:
| 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 wrote:
| 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.
| xxs wrote:
| >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 wrote:
| 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 wrote:
| Tried it, wouldn't recommend it. The file data would be
| stored in the browser tab's memory. It usually ends in
| crashes.
| [deleted]
| II2II wrote:
| I'm not sure if blocking third party cookies is the cause, but
| I have had difficulty downloading files under Firefox.
| Disabling third party cookies is one of the first settings I
| enable after installing Firefox.
|
| I would not be surprised if Apple makes an exception for
| Google.
| jefftk wrote:
| _> I would not be surprised if Apple makes an exception for
| Google._
|
| Apple doesn't, which you can verify with developer tools in
| Safari.
| seydor wrote:
| How is it wrong? And if safari does it without cookies, why not
| chrome?
|
| Chrome is used by 65% of people, safari ~15% (<10% on desktop)
| Quarrelsome wrote:
| I believe they're suggesting some code is executed based on
| the user agent. So Safari gets treated differently. Safari is
| defacto zero 3rd party cookies but Chrome isn't which is
| possibly why that site is treating them different.
| 0xbadcafebee wrote:
| Google pre-emptively setting its services up to fail and be
| sunset. If they keep this up maybe they can sunset services
| before they even launch
| GTP wrote:
| And from their solution:
|
| "Type chrome://settings/cookies in the browser address bar"
|
| I love how they assume everybody uses Chrome.
| jefftk wrote:
| It's only broken on Chrome, though. In Safari it works fine
| without third party cookies.
| NicuCalcea wrote:
| It's broken in Firefox for me.
| jefftk wrote:
| Stock Firefox?
| GTP wrote:
| This is interesting, are you sure your browser isn't making
| an exception for google drive?
| jefftk wrote:
| You can verify that it isn't by looking in developer tools,
| and you will see that no third-party cookies are sent
| rpadovani wrote:
| I think it is because they use `googleusercontent.com` for
| content uploaded by users - that makes sense for security
| reasons, never ever let users upload content to your main domain.
| Nuzzerino wrote:
| Can you elaborate on this? What's special about the domain here
| for security?
| rpadovani wrote:
| It's a defense in depth mechanism: when you allow user-
| generated content uploaded on your main domain, somebody will
| find a way to break your security system and make that
| content executable on the user's browser.
|
| 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.
| nickjj wrote:
| Is this also another case for hosting your main site on
| www.example.com instead of example.com? This way you could
| have cookies only on www.example.com while hosting user
| generated content on assets.example.com or whatever sub-
| domain you want that's not www?
| rpadovani wrote:
| Yes and no: one thing I totally forgot to mention is
| phishing. You don't want to give any semblance of
| endorsement to user-generated contents: many viewers will
| check only the main domain, due to how browsers' URL bars
| hide stuff.
|
| Having a total different domain help highlighting that it
| is not official content.
| nickjj wrote:
| Makes sense.
|
| 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.
| hannes0 wrote:
| How does the configuration look like (very broadly)? Is
| already a domain redirect helpful here?
| rpadovani wrote:
| Yes, as long as the content is downloaded from another
| domain, everything is good.
|
| 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_i
| n_depth_(computing)
| jakub_g wrote:
| Similarly, long time ago you could have a personal/project
| website on <username>.github.com. A few years ago they
| moved all personal/project websites to <username>.github.io
| instead.
| TobTobXX wrote:
| Also, malware detection algorithms decrease their rating for
| the google.com domain when they encounter malicious content
| on this domain. Probably not an issue for google
| specifically, as they themselves control this list for
| Chrome, but for other companies this might be relevant too.
| nottorp wrote:
| Google container for Firefox :)
|
| You're screwed on iOS though.
| mig39 wrote:
| Doesn't require 3rd party cookies on iOS or Safari on MacOS.
| Pakdef wrote:
| So, could you just spoof your user-agent on Linux/Windows for
| an Apple one?
| est wrote:
| Maybe we could categorize cookie's party by domain's whois
| record?
| rpadovani wrote:
| Unfeasible.
|
| 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;
| jabiko wrote:
| I'm wondering why the information necessary for downloading the
| file can't just be encoded as a URL parameter.
|
| 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.
| ratww wrote:
| That's quite easy to do with Amazon S3. Maybe Google could just
| use AWS since implementing this feature seems to be a bit
| complex for them. /s
| krono wrote:
| As far as I'm aware no browser offers granular third-party cookie
| permission controls - e.g. allow third-party cookies from
| `googleusercontent.com` but only on `drive.google.com`.
| throwaway294566 wrote:
| Firefox with uMatrix can do that.
| lapinot wrote:
| Or ublock origin, in advanced mode. I took time to transition
| away from umatrix and i miss the interface but it's fine.
| [deleted]
| Animats wrote:
| What happens with curl?
| martini333 wrote:
| Why not enable [*.]googleusercontent.com instead?
| whywhywhywhy wrote:
| Wasted a lot of time trying to figure this one out a few months
| ago.
___________________________________________________________________
(page generated 2022-07-19 23:02 UTC)