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

Comcast, Mozilla strike privacy deal to encrypt DNS lookups in Firefox

arstechnica.com

Post reply on HN
Print view View original

191–200 of 211 posts

Re: Comcast, Mozilla strike privacy deal to encrypt DNS lookups in Firefox

#191

Post by pbhjpbhj »

tialaramex wrote: post #115
pbhjpbhj wrote: post #93

Earlier quoted context omitted.

Given your disclosure presumably you know if it's true or not. It's a weird way to phrase "I work on this, we don't capture any information about customers site visits" or "I work on this we don't capture any information about domain lookups" or whatever. When a customer gets a contract with Comcast are you saying the contract includes that Comcast will not filter/log their domain lookups in any way? To others: what'…

UK ISPs could offer to operate a Mozilla TRR DoH server for two reasons: 1. The deal major "as seen on TV" ISPs struck was that they would offer a configurable child protection style filtering to their users. Mozilla permits users to opt in to filtering, you just aren't allowed to filter by default, so an ISP provided DoH server which can be configured explicitly to filter would meet this requirement. NextDNS offers…

I chose "oblige" carefully. Basically the ISPs AIUI/IIRC were given the option to voluntarily abide by a blocklist of domains - like thepiratebay - or have legislation made to force them to comply.

I'd heard A&A were an outlier here but didn't know they actively stopped users from choosing their service if they want filtering. That seems weirdly fascist: like a supermarket that won't let you choose not to have Coca Cola on your shopping list, if you don't want it you have to actively remove it yourself.

Porn, yes to some extent, but super-violence, torture, malware, gambling, prostitution, ... these are all things I choose to attempt not to pipe in to my home via OpenDNS/pihole/uBlock/direct instruction to local users!

Re: Comcast, Mozilla strike privacy deal to encrypt DNS lookups in Firefox

#192

Post by SAI_Peregrinus »

pabs3 wrote: post #170
SAI_Peregrinus wrote: post #37

Earlier quoted context omitted.

Only for sites with dedicated IPs. If they're hosted on some sort of cloud service then the ISP has to sniff the SNI data. And with ESNI coming to encrypt it that hole will be plugged soon.

I found this study interesting: "What can you learn from an IP?" https://irtf.org/anrw/2019/slides-anrw19-final44.pdf So essentially ESNI/DoH are only useful for websites on global CDN providers? Why would Mozilla be interested in enhancing those companies profits?

Or any other shared hosting. I never mentioned global CDNs, just "cloud" (somebody else's computer with other clients) hosting.

Re: Comcast, Mozilla strike privacy deal to encrypt DNS lookups in Firefox

#193

Post by SAI_Peregrinus »

pbhjpbhj wrote: post #109
SAI_Peregrinus wrote: post #38

Earlier quoted context omitted.

No need to disable Firefox's DoH support, just point it at your pihole as the DoH provider.

How do you do that without accessing each client, like how do I disable DoH on my home network for all devices without having to access all devices?

Well, there's the use-application-dns.net canary domain (if it resolves to a response code other than NOERROR or to NOERROR but lacks both A and AAAA records), Firefox will fall back to using the OS DNS. Otherwise it's up to the application, just like with DNS it's always been the application's choice whether to use the OS-provided DNS or to use their own (eg via proxy or VPN).

In short, you can't. But you never could stop an application from tunneling DNS over some other channel before, so that's nothing new.

Re: Comcast, Mozilla strike privacy deal to encrypt DNS lookups in Firefox

#194

Post by parliament32 »

sprayk wrote: post #116
parliament32 wrote: post #74

Earlier quoted context omitted.

You should just use anycast for that instead of trying to shoehorn it in with DNS trickery.

It's interesting that the DNS-based solution is considered "trickery", when I don't really know anyone except for very networking-focused people who can explain how anycast works to achieve the same thing. While BGP is definitely not magic, it feels way more magic to me than DNS. The DNS-based solution, in comparison, seems way simpler to explain: get general location of IP of requester, send back the IP of a server…

I'm only calling it "trickery" because DNS isn't supposed to work that way. The entire systems structure of authoritative resolvers to recursive resolvers to cachers depends on a record being the same regardless of external factors like location or source IP. Meanwhile, anycast was literally designed for this purpose. And it's been around since 1993.[1]

>explain how anycast works

Advertise your IP space in multiple locations. Traffic will come to the location closest[2] to it. There's nothing particularly complicated about it.

How the routing end of it works is up to the specific protocol you're using and whether this is external or internal... so it depends on BGP on the Internet (in the case we're talking about here), but you can also anycast on your internal network, and the routing will be handled by OSPF/IS-IS/whatever.

Further, effectively every large service online today uses anycast clusters. Do you think 8.8.8.8 goes to a single server? Cloudflare IPs? Google IPs? It's all anycast.

[1]https://tools.ietf.org/html/rfc1546

[2]"closest" is subjective, it's not necessarily the geographically closest, but the "best" path. This is decided by the specific protocol you're using, but generally you can assign costs/metrics to various routes to prioritize/deprioritize them. This is your netops team's problem, not yours, so for all intents and purposes you'll always get the "best" path.

Re: Comcast, Mozilla strike privacy deal to encrypt DNS lookups in Firefox

#195

Post by parliament32 »

WatchDog wrote: post #127
sprayk wrote: post #116

Earlier quoted context omitted.

It's interesting that the DNS-based solution is considered "trickery", when I don't really know anyone except for very networking-focused people who can explain how anycast works to achieve the same thing. While BGP is definitely not magic, it feels way more magic to me than DNS. The DNS-based solution, in comparison, seems way simpler to explain: get general location of IP of requester, send back the IP of a server…

