Metadata is the real data(standardnotes.org)
standardnotes.org
Metadata is the real data
https://standardnotes.org/blog/4/metadata-is-the-data
37 comments
"... but the operator of that resolver..."
The operator of the resolver cache is supposed to be the user, not some third party (e.g., OpenDNS/Cisco, etc.).
IOW, the cache is meant to be running on the user's computer not some third party computer (e.g., OpenDNS/Cisco, etc.).
Using remote (i.e. third party) recursive resolver caches has never been recommended. If anyone is recommending that then they are ignoring the advice of the original author.
(There are other reasons to use a local cache, even if not to encrypt outgoing queries, e.g., it reduces/eliminates the risk of cache poisoning.)
If you look, you may find there are implementations that did follow the author's advice, e.g., a resolver that only accepts queries from 127.x.x.x.
What is missing to have a complete encrypted DNS solution? Authoritative nameservers that implement the system.
The recursive part of the system already works. It is controlled locally by users.
Authoritative nameservers for www sites however are run by third parties. Cooperation is needed.
As for TLS, there may be an alternative encryption solution forthcoming. Similar to encrypted DNS, it will be a small program running on the user's computer that encrypts outgoing packets. An ssl wrapper sort of like stunnel but better. It will not rely on establishing an "encrypted tunnel" like TLS. It will encrypt each packet separately.
The operator of the resolver cache is supposed to be the user, not some third party (e.g., OpenDNS/Cisco, etc.).
IOW, the cache is meant to be running on the user's computer not some third party computer (e.g., OpenDNS/Cisco, etc.).
Using remote (i.e. third party) recursive resolver caches has never been recommended. If anyone is recommending that then they are ignoring the advice of the original author.
(There are other reasons to use a local cache, even if not to encrypt outgoing queries, e.g., it reduces/eliminates the risk of cache poisoning.)
If you look, you may find there are implementations that did follow the author's advice, e.g., a resolver that only accepts queries from 127.x.x.x.
What is missing to have a complete encrypted DNS solution? Authoritative nameservers that implement the system.
The recursive part of the system already works. It is controlled locally by users.
Authoritative nameservers for www sites however are run by third parties. Cooperation is needed.
As for TLS, there may be an alternative encryption solution forthcoming. Similar to encrypted DNS, it will be a small program running on the user's computer that encrypts outgoing packets. An ssl wrapper sort of like stunnel but better. It will not rely on establishing an "encrypted tunnel" like TLS. It will encrypt each packet separately.
And yet that's not how it works. Many systems are happy to use whatever resolver DHCP tells them to -- usually their ISP's or their router's. If it is close enough to the user, then all queries might as well go in the clear, and once again you're subject to metadata gathering that way.
I do not use DHCP. (Nor do I use ARP.) For a small home network I do not need it.
I run a private root and a private nameserver that serves encrypted DNS packets from a datacenter. "Pseudo authoritative": the zone contains the third party addresses I need. All DNS queries are encrypted. Sent from localhost resolver to private nameserver. Nothing in the clear. That is how it works.
There will always be metadata gathering on the internet (access logs). But there does not have to be unencrypted (DNS) packets or third party DNS resolvers.
I run a private root and a private nameserver that serves encrypted DNS packets from a datacenter. "Pseudo authoritative": the zone contains the third party addresses I need. All DNS queries are encrypted. Sent from localhost resolver to private nameserver. Nothing in the clear. That is how it works.
There will always be metadata gathering on the internet (access logs). But there does not have to be unencrypted (DNS) packets or third party DNS resolvers.
I don't know much about the technical side of this, but isn't this what onion routing is for?
Tor? And yet that doesn't seem to work very well. It seems U.S. agencies operate many Tor exit nodes, no? Also, if it can be fingerprinted at all (usually it can) then you stick out like a sore thumb when you use it.
Yes, metadata can't be encrypted. And it can't be eliminated.
But it can be obfuscated enough to be, in practice, virtually useless. A single VPN service provides no anonymity. Tor provides some anonymity, using onion routing. There are three relays in normal circuits. Each of them knows where data comes from, and where it's going to. But with at least three, the entry and exit relays don't know each other.
But there are vulnerabilities. The relay early bug allowed CMU researchers to communicate between their malicious entry and exit relays, and so de-anonymize users and onion services. That bug is fixed, but of course there may be others.
However, onion routing can also be applied to VPN services. I'm typing this through a nested chain of VPNs. And one can readily use Tor via nested VPN chains. So adversaries would need to compromise multiple servers in different jurisdictions, walking through Tor and VPNs, in order to identify me. Or they could exploit intercepts from network edges with traffic analysis. But it wouldn't be easy.
But it can be obfuscated enough to be, in practice, virtually useless. A single VPN service provides no anonymity. Tor provides some anonymity, using onion routing. There are three relays in normal circuits. Each of them knows where data comes from, and where it's going to. But with at least three, the entry and exit relays don't know each other.
But there are vulnerabilities. The relay early bug allowed CMU researchers to communicate between their malicious entry and exit relays, and so de-anonymize users and onion services. That bug is fixed, but of course there may be others.
However, onion routing can also be applied to VPN services. I'm typing this through a nested chain of VPNs. And one can readily use Tor via nested VPN chains. So adversaries would need to compromise multiple servers in different jurisdictions, walking through Tor and VPNs, in order to identify me. Or they could exploit intercepts from network edges with traffic analysis. But it wouldn't be easy.
What kind of speeds do you get with that setup?
Through three nested VPNs, about 10 Mbps each way, with 100-150 ms rtt. Plus Tor, about 1-3 Mbps each way, with 500 ms rtt or more.
You must have a really good internet connection. I pay close to $200 USD/mo for a wireless, 10Mbps max connection, and that's literally the best I can get unless I were to personally invest in running a fiber-optic line to my house.
Yes, I have a decent uplink. And I use fast VPN services.
With 10 Mbps, you should be able to get 3-5 Mbps through nested VPNs. I use UDP for all of them, so there's no retransmission chaos. As you add VPNs to the chain, bandwidth doesn't necessarily go down. But rtt increases, of course.
With 10 Mbps, you should be able to get 3-5 Mbps through nested VPNs. I use UDP for all of them, so there's no retransmission chaos. As you add VPNs to the chain, bandwidth doesn't necessarily go down. But rtt increases, of course.
My upstream commercial provider is not a US company, which makes a subpoena an international incident: a much higher bar. I also pay them for the service precisely because I want them to consider my best interest: they are likely to fight broad subpoenas. (they have admitted to giving data for a few subpoenas, but this is a small percent of their customers not everyone)
But now you live by their rules, which may or may not be as generous as the U.S. rules, and which you may not be familiar with. Worse, you may live under both rules since they may cooperate in ways you're not aware of.
> Today all DNS resolution goes in the clear.
Yes, but I suppose you could decrease the signal-to-noise ratio by doing random DNS searches.
Yes, but I suppose you could decrease the signal-to-noise ratio by doing random DNS searches.
Setting up unbound to use dnssec and tor is super-easy too.
And once you set up the router, the cost of configuration is zero.
And once you set up the router, the cost of configuration is zero.
Dnssec still has your data in the clear, it just signs the data. (And is not supported by most domains)
DNSSEC only gives you two things, and only when all zones on the path to the domains you're looking at are signed: authentication of the response data, and authenticated denial of existence (NXDOMAIN).
DNSSEC does NOT encrypt requests nor responses.
DNSSEC does NOT encrypt requests nor responses.
Probably not. First of all, you'd need a large list of domains to query for randomly. Second, you'd have to actually have traffic with them, because if all you do is look up their info, but you connect only to the ones you want to talk to, then it's clear which ones you're talking to.
The right to encrypt is the right to privacy.
Communications on the Internet are public by default; this is something that human civilization never experienced before. If you want to make your conversation or your behavior private, you have to encrypt it.
But there were many other things that human civilization never experienced before, and we adapted.
Right to encryption is, indeed, an essential natural right. People who deny it are the same people who think that everybody should have a government-supplied monitoring camera in every room of every home, and fail to understand what's wrong with it.
Communications on the Internet are public by default; this is something that human civilization never experienced before. If you want to make your conversation or your behavior private, you have to encrypt it.
But there were many other things that human civilization never experienced before, and we adapted.
Right to encryption is, indeed, an essential natural right. People who deny it are the same people who think that everybody should have a government-supplied monitoring camera in every room of every home, and fail to understand what's wrong with it.
>The right to encrypt is the right to privacy.
Is there no right to encrypt? Because no government can actually prevent you from encrypting anything and the maths behind cryptography are openly taught and researched in all modern states. So are you saying that governments should never have the right to compel you to decrypt what you encrypted (by, for example, a fine or a prison term)?
Is there no right to encrypt? Because no government can actually prevent you from encrypting anything and the maths behind cryptography are openly taught and researched in all modern states. So are you saying that governments should never have the right to compel you to decrypt what you encrypted (by, for example, a fine or a prison term)?
That's relatively recent, though. Until the 90s and PGP, encryption was very much under the government's control, and regular citizens definitely did not have a "right to encrypt". The Clipper Chip launched in 1993.
IMO the battle over privacy and crypto is well documented by Steven Levy: https://en.wikipedia.org/wiki/Crypto:_How_the_Code_Rebels_Be...
IMO the battle over privacy and crypto is well documented by Steven Levy: https://en.wikipedia.org/wiki/Crypto:_How_the_Code_Rebels_Be...
Wow the Clipper Chip is interesting reading, especially in light of the current battles over cellphone encryption. Thanks!
While encryption is of course just maths, governments have done a surprisingly effective job in the past controlling access to research and implementation. Granted this is significantly harder now with much wider proliferation of the internet. While this may not deter those with a technical interest much, it definitely does affect 'average users'.
As one concrete example, Netscape's SSL implementation was originally shipped in two versions - the 'secure' US version, and a severely compromised international download version, due to export controls on the encryption method used.
I'd also argue it's still not fully 'open' in the US - there's still a legal requirement to notify the government of any open source release of new cryptographic technologies, and some restrictions on distribution still exist. I also don't think it's a major stretch to imagine we are just one more San Bernadino style tragedy away from the first western government legislating to ban/compromise cellphone storage encryption, especially with the current US and UK political climates. One can only hope after San Bernadino that Apple has began preparing in earnest for that fight - I can't see any other big players having the moral conviction.
https://www.apache.org/dev/crypto.html
https://en.wikipedia.org/wiki/Crypto_Wars
https://en.wikipedia.org/wiki/Export_of_cryptography_from_th...
As one concrete example, Netscape's SSL implementation was originally shipped in two versions - the 'secure' US version, and a severely compromised international download version, due to export controls on the encryption method used.
I'd also argue it's still not fully 'open' in the US - there's still a legal requirement to notify the government of any open source release of new cryptographic technologies, and some restrictions on distribution still exist. I also don't think it's a major stretch to imagine we are just one more San Bernadino style tragedy away from the first western government legislating to ban/compromise cellphone storage encryption, especially with the current US and UK political climates. One can only hope after San Bernadino that Apple has began preparing in earnest for that fight - I can't see any other big players having the moral conviction.
https://www.apache.org/dev/crypto.html
https://en.wikipedia.org/wiki/Crypto_Wars
https://en.wikipedia.org/wiki/Export_of_cryptography_from_th...
> As one concrete example, Netscape's SSL implementation was originally shipped in two versions - the 'secure' US version, and a severely compromised international download version, due to export controls on the encryption method used.
No need to bring Netscape from the past, Oracle's Java 8 ships with crippled crypto and you need to download additional jar from their site after accepting that you are not exporting it to "bad" countries [0]. What's funny is that the jar contains only configuration and it's super easy to adjust it manually.
[0]: https://stackoverflow.com/questions/6481627/java-security-il...
No need to bring Netscape from the past, Oracle's Java 8 ships with crippled crypto and you need to download additional jar from their site after accepting that you are not exporting it to "bad" countries [0]. What's funny is that the jar contains only configuration and it's super easy to adjust it manually.
[0]: https://stackoverflow.com/questions/6481627/java-security-il...
The right to encrypt - unlike the current debate over a right to healthcare - is a negative right: All men are born able to encrypt (given the math), it can only be taken away.
Positive rights, like healthcare or Social Security, are a thing that you are not born with that is given to you. The government does not have to provide you with encryption software in order for you to encrypt.
That is to say, I think you are correct and that right does exist.
Positive rights, like healthcare or Social Security, are a thing that you are not born with that is given to you. The government does not have to provide you with encryption software in order for you to encrypt.
That is to say, I think you are correct and that right does exist.
With respect to healthcare isn't it more complicated? As regulations/laws can interfere with a negative right like the ability to self medicate?
In the same vein, there is no right to life, there's right of not being killed.
And despite centuries of civilisation, this is actually true, under the surface of civility and sophistication. Human beings understand what they ought NOT to do better than what they ought. We're wired that way.
Correct & important to grow awareness about! Sadly many so-called private email or other services claim just encrypting your content brings you privacy...while ignoring/failing to discuss the metadata.
Descriptive metadata - please, please stop misusing a term thats existed since the 1970's - https://www.youtube.com/watch?v=L0vOg18ncWE
Conflating the term "metadata" with "descriptive metadata" and "metadata retention" makes it harder for data archives to get people to provide "structural metadata" (aka. the real metadata), that effectively describes the schemas and data structures of academic and open government data.
Yes, descriptive metadata retention is a huge problem, but say that instead of abbreviating terms in a way that obfuscates the issue use the full term.
Conflating the term "metadata" with "descriptive metadata" and "metadata retention" makes it harder for data archives to get people to provide "structural metadata" (aka. the real metadata), that effectively describes the schemas and data structures of academic and open government data.
Yes, descriptive metadata retention is a huge problem, but say that instead of abbreviating terms in a way that obfuscates the issue use the full term.
Anyone using Standard Notes? Might give it a shot if it comes recommended.
I've been using the free version for the past several weeks and have been enjoying it. I am an avid Keep user, and StandardNotes has all but replaced that.
I find it refreshing writing in markdown for minimal formatting, and the interface gets out of your way to let you write.
I'd give it a try if you're wondering!
I find it refreshing writing in markdown for minimal formatting, and the interface gets out of your way to let you write.
I'd give it a try if you're wondering!
Does it support Markdown? I wrote a list with asterisks and it didn't get "rich" formatting.
Markdown is supported through editor extensions: https://standardnotes.org/extensions
Not using standard notes but I love the idea behind it. I personally use a selfhosted meemo for my notes (https://meemo.minimal-space.de).
Concerning encryption, privacy, and the U.S. Constitution:
Confidentiality - First, Fourth, and Fifth Amendments
Integrity - First and Fourth Amendments
Availability - First and Fourth Amendments
Confidentiality - First, Fourth, and Fifth Amendments
Integrity - First and Fourth Amendments
Availability - First and Fourth Amendments
Are there any companies that sell something like privacy as a service? It seems sorely needed that someone work on this
Suppose you encrypt all your SMTP/SUBMIT traffic. If your upstream is a commercial provider, then they will be subject to subpoenas. If you run your own upstream, then watching who it connects to will often be sufficient to gather metadata of interest.
Consider TLS. Before you can use it you must have used DNS. Today all DNS resolution goes in the clear. So game over right there. Eventually your client's DNS communication with a shared recursive resolver will not be in the clear, but the operator of that resolver will be subject to subpoenas, so game still over. Let's say we did deploy DJB's encrypted DNS solution. Well, you can still see which domains people are talking to, roughly, at least as long as they don't share nameservers, and if they do... You can see where this is going. Now let's say you did get DNS resolution securely anyways, well, now you have to connect to some IP address, and if it's not hosting many services, then game over, and if it is hosting many services, then SNI will be game over anyways (TLS 1.3 requires SNI). SNI cannot be encrypted.
The problem really is that metadata can't really be encrypted.
Mind you, criminals are defeated by data encryption -- mostly anyways.
And forcing governments to use subpoenas does mean increasing the cost of metadata gathering. Plus there won't be infinite retention requirements, perhaps. So, encryption does help somewhat, which means we must do it -- it's just not a complete solution.