Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DNS TLD for Privacy #36

Open
mnot opened this issue Dec 9, 2022 · 10 comments
Open

DNS TLD for Privacy #36

mnot opened this issue Dec 9, 2022 · 10 comments

Comments

@mnot
Copy link

mnot commented Dec 9, 2022

Rumour has it that ICANN is considering another run of the new gTLD program.

Last time around, Google registered .app and runs it with an additional semantic: all domains in that TLD are automatically on the HSTS preload list, effectiely enforcing HTTPS for any server with an .app domain.

What if something similar were done with a privacy focus? For sake of argument, let's say .priv1 is registered, and there's agreement that browsers will not allow any third-party requests from those domains. The registrar might also insert contractual terms that limited first-party tracking as well.

Sites with .priv domains could then beliveably market themselves as privacy-focused, giving them an advantage with privacy-concious users / customers.

This would also provide an opportunity for browsers to try out new techniques for privacy in a 'sandbox' that's already privacy-focused.

Just thinking out loud here - any interest? Obviously it'd need good browser support. Best path forward might be to define an opt-in signal for sites first, just like HSTS did.

Footnotes

  1. I suspect .priv is not the right name here, but let's not bikeshed that at the moment

@martinthomson
Copy link

I think this needs careful consideration regarding the scope of what you might be requiring these hypothetical sites to commit to.

There are obviously some privacy-related things that are technically enforceable and so might engage machinery in browsers. I don't think that that is limited to the use of third-party requests.

There are also some privacy-related things that are legally enforceable and so might engage an entirely different sort of machinery in various jurisdictions.

And of course this is hardly a clean bifurcation. Some practices bleed across between the two. If your intended scope includes navigation tracking, then that is sometimes identifiable by a browser and sometimes not.

What concerns me more is that this specific shape risks ending up as a marketing stunt more than delivering people with meaningful privacy advantages. A gTLD that was specifically "private" ends up positioning itself relative to all the other gTLDs. And this is just one of many dimensions that are relevant when it comes to making decisions about which domains to interact with and how to do so.

Google attaching what amount to public hygiene conditions to registrations of .app domains certainly helps improve online security. But there is no expectation or implication that non-.app domains are any less secure because security is not the primary reason for domains in that gTLD. The requirement is just an easy on-ramp to a good practice for sites looking to use an otherwise appealing gTLD.

Another way of approaching this is to have a site-level commitment to a particular policy, with markers that allow for various types of enforcement, automated or otherwise. GPC has something like that already, which presumably intends to engage with the jurisdictional mechanisms. A browser-level one can effectively be described with CSP (connect-src 'self', but I think that you are probably looking for something that makes intent more explicit.

-- not-chair-comment

@mnot
Copy link
Author

mnot commented Dec 9, 2022

What concerns me more is that this specific shape risks ending up as a marketing stunt more than delivering people with meaningful privacy advantages. A gTLD that was specifically "private" ends up positioning itself relative to all the other gTLDs. And this is just one of many dimensions that are relevant when it comes to making decisions about which domains to interact with and how to do so.

... which is why I noted that .priv might not be the best name.

Generally I agree that it's better to talk about the specific mechanisms to improve privacy rather then how they're invoked. What's interesting about embedding that mechanism in the name is not only that it's visible, but also that it's immutable -- to change their commitment, a site has to change its name. Of course, there are other ways to make things sticky on the Web.

@martinthomson
Copy link

there are other ways to make things sticky on the Web.

:) HTTP/1.1 301 ... Location: https://site.com/...

@annevk
Copy link

annevk commented Dec 9, 2022

I would be more comfortable with this if there was an equivalent to HSTS (preloading) for the kind of feature you envision.

@mikewest
Copy link

mikewest commented Dec 9, 2022

An alternative might be to look at the other parts of a hostname, locking in certain properties using a prefixing trick similar to what we've done for cookies. https://www.youtube-nocookie.com/embed/dQw4w9WgXcQ could be https://nocookie.youtube.com/embed/dQw4w9WgXcQ, for example, instructing the browser to ignore cookies for that host. I think that might be a useful concept for other kinds of properties (you could imagine ed25591-[publickey-goes-here].example.com as enforcing a signing requirement, or tls.example.com requiring TLS. This has the same drawbacks as cookie prefixes, most notably the requirement of coming up with meaningful bundles of the properties you actually want to offer developers, but the concept doesn't seem out of the question to me.

@kdenhartog
Copy link

Would it make sense to make this as a scheme rather than a TLD? Seems like that would create better backwards compatibility here rather than requiring a separate TLD for this. Additionally, I think the troublesome question here is what features are guaranteed when doing this?

E.g. if I go to privhttps:// what guarantees am I getting from this site and what enforcement mechanism is the browser offering for this so that it doesn't break compatibility? For example, would we expect that no scripts would run on a page like this? How might we guarantee that no tracker pixels have been added to subvert known methods?

Overall, I think there's some good ideas to adding a class of website identifiers that are easily recognisable as private, but from the discussions I had with our team we're not sure if this is the best path to approach it.

@pes10k
Copy link

pes10k commented Dec 12, 2022

+100 for having this functionality, but +100 too for moving the signal to the protocol (or something similar) instead of the TLD

That has the benefit of the user knowing the privacy-benefits of the site before they visit it but

  1. without conflating domain names with privacy guarantees (since we currently explicitly tell people to NOT think of sites like secure.example.org as more secure than example.org)
  2. allowing sites to upgrade / opt-in for free (no new domain registrations needed)
  3. lots of sites have selected their domains for specific reasons (e.g., https://cr.yp.to) and we'd presumably like them to be able to use this more-secure feature

@mikewest
Copy link

mikewest commented Dec 13, 2022

(since we currently explicitly tell people to NOT think of sites like secure.example.org as more secure than example.org)

  1. We discourage that today because it's not true. Presumably if we made the hostname meaningful, we'd stop discouraging folks from making such intuitive leaps. :)
  2. I think the hostname based mechanism is more useful for web developers (by choosing subresource/widget hosts that lock in strong security properties) than for users directly. I don't think there's a huge appetite in asking users to type in a public key hash, for instance, though there might be useful benefits to a developer who relies on subresources served from such an origin.

@pes10k
Copy link

pes10k commented Dec 13, 2022

We discourage that today because it's not true

Sure, point taken, but i expect that its easier for folks to understand and follow security advice that is consistent and doesn't have a bunch of decision-tree branches. Right now we tell people "the domain tells you who you're talking to, the protocol tells you [partially] about the privacy/security of that conversation".

My point is that Keeping the kind of restriction discussed in this thread to the protocol (https-priv:// or whatever) is compatible with existing security advice in a way that the TLD isn't

@mikewest
Copy link

Right now we tell people "the domain tells you who you're talking to, the protocol tells you [partially] about the privacy/security of that conversation"

I think you're overestimating the protocol's place in users' minds. Browsers have generally aligned on stripping the protocol from the address bar when the user isn't directly interacting with it, relying instead on iconography to represent (negative) security properties.

My point is that Keeping the kind of restriction discussed in this thread to the protocol (https-priv:// or whatever) is compatible with existing security advice in a way that the TLD isn't

Hostnames have the nice property of being backwards compatible with browsers. Protocols take some time to gain adoption, have more pervasive impact on core specifications (Fetch, for instance) and fail hard when unsupported.

That said, I don't have terribly strong opinions about this. I think the idea of creating a mechanism that allows us to lock in a set of guarantees a priori such that we can reason about them at request time is good. If folks align around protocols, I won't argue about it. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants