Hacker News Reader

Comment by kazinator | Hacker News Reader

> Some features of the web that people have come to expect, and which greatly improve user experience, currently depend on third-party cookies.

Idea: domains should be able to publish a text record in their DNS (similarly to SPF record for mail domains) designating other domains which are allowed to peek at their cookies.

Suppose I operate www.example.com. My cookie record could say that foo.com and bar.com may ask for example.com cookies (in addition to example.com, of course). A website from any other domain may not. As the operator of example.com, I can revoke that at any time.

Whenever a page asks for a cookie outside of its domain, the browser will perform a special DNS query for that cookie's domain. If that query fails, or returns data indicating that the page does not have access, then it is denied.

View on HN

But then all the ad-supported websites will whitelist the ad tracking cookies, which is precisely what they are trying to avoid here.

Ah, but in so doing they will have to publish their whitelist, which will exhaustively have to list every single affiliated domain.

Browsers and browser extensions will be able to use that info to identify shit sites, turning the whitelist around into blacklisting uses, like ad blocking and whatnot.

One simple mechanism would be for the browser to deny the cookie request if the requested domain's cookie DNS record contains more than, say, three affiliated domains. (At the discretion of the browser developer, and user settings.) The proliferation of that sort of config would discourage domains from being overly promiscuous with their tracking cookie access.

Plus, existing cookie control mechanisms don't go away.

Not a bad idea, TBH.

Just feeling uncomfortable putting more data into DNS. DNS is not encrypted. DNSSEC is easy to bypass (or break way too often that nobody want to enforce it).

-- but these are not w3c's problem.

Yes; if someone hijacks example.com's main A record, that gets caught at the SSL level.

If someone hijacks example.com's cookie record, that won't be caught; they just write themselves permission to have their page access example.com's cookies.

The same info could just be hosted by example.com (at some /.well-known path or whatever). The web could generate a lot of hits against that.

The DNS records could be (optionally?) signed. You'd need the SSL key of the domain to check the signature.

DNSSEC isn't encrypted either.

When you say bypass, do you mean disable DNSSEC on your own computer? Or are there known vulnerabilities in DNSSEC cryptography or software?

The stub resolver on your own computer doesn't actually speak DNSSEC. It speaks normal DNS to a recursing resolver, probably at your ISP or at Google, that itself does DNSSEC validation, and then just sets a bit in the response back to you that says "this is authentic".

Glibc supposedly has DNSSEC, but does anyone use it:

https://sourceware.org/glibc/wiki/DNSSEC

That page appears to be mostly about how to trust a real recursive cache from a glibc program.

I'd hate to be pointed to that page and tasked with designing and implementing a test plan.

The recursing resolver is on my local system, anything else is clearly madness.

Always fascinating to hear about how the standard configuration for every workstation Linux distro, macOS, and Windows 10 are "clearly madness". Do go on!

This is already a feature called "Related Websites": https://github.com/WICG/first-party-sets

I dont think DNS should be overloaded to have a security measure.

It's already used in a similar way for SPF records, in the context of e-mail.

Using a SPF record, a domain indicates hosts that are allowed to deliver mail on its behalf (meaning using an envelope sender address from that domain).

Reply on news.ycombinator.com