Running any connection/TCP based service on an anycast IP seems to require a large and effective network operations team. Dealing with BGP route flapping, single connection traffic being split between different servers, is a difficult problem that requires extensive relationships among other network operators. Implementing EDNS Client Subnet, on the other hand is pretty simple.

The joke is you have to use anycast if you want any redundancy in your network. If you advertise your address space on a single upstream you're praying that they never have any issues.

>BGP route flapping

So what? Your traffic will go over to one of the other locations you're advertising on, and you keep ticking along merrily, with some extra latency.

>single connection traffic being split between different servers

That shouldn't happen. Keep in mind traffic just gets driven to your router, from there you load balance as you see fit. Unless you mean split between different ingress points -- TCP will happily renegotiate with very little overhead, if you're getting more serious issues your application sucks and should should be more resilient to connection state changes (if this is causing you problems, you're probably also dropping users who switch mobile to wifi...). Not to mention that these kinds of path cost updates are pretty rare on the real internet, you're not going to see this more often than once a month maybe.

Re: Comcast, Mozilla strike privacy deal to encrypt DNS lookups in Firefox

#196

Post by SAI_Peregrinus »

the8472 wrote: post #45
SAI_Peregrinus wrote: post #37

Earlier quoted context omitted.

Only for sites with dedicated IPs. If they're hosted on some sort of cloud service then the ISP has to sniff the SNI data. And with ESNI coming to encrypt it that hole will be plugged soon.

That just means moving from the ISP in a prime position for snooping to various CDNs being in that prime position. You traded one master for another.

Only if the site is using a CDN. I said some sort of "cloud" service, which (IMO, it's an admittedly fuzzy term for someone else's computer) includes shared hosting providers. All together there are a LOT of shared hosts out there, not just AWS, Azure, and GCP. So collating all your habits becomes much harder.

Re: Comcast, Mozilla strike privacy deal to encrypt DNS lookups in Firefox

#197

Post by a1369209993 »

a1369209993 wrote: post #140
sprayk wrote: post #116

Earlier quoted context omitted.

It's interesting that the DNS-based solution is considered "trickery", when I don't really know anyone except for very networking-focused people who can explain how anycast works to achieve the same thing. While BGP is definitely not magic, it feels way more magic to me than DNS. The DNS-based solution, in comparison, seems way simpler to explain: get general location of IP of requester, send back the IP of a server…

> I don't really know anyone except for very networking-focused people who can explain how anycast works to achieve the same thing. I'm not familiar with the crap the IETF et al have smeared on it, but in principle , it's very simple: each network vertex maintains a mapping from (blocks of) addresses to edges (and the neighbors on the other ends of each edge) moving closer to that address, such that the directed edge…

> but in principle, it's very simple

Er, very simple provided that you're already doing doing unicast routing, that is. There are plenty of complexities, they just almost all already exist even without any anycast addresses.

Re: Comcast, Mozilla strike privacy deal to encrypt DNS lookups in Firefox

#198

Post by parliament32 »

a1369209993 wrote: post #197
a1369209993 wrote: post #140

Earlier quoted context omitted.

> I don't really know anyone except for very networking-focused people who can explain how anycast works to achieve the same thing. I'm not familiar with the crap the IETF et al have smeared on it, but in principle , it's very simple: each network vertex maintains a mapping from (blocks of) addresses to edges (and the neighbors on the other ends of each edge) moving closer to that address, such that the directed edge…

> but in principle, it's very simple Er, very simple provided that you're already doing doing unicast routing, that is. There are plenty of complexities, they just almost all already exist even without any anycast addresses.

Exactly, if you're already doing routing/advertisements anycast just boils down to "advertise from multiple places at once" and it basically just works. If you're not doing your own routing this isn't a conversation for you.

Re: Comcast, Mozilla strike privacy deal to encrypt DNS lookups in Firefox

#199

Post by pwdisswordfish2 »

smichel17 wrote: post #187
pwdisswordfish2 wrote: post #114

Earlier quoted context omitted.

When pigs fly! Can you imagine Mozilla CEO depleting her own compensation in order to sue a company the size of Comcast? What exactly are the claimed damages in this hypothetical lawsuit? The damages to Mozilla are _____ ? (This PR piece in Ars suggests the deal is solely to protect users. No financial details.) How about the damages suffered by users? (Whoops, they are not parties to the agreement.) Quite the vivid…

Hypothetically, I imagine they'd sue for damage to their brand. Mozilla has been pushing Firefox as the privacy browser, and if Comcast were to break the deal it would hurt users' trust in Mozilla. I agree it is unclear what the consideration from each party is, though.

Comcast does not appear to be using the Mozilla brand. Am I missing something?

Re: Comcast, Mozilla strike privacy deal to encrypt DNS lookups in Firefox

#200

Post by tptacek »

shirro wrote: post #134

Tin foil hat time but I can't help feeling a lot of things promoted as privacy solutions like VPNs and DoH are just aggregating data in a handful of locations so it is easier to intercept. Sure they have privacy policies but are they worth the paper they are written on when state actors are bound by a totally different set of rules? I recently changed my local dnssec resolver to forward to quad9 and cloudflare using…

If you're in the US, you can't trust your ISP (most of them farm DNS data), and shaking your fist at the clouds won't change that. If you don't Cloudflare or Quad9, stand up your own DoH server somewhere; it's trivial to do.
Post reply on HN