Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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


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


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.


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.


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


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


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


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


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.


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.


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


I don't think we're talking about the same thing.

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?


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


> fundamentally web-hostile.

Sniffing the user agent is fundamentally web-hostile!


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?


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


Except their instructions are specific to whitelisting the exact subdomains in question - they aren't telling you "Enable 3rd party cookies".


Yeah I'm not agreeing with it, just think that's what he was thinking of.


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.


The article we're commenting on has specific instructions for how to do this in Chrome: https://support.google.com/drive/answer/2423534


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


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: