There is nothing that Comcast can do that would increase my opinion of them re privacy. In my security regime ISPs like them are on the other side. Last-mile ISPs are unsecured public networks that shouldn't be trusted any more than free airport wifi. I want them blind to everything I (and my client) does online. Encrypt everything. Route DNS to trusted non-profit entities. Serve me the encrypted data I request but otherwise I don't want to even have a conversation with Comcast.

> Route DNS to trusted non-profit entities.

I'm sure you know this, but some readers might not. DNS is totally insecure. 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. This sort of interference is absolutely trivial to implement, even at scale. Don't think it isn't happening to you.

... which is exactly why DoH is gaining attention.

But I keep wondering: Can't the ISP trivially correlate the accessed IP addresses with their corresponding sites even without DNS query data?

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.

>You traded one master for another.

No. By definition, last mile ISP sees 100% of net-bound traffic. "Various CDNs" itself already represents a dilution of that view, and are not universal themselves. It's an inherent improvement even outside of other factors. But there are other factors, including a decrease in the level of natural monopoly. Last-mile ISPs often have zero effective competition, and even with one or two there are often high change over costs, longer term contracts involved, etc. The closer you get to the net's core however, the more bandwidth there is and the more players there are and in turn vastly more competition potential. That's not a guarantee sure, but it absolutely makes a difference. There's also a limiting factor principle at work: even if you do trust a given ISP, how does that help you avoid CDNs anyway?

It's the same reason that spinning up your own instance of an algo VPN on some VPS and funneling all your home and mobile traffic through that may have practical benefits. Sure in principle the VPS (or data center if you go on your own metal) provider could try spying as well. But competition there is fierce, the average technical level of users is higher, major business interests are involved in reputation, and swapping to another provider is utterly trivial. The incentives and business models for the likes of Amazon/DigitalOcean/Google/Microsoft/OVH/Scaleway/Vultr/[...] in their compute offerings are completely different from the likes of AT&T/Charter/Comcast/T-mobile/Verizon. So it is in fact reasonable to expect a difference in the level of shenanigans too, and hey, if not you can easily move, which also in turn makes it much easier as a practical matter to retaliate (sue), which virtuously further decreases the likelihood of shenanigans.

You have a contractual relation with your ISP and they're in your jurisdiction so at least in theory you have legal recourse.

Advocating for ESNI on the other hand means argueing for more centralization towards entities which are far more removed from you where you have little recourse. So as far as incentives go they may be more beholden to some law enforcement agency than you the non-customer.

There are difference, but it does not appear to be an obvious improvement to me.

I think you bring up good points but your takeaway is 180 off.

Different jurisdiction means less likely to be answerable to your local government should they be oppressive.

The fact you don't have a contractual relationship with a CDN is a good thing because it becomes trivial simply to stop using them, should the need arise. Don't like Cloudflare? block them. Your choice of websites will be reduced greatly but you still have an operational internet connection.

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.

Let's try the one that hasn't eagerly and willingly (that we know of) gone against their users.

That heavily depends on who those parties are. E.g. a european might trust their local ISP (subject to GDPR) more than an american CDN (subject to the cloud act and NSLs).

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.

Also don't forget about SNI. This exposes the domain you're connecting to over TLS. Yes, I know eSNI is a thing, but it's new and so unlikely to be deployed much.

Trivial in the individual case is not trivial at scale.

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

I'm very suspicious of Comcast too. They've had hostile policies in their Internet management for as long as I can remember, going back to the days they'd forge RST packets because they didn't like customers using BitTorrent.

OTOH as the article says, 'Joining Mozilla's program means that Comcast agreed that it won't "retain, sell, or transfer to any third party (except as may be required by law) any personal information, IP addresses, or other user identifiers, or user query patterns from the DNS queries sent from the Firefox browser'.

I assume Mozilla will audit and keep Comcast honest here, or at least try. I just am left wondering what loophole Comcast has found.

I hit commit on that feature. Sorry.

It's not just Comcast. Every ISP that uses Akamai's software to power their ISP has this ability and possibly uses it, just not in obvious ways. And given that almost every ISP in the US, let alone the world, uses this software, well.. that's just how it is.

