Surveillance capitalism will transform the domain name system(zdnet.com)
zdnet.com
Surveillance capitalism will transform the domain name system
https://www.zdnet.com/article/how-surveillance-capitalism-will-totally-transform-the-domain-name-system/
63 comments
> The cause of an arms race isn't arms. It's the inability to come to terms on an issue. We should be addressing the issue
No, there are no compromises with these people. What they do is completely unacceptable. We want them to stop. Just cease all surveillance operations.
Asking them nicely does nothing. They just refuse. So we'll fight them with technology of our own.
No, there are no compromises with these people. What they do is completely unacceptable. We want them to stop. Just cease all surveillance operations.
Asking them nicely does nothing. They just refuse. So we'll fight them with technology of our own.
Hence, arms race, which "we" will lose because "they" have money and power.
I have configured local Unbound to use four different open DNS provideds, round-robin, the rationale being each one gets 1/4th of requests. On the other hand, I am sending requests to four providers instead of one, so I have to trust four providers instead of one. What’s better?
You can set up recursive resolver to query directly the DNS root servers.
https://www.iana.org/domains/root/servers
https://www.iana.org/domains/root/servers
> What’s better?
4 providers, at the same time, all times.
It is wasteful but you can run the alarms when responses don't match.
4 providers, at the same time, all times.
It is wasteful but you can run the alarms when responses don't match.
But responses will not match for legitimate reasons of dynamic configuration at specific domains.
This isn't a concrete software recommendation, but the DNS would lend itself exceptionally well to a distributed p2p resolver that would prevent most queries from hitting centralized servers in the first place - it's just a simple distributed database. You'd need some sort of multiparty trust metric to avoid tampering (or DNSSEC), but modulo that peers could just freely pass around records.
There would be a little more complexity these days with large companies changing answers based on the address of the requester, but that doesn't seem too hard to account for or even just ignore. And to reduce traffic even further, you could take some liberties with TTLs, for records that actually don't change often.
There would be a little more complexity these days with large companies changing answers based on the address of the requester, but that doesn't seem too hard to account for or even just ignore. And to reduce traffic even further, you could take some liberties with TTLs, for records that actually don't change often.
What about remote address correlation? DNS is transmitted in plaintext. Transit providers could evasedrop on your traffic and short circuit your work.
They could sniff but not tamper as long as you are using DNSSEC.
At least you've removed one single point of failure for DNS lookups.
"One way to make DNS surveillance more difficult is to use a public open DNS server, such as Google's 8.8.8.8..."
Lol
Lol
[deleted]
"Knowing the domain names of the websites you visit, or servers that apps access on your behalf, is valuable intelligence. DNS traffic is especially valuable because it reflects what users are doing in real time.
"The names you asked for, and when you ask for them, say an awful lot about you," Huston said in his presentation to the APNIC 52 conference on Wednesday."
This goes on the assumption that a DNS request and HTTP request are coupled in time. They can be decoupled.
Ive been gathering DNS data in bulk for many years. This can be done, e.g., by making UDP/TCP DNS requests to the appropriate authoritative nameservers, making UDP/TCP requests to DNS caches run by third parties (this is what developers seems to prefer; its an inefficient, inconsiderate and braindead method, IMO), extracting the data from public scan datasets available for download, extracting from passive DNS datasets, and most recently making pipelined HTTP requests to DoH servers over a single TCP connection. Its good to have multiple sources of DNS data so one can note any differences.
A surveillance capitalist acting as a passive DNS data or DoH provider could be observing this data gathering but it would be difficult to connect any subsequent HTTP requests, separated in time, days, months or years later, with particular domainnames. With the way CDNs are used today, a large percentage of these domainnames can be requested from the same IP address. Obviously CDNs can have troves of data on users' browsing habits. Perhaps surveillance capitalists approach CDNs to get data about users.
What this article fails to mention is TLS 1.2 leaking domainnames in certificates and SNI extensions, in plaintext. Using third party DNS like Google, or even "Oblivious DNS" wont stop ISPs and others on path from seeing every domainname for every site the customer visits. TLS 1.3 with ESNI will fix this but its still experimental and Cloudflare is the only host I am aware of that supports it. Nevertheless I use it and it works well. For non-Cloudflare sites that require SNI (its quite a small of the sites submitted to HN) I use archive.org. Of course, I am trusting that archive.org isnt engaged in "surveillance capitalism". :) Another trick for Cloudfront hosted sites is one can use the [hash].cloudfront.net domainnname for SNI instead of the "real" domainname. If only mall number of customers are doing this, it makes more work for ISPs or marketers for very small reward, but its a trivial amount of work. Archive.org is the best solution I have so far.
For recreational web use, I have stopped using DNS altogether. I let the forward proxy store the IP address info for each host in memory. Its very fast.
"The names you asked for, and when you ask for them, say an awful lot about you," Huston said in his presentation to the APNIC 52 conference on Wednesday."
This goes on the assumption that a DNS request and HTTP request are coupled in time. They can be decoupled.
Ive been gathering DNS data in bulk for many years. This can be done, e.g., by making UDP/TCP DNS requests to the appropriate authoritative nameservers, making UDP/TCP requests to DNS caches run by third parties (this is what developers seems to prefer; its an inefficient, inconsiderate and braindead method, IMO), extracting the data from public scan datasets available for download, extracting from passive DNS datasets, and most recently making pipelined HTTP requests to DoH servers over a single TCP connection. Its good to have multiple sources of DNS data so one can note any differences.
A surveillance capitalist acting as a passive DNS data or DoH provider could be observing this data gathering but it would be difficult to connect any subsequent HTTP requests, separated in time, days, months or years later, with particular domainnames. With the way CDNs are used today, a large percentage of these domainnames can be requested from the same IP address. Obviously CDNs can have troves of data on users' browsing habits. Perhaps surveillance capitalists approach CDNs to get data about users.
What this article fails to mention is TLS 1.2 leaking domainnames in certificates and SNI extensions, in plaintext. Using third party DNS like Google, or even "Oblivious DNS" wont stop ISPs and others on path from seeing every domainname for every site the customer visits. TLS 1.3 with ESNI will fix this but its still experimental and Cloudflare is the only host I am aware of that supports it. Nevertheless I use it and it works well. For non-Cloudflare sites that require SNI (its quite a small of the sites submitted to HN) I use archive.org. Of course, I am trusting that archive.org isnt engaged in "surveillance capitalism". :) Another trick for Cloudfront hosted sites is one can use the [hash].cloudfront.net domainnname for SNI instead of the "real" domainname. If only mall number of customers are doing this, it makes more work for ISPs or marketers for very small reward, but its a trivial amount of work. Archive.org is the best solution I have so far.
For recreational web use, I have stopped using DNS altogether. I let the forward proxy store the IP address info for each host in memory. Its very fast.
ESNI is superseded by a better design and implementation called ECH. It’s still not widely available, but has been available in Firefox. Cloudflare, of course, supports it (Fastly is the third co-author of this).
Links (dated January 2021):
https://blog.mozilla.org/security/2021/01/07/encrypted-clien...
https://blog.cloudflare.com/encrypted-client-hello/
Links (dated January 2021):
https://blog.mozilla.org/security/2021/01/07/encrypted-clien...
https://blog.cloudflare.com/encrypted-client-hello/
instead of firefox as the ech client, its possible to use esni/ech-enabled openssl together with proxy, so can use any tcp client, not just web browsers or only certain web browsers. because i use openssl i dont have to wait for firefox releases.
the "bleeding edge" ech is not in firefox. the above link says firefox is still stuck on drafts 08 and 09. openssl is on drafts 10 and 13.
the "bleeding edge" ech is not in firefox. the above link says firefox is still stuck on drafts 08 and 09. openssl is on drafts 10 and 13.
I am not happy with the design of ESNI as in its current form it is not straightforward to implement as it relies on dns hackery. I would rather instead that the outer tunnel be encrypted using a cert for the IP address, and the inner tunnel as before using the cert for the domain. This is analogous to how EAP works with an outer and inner identity.
only reason esni is even usable now is because its with a cdn. one key works for hundreds of thousands of websites. having to request a different key for every website would be far too much hassle. its a shame whenever folks write about encryoted sni they never offer the user perspective of sni which is that the sni extension prioritises cost savings for websites and increased business for cdns over privacy for users. sni was never something users needed. it may have solved a problem for websites who didnt want to pay for dedicated ssl certs (arguably, this has since been better solved by lets encrypt), and created a business opportunity for cdns, but it has created a new problem for users.
> One way to make DNS surveillance more difficult is to use a public open DNS server, such as Google's 8.8.8.8
I assumed Google ran 8.8.8.8 to collect data for targeted advertising, as one of the major players in surveillance capitalism. Am I mistaken?
I assumed Google ran 8.8.8.8 to collect data for targeted advertising, as one of the major players in surveillance capitalism. Am I mistaken?
There are at least two ways of looking that make using 8.8.8.8 sense.
First is that if you assume that Google has a decent profile of you anyways (from other services), then feeding in DNS data to Google would have relatively minor impact on your privacy.
Second is that at least Google is relatively competent and restrictive in providing any of the important data to 3rd parties, whereas other providers (like your ISP) is more like to sell the data wholesale left and right.
Both are sort of "better the devil that you know" ways of thinking.
First is that if you assume that Google has a decent profile of you anyways (from other services), then feeding in DNS data to Google would have relatively minor impact on your privacy.
Second is that at least Google is relatively competent and restrictive in providing any of the important data to 3rd parties, whereas other providers (like your ISP) is more like to sell the data wholesale left and right.
Both are sort of "better the devil that you know" ways of thinking.
> Second is that at least Google is relatively competent and restrictive in providing any of the important data to 3rd parties, whereas other providers (like your ISP) is more like to sell the data wholesale left and right.
While this is true (of all the entities trying to gather my data I'd expect Google to be one of the least likely to leak it - after all, no matter your preconceptions, Googlers are usually pretty good at what they do) it's at least somewhat moot because while your ISP (or, say, MasterCard) is more likely to sell your data, Google is more likely to be buying that data (from, say, MasterCard). If any basket acquires more than a certain percentage of my eggs (or footprints), I start to get uncomfortable.
While this is true (of all the entities trying to gather my data I'd expect Google to be one of the least likely to leak it - after all, no matter your preconceptions, Googlers are usually pretty good at what they do) it's at least somewhat moot because while your ISP (or, say, MasterCard) is more likely to sell your data, Google is more likely to be buying that data (from, say, MasterCard). If any basket acquires more than a certain percentage of my eggs (or footprints), I start to get uncomfortable.
According to Google [1], they keep client IP addresses and DoH headers for up to 48 hours and then strip them after that, and don’t use the logs for any personalization.
Everyone else here is assuming you can’t trust what they say, but it’s worth pointing out that, if they’re telling the truth, none of the rest of this privacy discussion matters.
[1] https://developers.google.com/speed/public-dns/privacy
Everyone else here is assuming you can’t trust what they say, but it’s worth pointing out that, if they’re telling the truth, none of the rest of this privacy discussion matters.
[1] https://developers.google.com/speed/public-dns/privacy
But ideally you shouldn’t have to trust them.
Sure, which is why Oblivious DNS would be a nice upgrade. One less thing to worry about.
But I expect that, compared to 8.8.8.8 or 1.1.1.1, the user experience will be unaffected, and there will be no measurable improvement in user privacy. (Because we have no way to measure it unless something bad happens and it can somehow be traced back to one of these DNS services.)
But I expect that, compared to 8.8.8.8 or 1.1.1.1, the user experience will be unaffected, and there will be no measurable improvement in user privacy. (Because we have no way to measure it unless something bad happens and it can somehow be traced back to one of these DNS services.)
Anything that gets people online and able to use google's services is good for google.
They claim to not use it for targeted advertising. https://developers.google.com/speed/public-dns/privacy
They claim to not use it for targeted advertising. https://developers.google.com/speed/public-dns/privacy
I've been using OpenDNS for years on the same basis... am I just being naive to assume they're not as bad?
Whatever happened with namecoin?
DNS is getting rather long in the tooth and I expect it will be replaced largely RSN. Article assumes we will keep internet address assignment the same as well and not at least move to IPV6 and a less stingy model of effectively static addresses. And the use of VPN today and something rather different tomorrow will likely change this. What happens when you effectively throw an authenticated request into some pool/queue of outstanding request and something else pools it and forwards it then putting response in pool? The assumed direct link of packet IP address to website that is fixed is not likely to last so long imho. Already we are starting to see blockchain mediated DNS like services. I would not be surprised by some kind of NFT registration of sites.
What does RSN mean here?
What cannot you do with traditional internal DNS that you can do with those newfangled DNS replacements? They offer censorship resistance and potentially a much lower cost to register your name, but they have plenty of drawbacks too.
Quite frankly, I suspect I might be getting trolled by GPT-3, but I'm asking the question anyway for the benefit of the community.
What cannot you do with traditional internal DNS that you can do with those newfangled DNS replacements? They offer censorship resistance and potentially a much lower cost to register your name, but they have plenty of drawbacks too.
Quite frankly, I suspect I might be getting trolled by GPT-3, but I'm asking the question anyway for the benefit of the community.
Regional Sports Network?
Check https://handshake.org/ it has the potential to overthrow DNS and CA while also providing real ownership to names.
The real problem here is "overthrow" vs "work with"
That was handshakes biggest mistake
That was handshakes biggest mistake
The handshake team itself has never used language like "overthrow", and have carefully designed the system to work with DNS, not necessarily replace it. From their FAQ:
> Does Handshake replace DNS?
No. Handshake is meant to replace the root zone file, not DNS. Browsing the web with human readable names is what Internet users have gotten acclimated to. Our solution allows for a seamless transition between a centralized name root zone file controlled by private parties to a decentralized root zone file controlled by actual Internet users. The Handshake blockchain itself is essentially one big distributed zone file in which anyone has the right to add an entry in.
https://handshake.org/faq/
> Does Handshake replace DNS?
No. Handshake is meant to replace the root zone file, not DNS. Browsing the web with human readable names is what Internet users have gotten acclimated to. Our solution allows for a seamless transition between a centralized name root zone file controlled by private parties to a decentralized root zone file controlled by actual Internet users. The Handshake blockchain itself is essentially one big distributed zone file in which anyone has the right to add an entry in.
https://handshake.org/faq/
They have in fact used phrases like "overthrow" and "collision course"
You have to look at their behavior and communications over time and beyond their website
Some of the community wants to aggressively replace ICANN, that is the context, not changing how DNS works.
https://github.com/handshake-org/hs-names/issues/6#issuecomm...
This is the flaw, being an uncooperative community member in the DNS ecosystem
You have to look at their behavior and communications over time and beyond their website
Some of the community wants to aggressively replace ICANN, that is the context, not changing how DNS works.
https://github.com/handshake-org/hs-names/issues/6#issuecomm...
This is the flaw, being an uncooperative community member in the DNS ecosystem
The word "overthrow" is not used anywhere in that thread.
"Collision" is used 26 times, mainly referring to name collisions between different root zone domains or to the ICANN NCAP project (Name Collision Analysis Project).
"Collision Course" is used only once, by a contributor who was not part of the original Handshake team but joined and became a major contributor later.
Hardly representative of the entire community, and definitely not of the founding team.
"Collision" is used 26 times, mainly referring to name collisions between different root zone domains or to the ICANN NCAP project (Name Collision Analysis Project).
"Collision Course" is used only once, by a contributor who was not part of the original Handshake team but joined and became a major contributor later.
Hardly representative of the entire community, and definitely not of the founding team.
the context for that comment is that handshake took a snapshot of the icann namespace. so any names icann adds or changes after the fact will conflict with the HNS namespace.
The comment is the start of a longer thread that is one data point in understanding how HNS would rather be adversarial than cooperative, from my perspective and others. Much of the crypto public speak is about replacing rather than enhancing existing systems. There is no join, only beat. They would likely become the very thing they desire to replace. It's human nature
There are factions within crypto, some think the "end of history" looks like crypto replacing centralized systems. others (like myself) think those systems are complements and simply alternatives in the marketplace.
As to being adversarial... ICANN was allocated 1.2% of the total HNS supply, and all existing TLD owners (at the time of the snapshot) can claim their TLDs on chain. The icann allocation is 5.8% of the current circulating supply.
i suppose there could have been a way to give ICANN a blank check to modify the handshake namespace in perpetuity, but i suspect that might either be technically unworkable or just made the whole venture pointless.
As to being adversarial... ICANN was allocated 1.2% of the total HNS supply, and all existing TLD owners (at the time of the snapshot) can claim their TLDs on chain. The icann allocation is 5.8% of the current circulating supply.
i suppose there could have been a way to give ICANN a blank check to modify the handshake namespace in perpetuity, but i suspect that might either be technically unworkable or just made the whole venture pointless.
[deleted]
It sounds great. Do you use it? Curious to learn about people's experiences with it and things like it. Centralized control over DNS is flawed, and I would like to see more solutions to this problem deployed and in use. Unfortunately, many HNers will immediately scoff at the mere mention of blockchain.
I scoff at the plethora of pointless blockchains shoehorned into a problems where neither centralization nor trust are essential complexity of the problem domain. Most new blockchain tech claims that they'll solve centralization and trust (in a domain that doesn't have those problems) -- as long as you centralize on their platform and trust them. Most blockchain is a whitewash for new-age centralization.
But DNS does have those problems inherent in the domain. It's one of the very few use-cases for blockchain that actually makes a modicum of sense.
But DNS does have those problems inherent in the domain. It's one of the very few use-cases for blockchain that actually makes a modicum of sense.
It was actually one of the legit uses of blockchain. It actually replaces ICANN, not DNS. There are registrars that have built on top of HNS, but serving DNS requests still uses the same tools and tech.
A couple of problems with it is that the do not prevent existing domains from transacting (unless you are in the top 100k) and the real big problem is the same guy who ruined Freenode, essentially controls handshake.
A couple of problems with it is that the do not prevent existing domains from transacting (unless you are in the top 100k) and the real big problem is the same guy who ruined Freenode, essentially controls handshake.
Unless a blockchain based DNS is involved with a blockchain currency, I see nothing to stop the mad grab of all memorable, pronounceable, or legible names less than 40 characters long almost immediately.
If I was so inclined to participate, I'd just grab a ton of blockchain DNS names, back them up, and hope I can sell one someday.
If I was so inclined to participate, I'd just grab a ton of blockchain DNS names, back them up, and hope I can sell one someday.
From a NamePros thread [1]:
> artdao.eth bought for 59Ξ ($191711.65)
> tara.eth bought for 6Ξ ($21797.16)
> keira.eth bought for 15.0Ξ ($51192.90)
> protein.eth bought for 10.0Ξ ($32484.00)
> esports.eth bought for 2.76Ξ ($10699.55)
> fidenza.eth bought for 30.0Ξ ($107111.40)
> artblockscurated.eth bought for 7.0Ξ ($24992.66)
There are tons of similar sales apparently. Some of it just doesn't make sense. $200k for artdao.eth? Really? The last two are apparently NFT related things. The only one in there I can maybe understand is esports.eth since $10k for an esports company to have a premium wallet address makes sense to speculate on given that market.
However, they have domain validated integration of existing (ICANN) domains now, so I don't see much value in the .eth stuff. There's some value in avoiding confusion. Saying "send money to esports.eth" is less ambiguous than "send money to esports.com" because the latter could be confused with normal eTransfers. Beyond that though, what makes a .eth domain worth $10k+?
1. https://www.namepros.com/threads/ens-ethereum-domain-service...
> artdao.eth bought for 59Ξ ($191711.65)
> tara.eth bought for 6Ξ ($21797.16)
> keira.eth bought for 15.0Ξ ($51192.90)
> protein.eth bought for 10.0Ξ ($32484.00)
> esports.eth bought for 2.76Ξ ($10699.55)
> fidenza.eth bought for 30.0Ξ ($107111.40)
> artblockscurated.eth bought for 7.0Ξ ($24992.66)
There are tons of similar sales apparently. Some of it just doesn't make sense. $200k for artdao.eth? Really? The last two are apparently NFT related things. The only one in there I can maybe understand is esports.eth since $10k for an esports company to have a premium wallet address makes sense to speculate on given that market.
However, they have domain validated integration of existing (ICANN) domains now, so I don't see much value in the .eth stuff. There's some value in avoiding confusion. Saying "send money to esports.eth" is less ambiguous than "send money to esports.com" because the latter could be confused with normal eTransfers. Beyond that though, what makes a .eth domain worth $10k+?
1. https://www.namepros.com/threads/ens-ethereum-domain-service...
yup, there was a lot of that on HNS and ENS
I use it, and own a small portfolio of names on chain. "base" and "faq" are a couple of them. It's been pretty interesting to watch the ecosystem mature.
Just recently a small dev team released a desktop app that syncs name data to your local device and lets you browse sites with lookups to the handshake root before falling back to icann root https://impervious.com/fingertip.html
Just recently a small dev team released a desktop app that syncs name data to your local device and lets you browse sites with lookups to the handshake root before falling back to icann root https://impervious.com/fingertip.html
So name squatting will still be a thing? Any solutions for that?
the way handshake addresses this problem is putting a cap on the total number of names that can be registered, and then users compete on fees in order to get their transaction mined to renew the name
Can't I make a few million accounts (or "wallets") programmatically, since it's a blockchain?
total number of names "total", not total number per wallet
So there is an ongoing cost to owning a name and the cost increases as the global number of names registered/owned increases?
yeah. right now it's ~$0 since there's no fee competition, but as soon as the total names registered gets close to the limit (66 million) then the cost of renewall will go up and it will be costly to squat. there are 1.85 million names registered currently.
I've looked at HNS and ENS a bit. I want a domain on both, but haven't bought any. The biggest problem is having to deal in crypto currency.
In Canada buying and selling crypto currency is similar to dealing with stocks. You need to track it like an asset and both sales and transfers create taxable events.
Imagine you want to buy a 2x4 at Home Depot. In the crypto equivalent world, you'd have to provide KYC / AML information to an exchange that supports Home Depot to get an account, buy Home Depot stock, use the stock to buy lumber, sell your excess stock, and claim any relevant losses / gains on your taxes. It's a hilariously bad user experience.
Then on the ENS side the fees are insane. To buy a "$5" .eth domain right now shows me .001 ETH (they try to keep it around $5 USD) for the domain plus .083 (~$285) ETH for gas fees for ~$290 total.
I went as far as signing up to an exchange to get a .eth domain and that exchange charges .008 ETH to transfer my money off the exchange which is another $30. So all in, right now it would cost me (up to) $320 USD to buy a "$5" .eth domain.
Paying $315 in fees to buy a $5 good doesn't seem like the free market efficiency the crypto crowd is selling. To me it feels like a bit of a grift where whoever's getting those fees is taking a ton of money out of the system.
Then if you jump over to the HNS side, the exchange I signed up with doesn't support HNS, so I would need to provide them (HNS) KYC levels of identity verification too and I'm not willing to do that because they're not listed in FINTRAC (Canada's AML regulator). I think Coinbase would be ok, but what a hassle!
In Canada buying and selling crypto currency is similar to dealing with stocks. You need to track it like an asset and both sales and transfers create taxable events.
Imagine you want to buy a 2x4 at Home Depot. In the crypto equivalent world, you'd have to provide KYC / AML information to an exchange that supports Home Depot to get an account, buy Home Depot stock, use the stock to buy lumber, sell your excess stock, and claim any relevant losses / gains on your taxes. It's a hilariously bad user experience.
Then on the ENS side the fees are insane. To buy a "$5" .eth domain right now shows me .001 ETH (they try to keep it around $5 USD) for the domain plus .083 (~$285) ETH for gas fees for ~$290 total.
I went as far as signing up to an exchange to get a .eth domain and that exchange charges .008 ETH to transfer my money off the exchange which is another $30. So all in, right now it would cost me (up to) $320 USD to buy a "$5" .eth domain.
Paying $315 in fees to buy a $5 good doesn't seem like the free market efficiency the crypto crowd is selling. To me it feels like a bit of a grift where whoever's getting those fees is taking a ton of money out of the system.
Then if you jump over to the HNS side, the exchange I signed up with doesn't support HNS, so I would need to provide them (HNS) KYC levels of identity verification too and I'm not willing to do that because they're not listed in FINTRAC (Canada's AML regulator). I think Coinbase would be ok, but what a hassle!
This is a fantastic solution, the only issue it's relatively unheard of.
[deleted]
[deleted]
This sounds like Tor but for DNS.
That was my take on it too. The first resolver knows who you are, so can return the DNS query response but not the actual query itself as it’s encrypted. The exit resolver (exit node if you will) knows the DNS query but not the original source of the request, since it came from the first resolver. So at this point it looks like the idea of onion routing applied to DNS queries. Sound about right?
Same problem as TOR; the servers can share information. DNS seems like a good service for homomorphic PIR.
so we will make our own DNS system with blackjack and hookers
Thus solving the problem once and for all!
but...
ONCEANDFORALL!
but...
ONCEANDFORALL!
[deleted]
I can't remember when it was first researched, but sometime after the birth of Tor, there was increased interest by DoD and others to track connections over an obscured network. The end result was a paper that showed you could identify the sources and destinations of traffic solely by monitoring aggregate traffic over major routes in the network. In essence, for completely encrypted tunnels, you could know exactly what user was using what Tor exit node, assuming you had enough network sensors spread out and enough sample data. There was also the possibility of discovering Tor hidden nodes and what users were using them.
Therefore, regardless of traffic (ex. DNS), if you have the motive to find out who is doing what on the internet, and the capital and access for the network sensors, you can find out who's going where (and even doing what to a certain extent).
The more traffic is encrypted, and the more we push for more privacy and more difficult we make it to monetize our network access, the more reason they have to increase their surveillance, so they can continue to fund all these products and technologies we take for granted.
The cause of an arms race isn't arms. It's the inability to come to terms on an issue. We should be addressing the issue, not ramping up our weapons research. I know this isn't a "sexy solution", but it would definitely free up our time to worry about more important or interesting things.