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

201–210 of 211 posts

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

#201

Post by tptacek »

virtuallynathan wrote: post #119
jlgaddis wrote: post #63

Earlier quoted context omitted.

> Actually not only does Comcast say they don't do that... Just like they said they didn't forcibly reset BitTorrent connections (until they did). Just like they said they didn't silently institute bandwidth caps (until they did). Just like they said they didn't hijack NXDOMAIN responses (until they did). Just like they said they didn't intercept plain-text HTTP connections and inject their own traffic into them (unt…

After the NXDomain redirection stuff, they invested a ton in doing DNS right, deploying DNSSEC and Anycast. They are a major participant in the IETF, DNS OARC, and many other industry working groups, if you attend these things, go talk to the Comcast folks! Their limited use of HTTP interception is a published RFC, and I've thought about ways to get around this, and for the use cases they use it for, it seems like th…

Why does it matter, at all, that Comcast documented their traffic interception system in an RFC?

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

#202

Post by chaostheory »

sprayk wrote: post #113
chaostheory wrote: post #30

Earlier quoted context omitted.

I also wonder what the RIAA and MPAA think of this? I know using a browser isn't ideal for piracy, but at the same time those two organizations are one of several major reasons why ISPs snoop on their customers.

does RIAA/MPAA snooping rely on DNS traffic at all? I was under the impression that the only thing RIAA/MPAA caught people for was the act of sharing, usually in the form of torrent seeding, and this was done by third parties they contracted out to who would provide a list of IPs they caught seeding. Then the list of IPs were resolved to ISPs who were sent subpoenas where they thought they had a good chance of ISP co…

Usually they primarily go after torrents, but some websites have caught their ire over the years.

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

#203

Post by tialaramex »

pbhjpbhj wrote: post #191
tialaramex wrote: post #115

Earlier quoted context omitted.

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 C…

I don't agree that choosing not to offer a product or service which is popular but which you believe is a terrible idea is "weirdly fascist".

I would suggest instead that demanding other people figure out whatever weird quirks you have and then cater to them under the guise of being "child friendly" is at best weirdly fascist.

And it seems you at least reluctantly agree this that can't work even if you wish A&A would try to do it anyway, since all the systems you listed involve you explicitly configuring what you want blocked, allowing you to take responsibility for the inevitable under/overblocking. This approach works fine† with A&A since it doesn't ask anything of them.

† Well, as "fine" as can be expected, no worse than at other providers.

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

#204

Post by efreak »

treve wrote: post #71
sandworm101 wrote: post #33

Earlier quoted context omitted.

>> Even if you change your DNS server from the default to 1.1.1.1 or whatever, your ISP can and does still read and/or intercept these requests. Not if VPNs/firewalls are properly implmented. Plugging DNS leaks is security 101.

I get that VPNs are considered more trustworthy by some (although so many also have shoddy records/ownership), but it's still 1 extra party to trust vs. just your DNS provider.

If your VPN is only being used for DNS queries, then they don't have much useful data there. I've recently seen instructions for setting this up on free cloud instances from AWS/Azure/etc. If the only traffic is DNS wrapped in VPN, it should stay within the free tier (especially if you add local caching, but even that shouldn't be necessary)

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

#205

Post by bwoodcock »

tptacek wrote: post #200
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.

Actually, most Quad9 users (in so far as we know, since we only know from those who contact us) are already running their own local caching resolver, and many of them are doing QNAME minimization, which is excellent. They use us to keep their cache misses from going in the clear, and because many of them have small enough user populations that their resolver still exposes individual user behavior.

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

#206

Post by Nemo_bis »

Nextgrid wrote: post #76
jlgaddis wrote: post #46

Let me make sure I've got this right: * Comcast sniffs / records / tracks their user's DNS traffic * Mozilla announced they would enable DoH by default, to protect end user's DNS data from shady ISPs like Comcast * Comcast then raised hell about Mozilla's decision (presumably because they would no longer have access to this data) * Now, Comcast and Mozilla come to some sort of agreement which effectively restores Com…

I don't understand why Mozilla should care or get involved at all into what Comcast thinks of them. Mozilla introduce a privacy feature in a free, open-source browser. Comcast bitches about it because it prevents them from doing shenanigans, essentially incriminating themselves and proving that the feature is both working as expected and necessary. Why does Mozilla need to care about Comcast's opinion on this, and tr…

> Why does Mozilla need to care about Comcast's opinion on this

Because Comcast has Washington in its pocket?

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

#207

Post by Nemo_bis »

mike_d wrote: post #177
mantap wrote: post #128

Earlier quoted context omitted.

If Comcast breaks the contract then Mozilla will simply change the default back to Cloudflare DNS.

Out of the pot into the fire. 24 years ago a group of Stanford students started Architext. They took a few million from Kleiner Perkins, called themselves Excite, and started a search engine and internet provider. They were a good, ethical, well ran technology company. Over the years bits and pieces were chopped up and merged and acquired and spun off based on what generated shareholder value. Parts of that old soul…

I sure hope that Mozilla writes contracts so that they can't be transferred by sale or merger. That's the most basic protection from your friendly counterparty joining your sworn enemy.

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

#208

Post by Nemo_bis »

beezle wrote: post #126
floatingatoll wrote: post #105

Earlier quoted context omitted.

It encrypts your DNS traffic over the public wire in a way that only the DOH endpoint operator can decrypt, preventing plaintext interception/modification attacks by unauthorized malicious actors positioned between you and the DOH endpoint It represents your DNS traffic over the wire as encrypted HTTPS traffic, which decreases the effectiveness of deep packet inspection and traffic shaping systems operated by some ne…

OK sure but what good is that when my next TCP/UDP activity after a dns lookup is to actually connect to that host? The upstream ISP knows exactly where you are going right? They can store and reverse that info and do with it as they wish.

That's unclear to me. By running DoH, Comcast gets to spy Comcast customers. But Comcast of course can already see what IP addresses talk with Comcast customers, so what changes really? That the spying might become marginally easier maybe?

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

#210

Post by WatchDog »

parliament32 wrote: post #195
WatchDog wrote: post #127

Earlier quoted context omitted.

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 T…

I think you are overestimating the resilience of TCP, yes it will probably eventually renegotiate, but you create a horrible user experience.

Have a read of some of the cloudflare engineering blogs, they give some sense of the technical challenges of deploying anycast.

I wouldnt recommend a company deploy connection based anycast services, unless they are prepared to spend a lot on the engineering challenges.

> Since packets will follow the shortest path, if a particular path is withdrawn then packets will find their way to the next shortest available route. For simple protocols like UDP that don't maintain state, Anycast is ideal and it has been used widely to load balance DNS for some time. At CloudFlare, we've done a significant amount of engineering to allow TCP to run across Anycast without flapping. This involves carefully adjusting routes in order to get optimal routing and also adjusting the way we handle protocol negotiation itself. While more complex to maintain than a Unicast network, the benefit is we can lose an entire data center and packets flow to the next closest facility without anyone noticing and hiccup.

https://blog.cloudflare.com/cloudflares-architecture-elimina...

> WARP was experiencing so many failures because devices were switching servers much more often than we expected. If you recall, our ECMP router configuration uses a combination of (Source IP, Source Port, Destination IP, Destination Port) to match a packet to a server. Destination IP doesn’t generally change, WARP clients are always connecting to the same Anycast addresses. Similarly, Destination Port doesn’t change, we always listen on the same port for WARP traffic. The other two values, Source IP and Source Port, were changing much more frequently than we had planned.

https://blog.cloudflare.com/warp-technical-challenges/

Post reply on HN