Though, it's http only. You can always switch to https and they can not do anything. There is no key injection or anything going on thankfully. Also, encrypted DNS should make it moot as well.

How would encrypting DNS help me avoid Comcast MITMing my HTTP traffic to inject bandwidth cap notifications? Doesn't the system just inject a script tag into the appropriate place in the HTTP response?

HTTPS Everywhere + encrypted DNS blocks a huge chunk of what they can see without expending effort on you in particular

FYI if you block this notification (it requires the script tag to load and you to click an I AGREE TO PAY PER GB bullshit thing), you can no longer do UDP traffic and your TCP connections start getting reset.

I found this out the hard way, because I browse nearly all HTTPS sites, and uBlock blocks the injected malware script on the few plaintext sites and never really noticed.

Your IP changes into a shared Comcast-run squid proxy one, all TCP ports are no longer available other than 80/443 filtered through squid, all UDP is no longer available.

that is not what I was asking. GP claimed that encrypted DNS would stop comcast from injecting notifications into HTTP traffic, I want to know how that would work, in the hopes that my assumptions about the system are wrong.

You make a good point. I worked on the code before encrypted DNS was a thing (or anything I knew about) so I'm going off of theory, not first hand experience.

When a request is sent for a http web page it is ran through the layer 4 proxy. In there is a user profile where http injection can occur. It works by injecting JavaScript into the end of the web page.

If the dns request is encrypted all of the handshaking goes through tls bypassing the proxy's view of this data for everything except disconnected http body data. However, it could be that as years have gone by it's been updated to take in http data without any sort of head and then it would work again. It's probably as simple as running some regex looking for </html>.

So, me in my half awake state this morning didn't really think it through. In previous versions of the software this wouldn't be supported, but in hindsight it's not a terribly difficult problem to fix, so Comcast probably does support HTTP injection even when using encrypted DNS by now. My apologies.

I don't care what their intent is. Interception and injection from a third party is bad.

With technology there are many ways to achieve the goal of notifying a customer without foul play.

Agreed, if it was cloudflare I would have at least given them the benefits of a doubt, but not Comcast.

Cloudflare is harmful to independent CDN's. They hide the originating i.p. address (no other does it) to the nameserver in the name of "privacy" so you can only have as much granularity as the nearest cloudflare server to user (anti-competitive). That is unless you buy an ipv4 block (because everyone is still on ipv4) and set up anycast.

For non 1.1.1.1 dns users I can just set up varnish and they'll be served via GEO ip lookup so the domain gets pointed to the nearest ip address. This is much cheaper. I'm not going to buy an ipv4 block just for cloudflare dns users.

Their privacy claim is a lie because your webserver is going to be exposed to the end user i.p. address anyways after resolving from the nameserver.

Not forwarding EDNS client subnet is a requirement for Mozilla TRR partners. NextDNS also doesn't forward EDNS subnet client since it is a partner and soon Comcast will be joining that list. Although not currently a member of the program Quad9 also by default doesn't forward EDNS subnet info.

I host my name server's myself. If Mozilla is really doing this, they're misguided. All this does is make it impossible to serve requests from nearest webserver. You are getting the ip address anyways, so why do this? This means if I get someone from netherlands I'd have to redirect their requests from www.example.com to nl.example.com or buy an ipv4 block, set up anycast and then serve from the closest ipaddress/server. The end result is same. I'll always get the end user's ip address unless they use a VPN or something.

This is a stupid decision by Mozilla. Too bad Firefox users when visiting websites making their own CDN's without anycast/country level redirects will see much slower sites.

What you're claiming is false.

Cloudflare has over 200 PoPs; in your own name servers, you can use the Cloudflare Resolver's IP (which will be a "close to the user" IP, not 1.1.1.1) to do geotargeting and serve from your closest IP address/server.

>What you're claiming is false. Cloudflare has over 200 PoPs; in your own name servers, you can use the Cloudflare Resolver's IP (which will be a "close to the user" IP, not 1.1.1.1) to do geotargeting and serve from your closest IP address/server.

What if my server is closer than cloudflare? Why is cloudflare artificially limiting?

I use cloudflare precisely because I don't want clients hitting the server directly. That's its entire purpose. For both caching and anti-ddos reasons.

rydre is specifically talking about the perspective of someone running a non-cloudflare CDN or possibly a site that does their own CDN with DNS rather than anycast because they explicitly don't want to use cloudflare for whatever reason. They are not talking about someone just hosting a site.

You will always get the IP because you host the nameserver and the web server. In many cases, the nameserver is hosted by a third party. Doesn’t what Mozilla and Cloudflare have done prevent the nameserver from receiving the originating IP, thus preventing large nameservers from generating user traffic histories? This is an honest question. I’m not fully familiar with the process of running a nameserver.

EDIT: I associated the name Cloudflare with the main product. I forgot the context of this being about DNS and therefore my comment is about Cloudflare CDN not 1.1.1.1

> Cloudflare is harmful to independent CDN's.

Cloudflare is a competitor to CDNs. You don't need to use a CDN with Cloudflare, they proxy your content fully and do caching along the way as needed.

> Their privacy claim is a lie because your webserver is going to be exposed to the end user i.p. address anyways after resolving from the nameserver.

It's not a lie. Cloudflare is the nameserver, and the CDN. So after resolution the end user still has just a Cloudflare IP.

> It's not a lie. Cloudflare is the nameserver, and the CDN. So after resolution the end user still has just a Cloudflare IP.

> In 2011 Google wrote an IETF draft to send Client IP information using the EDNS0 extension and this is usually called ‘edns-client-subnet’. As a DNS client, it means that a truncated version of your IP address will be added into the DNS request. The DNS server will use this truncated IP address to make a more informed decision in how it responds so that you can be connected to the most optimal server. This standard is promoted by the Faster Internet initiative and already adopted by some leading vendors.

Because it is designed to keep privacy, the sender has the freedom to limit the client IP information. Instead of sending a full IP address, the DNS server is able to send partial information such as /24 only. For instance, if your IP address is 66.214.81.22, the DNS server will only expose the first three octets, so 66–214–81. Armed with the real IP address of the querying device, the DNS server can now come up with a much more accurate response. With this more intelligent routing, customers have a better Internet experience with lower latency and faster speeds. Best of all, this integration is being done using an open standard that is available for any company to integrate into their own platform.

source: https://engineering.salesforce.com/why-is-edns-important-for...

Cloudflare 1.1.1.1 for consumers kills EDNS "edns-client-subnet" and instead offers the ip of the nearest cloudflare server to the user even if the website is not using cloudflare. This means your website can not ever serve content faster then cloudflare even if you could potentially be faster.

This is the reason why many internet archives do not allow access to cloudflare client dns (1.1.1.1) users as a form of protest.

BTW, Cloudflare allows you to get informed about the end user's ip via a "x-forwarded-for" header.

There is only a single "archive" that does not allow access to Cloudflare DNS users - not many.

It is also exceedingly unlikely that you have greater density of anycast PoPs than Cloudflare's 200+. In your case, you have zero...

Akamai has more than 200 pops and do geodns to stear traffic.

If I compare cloudflare DNS vs Google DNS, I can see a difference of ~50ms between the Akamai POPs offered.

https://pastebin.com/raw/xFQb4pVF

Even archive.today has given up on that crusade; I noticed a few days ago that they don't block me anymore (I use Cloudflare DNS) so they have to have stopped within the past couple weeks.

So now AFAIK the number of sites that block DNS resolvers which do not forward edns-client-subnet is zero. As it should be.

They continue to attempt to try to associate your connections/use dns cookies. CtrlF 'pixel' when you are visiting one of their pages (not frontpage)

They also attempt to correlate .onion traffic.

I think you’re confusing how CloudFlare can hide the server IP from the user (to protect against DDoS) versus how CloudFlare DNS hides the client’s IP from the name server, even though the Client IP is exposed to the web server by Cloudflare, and of course standard Cloudflare is irrelevant if the requested site isn’t using the Cloudflare service in the first place.

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 cooperation. Is there some legal, warrantless wiretapping I'm not aware of?

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

> Considering that Comcast sniffs, intercepts, and injects into HTTP web sites

You think that is bad ? If you get a connection from India's 'premier' public telco BSNL, you'll be treated to ad-injections for random malware straight into your HTTP page.

"Your govt. welcomes your appreciation for its 'top-notch' services."