5 ms·

I see a lot of confusion here, probably Cloudflare should have included an explanation of how ECH works in TFA instead of referring to their other article[1].

I see a lot of confusion here, probably Cloudflare should have included an explanation of how ECH works in TFA instead of referring to their other article[1]. The difference between ECH and SNI is that while SNI includes the hostname in the ClientHello (the first TLS record indicating connection initiation), ECH includes an encrypted section in the ClientHello called ClientHelloInner, and the hostname is moved inside it. The ClientHelloInner is encrypted using a public key made available over DNS, which is queried over DNS over HTTPS providers such as Google or Cloudflare DNS; plaintext DNS is avoided in order to prevent a MITM on the ClientHelloInner key. Doing so prevents ISPs and governments from analyzing your traffic. However, a CDN operator such as Cloudflare terminates TLS for your website, and thus traffic would be visible to them either way. Now, to the non-technical part of it: while ECH provides a significant privacy improvement, I personally am against its implementation. Most ISPs enforce country-specific orders to block domains using a combination of DNS packet interception and SNI inspection. The legitimacy or sanity of such laws are a separate matter - countries would want to block websites that violate their laws. If we take away this last resort from governments, they would react by enforcing client side blocklisting and DRMization as suggested in France[2], or force root certificate installation using legislation[3], or blocking large swathes of the internet as is the case with China. [1] https://blog.cloudflare.com/encrypted-client-hello/ https://blog.cloudflare.com/encrypted-client-hello/ [2] https://www.article19.org/resources/france-proposed-internet-bill-threatens-online-speech/ https://www.article19.org/resources/france-proposed-internet... [3] https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_attack https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...

josephcsible 3y ago
> while ECH provides a significant privacy improvement, I personally am against its implementation. Most ISPs enforce country-specific orders to block domains using a combination of DNS packet interception and SNI inspection. The legitimacy or sanity of such laws are a separate matter - countries would want to block websites that violate their laws. That's exactly why I'm in favor of it: it makes effective censorship impossible. > If we take away this last resort from governments, they would react by enforcing client side blocklisting and DRMization as suggested in France[2], or force root certificate installation using legislation[3] Note that those plans both thankfully failed. > or blocking large swathes of the internet as is the case with China. No free country would tolerate that.
- ocdtrekkie 3y ago
  We will almost certainly block ECH at my work, as we already block DoH. I expect any sane network to do the same. The natural alternative if blocking these protocols becomes unsustainable will absolutely be to require full decryption at our security edge. And that will provide drastically more information to us than we have now and will absolutely feel invasive. The idea of uninspectable client traffic is somewhat unhinged, and is already heavily used by malicious actors.
  - josephcsible 3y ago
    > I expect any sane network to do the same. Why? Sane networks shouldn't block anything. Even super dangerous stuff like ports 135-139 and 445 are a morally gray area. > The idea of uninspectable client traffic is somewhat unhinged, and is already heavily used by malicious actors. How is privacy unhinged? Isn't that basically the same as the argument that we need to gut the Fourth Amendment because of terrorists and pedophiles?
    - 4death4 3y ago
      I don’t think morals factor in to the decision to allow / disallow traffic on a private network. That’s definitely morally neutral and to suggest otherwise is immoral.
      - josephcsible 3y ago
        I didn't mean private networks. I meant the ISPs that do that.
        ocdtrekkie 3y ago
        ISPs are also private networks, unless operated by a government entity. And I would absolutely uphold the same expectation from an ISP as an organizational or personal network.
silverwind 3y ago
Why is DNS required to encrypt a TLS handshake? Why are there two SNIs in a ClientHello? ECH seems like a overengineered implementation when they could just have released TLS 1.4 which encrypts that section of the handshake.
- stefan_ 3y ago
  How do you "just encrypt it"? Encryption in TLS starts after you have verified who you are talking to via the certificate, otherwise you might just be doing encryption with whoever happens to MITM you. However to do the verification, the server must know what domain you are actually trying to reach - hence the SNI. This is why there is the DNS side channel.
- andrewaylett 3y ago
  Bootstrapping the encryption is a problem: until you've run the handshake, you don't have a key with which you could encrypt the handshake. And you don't want the key to live for too long, so folk are going to end up trying to use expired keys. Between the article and the linked introduction, all of what you are looking for is explained.
- tialaramex 3y ago
  Other people already explained that there's a bootstrap problem which prohibits "just encrypt that section of the handshake". But the two SNIs are because of GREASE particularly. They might be avoided if you didn't want to enable GREASE, but we definitely want GREASE. The idea of GREASE is, whenever we might want to do something that's visible to third parties, we must sometimes do it anyway, at least as much as they can tell, so as to ensure they tolerate this when it happens so that when we did want it we can do it successfully. For example GREASE extensions are just nonsense extensions you propose in a TLS connection today. Chrome does this. "Hey server, can you do BINGLE BONGLE?" and of course your server doesn't do BINGLE BONGLE because that's nonsense, but to a "Security device" which is "Inspecting TLS connections as part of our Next Generation Firewall Technology" it seems like maybe we want to do BINGLE BONGLE. How should it react? Well, it should do nothing because the specification is clear that if you don't understand what is said you should ignore it, but without GREASE we know in SSL, and TLS 1.0, TLS 1.1 and TLS 1.1 these devices would freak out for each new extension. 1.6GB of customer personal information in a CSV file POSTed to a competitor's Dropbox? Fine. Your web browser wanted to use NEW FEATURE? Alert! Attack detected - lock down the network, summon armed guards! So hence the invention of GREASE. For ECH GREASE works by just always pretending we're doing ECH. If we want to talk to old-web-site.example we send an outer SNI of old-web-site.example and it doesn't matter what our inner SNI is, it can be random nonsense encrypted to nobody, because old-web-site don't use ECH anyway. If we want to talk to ech-enabled-site.example our browser discovers oh, here's a key for ECH for ech-enabled-site.example and it says we should ask to talk to boring.example, so the browser encrypts the inner SNI of ech-enabled-site.example with the key, and provides an outer SNI of boring.example. In both cases this looks the same to snoops, there's an outer SNI they can read and an inner SNI they can't read. Which is genuine? No way for them to know. But the server knows easily.
1vuio0pswjnm7 3y ago
"I see a lot of confusion here, probably Clouflare should have included an explanation of how ECH works in TFA instead of referring to their other article[1]." Even better would be to explain why SNI exists. This in turn explains why CDNs like Cloudflare are interested in it. SNI allows CDNs to operate as intermediaries on a www where HTTPS is increasinglty mandatory for every website. With respect to the "privacy" of TLS it is peculiar to put ISPs and governments in one category and CDNs in another. If ISPs (without ECH) or CDNs (with or without ECH) are getting a list of every domain the user visits, then governments can get the same list by requesting it from the ISP or CDN. The question, IMHO, is whether there are other possible technical solutions besides TLS SNI to allow multiple HTTPS sites to be hosted on the same IP. Is it possible to obviate the need to use a third party such as a CDN to solve this problem. Is it possible to obviate the need for duct tape solutions like ECH. ECH is proposed as a solution for the "plaintext domain names over the wire" problem. But that problem only exists because it's created by the use of SNI. And SNI exists to enable one to host multiple HTTPS sites on the same IP. Today, CDNs are the primary benefactors of SNI. They host 10s or 100s of 1000s of HTTPS sites on a limited number of IPs. These are the primary users and benefactors of SNI. For example, consider this prototype, which some believe inspired the advertising company-sposonsored "QUIC": https://curvecp.org/addressing.html https://curvecp.org/addressing.html "An ISP or site administrator can easily run a huge number of CurveCP servers on a single global IPv4 address, even if the servers are independently operated with separate long-term public keys. This feature is provided by a simple extension mechanism in CurveCP addresses. CurveCP servers are inherently anti-aliased, providing automatic virtual hosting and fixing some of the deficiencies in the "same-origin" policy in web browsers. This feature is provided by a simple domain-name mechanism in CurveCP addresses. If a site has two server addresses, and one server is down, a CurveCP client will quickly connect to the other address. A CurveCP connection remains fully functional even if the client changes IP address. CurveCP is fully compatible with existing NAT (network address translation) mechanisms; none of the above features require clients or servers to know the global addresses of their gateways."
xg15 3y ago
> Now, to the non-technical part of it: while ECH provides a significant privacy improvement, I personally am against its implementation. Most ISPs enforce country-specific orders to block domains using a combination of DNS packet interception and SNI inspection. The legitimacy or sanity of such laws are a separate matter - countries would want to block websites that violate their laws. You don't even have to start with governments. ECH can just as well be used by trackers/ads/app telemetry etc to stop you from blocking them via Pihole.
- dharmab 3y ago
  If you control the client you can block trackers there, such as Brave and Orion do natively.
- 4death4 3y ago
  Your pihole could MITM the traffic. It doesn’t need unencrypted SNI to work.
- josephcsible 3y ago
  No it can't. If it's in a browser, then extensions can still block it, and if it's in an app, then they could make it unblockable without needing DoH or ECH just by putting the trackers/ads/app telemetry on the same domain as the rest of what the app uses.
ceilingcat0 3y ago
They're going to resort to blocking IPs and not caring about collateral damage and force CDNs and anyone running multi tenant to turn the specific site targeted off or move them onto a separate pool of IPs that is easily blockable.
- josephcsible 3y ago
  The hope is that the CDNs explicitly refuse to do that, so that the collateral damage leads to pressure that forces the censor to relent.
  - jiggawatts 3y ago
    Narrator: they didn't relent. Do you think for a second anyone in power in China, Russia, or North Korea care if some random 20-year-old kid can access English-language sites or not?
    - shaky-carrousel 3y ago
      Then we'll massively switch to VPNs, like Russians do.
    - josephcsible 3y ago
      I know North Korea is happy to cut off the entire rest of the world, but even China and Russia are not.
      - justsomehnguy 3y ago
        For China your 'entire rest of the world' ie US + Europe is less than China population.
costco 3y ago
> If we take away this last resort from governments, they would react by enforcing client side blocklisting and DRMization as suggested in France[2], or force root certificate installation using legislation[3], or blocking large swathes of the internet as is the case with China. Not every government has the leverage, capability or power to do this. Client side blacklisting will be trivially circumvented if it actually goes into effect. The browser vendors all rejected the proposed Kazakh root certificate. And plenty of countries with pervasive Internet censorship don't have enough of a "domestic internet" to block large numbers of websites without a lot of people getting upset.
ignoramous 3y ago
> plaintext DNS is avoided in order to prevent a MITM on the ClientHelloInner key. Is MiTM possible unless the attacker is in possession of a sufficiently advanced quantum computer? What's published as HTTPS/SVCB record is the public part of the key. Afaik, DNSSEC isn't even a requirement for zones publishing HTTPS/SVCB ECH records? > Doing so prevents ISPs and governments from analyzing your traffic. Don't think traffic analysis is thwarted. ECH plugs inspection of the only plaintext bits in TLS, which is not only abused by censors, but also by various 'well-meaning' middleware that made bringing upgrades to TLSv1.3 a nightmare. > If we take away this last resort from governments... You mention GFW, and we got GFW without ECH. Governments will government, nothing will stop them. That shouldn't stop us from shoring up our side of the equation. Because by that logic, Meta shouldn't e2ee WhatsApp or Browsers shouldn't OCSP / CRL. In fact, not having those sound scary to me; because governments aren't the only power hungry actor around. It wasn't long ago Meta was caught spying on the users of its data saver VPN (Onavo) for half a decade, if not more.
- Obscurity4340 3y ago
  Can someone chime in with how quantum computers effectively at least double the output of traditional "classical" computers? I legitimately don't understand why its not easier and in some bottom-line sense cheaper just to like double up your (classical) computing power. What is it about QC that's so damn sepcial when you could theoretically achieve the same maximal idealized output with a simple increase in classical inputs? It seems with QC, there's this collective magical thinking that they offer this magical free lunch that is inaccessable via more traditional means. I don't get what the seemingly non-existent tradeoffs or optimizations that are being made to achieve this...
  - infinityio 3y ago
    I'm speaking in very abstract terms as a non-expert, but the critical distinction in this case is that prime factorisation (the basic underpinnings of RSA / similar encryption) is known to be an NP problem (more precisely - sub-exponential) for a classical computer but is polynomial for a quantum computer To achieve the same computing power on a classical computer, it would need to be exponentially more powerful - this is because (abstracting heavily) the quantum computer can test all possible inputs to a function at once, where a classical computer must test them one at a time
tialaramex 3y ago
> If we take away this last resort from governments, they would [...] Appeasement doesn't work. Maybe it's easier to remember that if you're British and so you had to watch Chamberlain's "Peace for our time" news reel in history class. The British Prime Minister, Neville Chamberlain, negotiated a deal with rising star German Chancellor Adolf Hitler, you've heard of him. Hitler agreed that Germany wouldn't start a massive European war in exchange for the British turning a blind eye to smaller wars he'd already started. You may never have heard of Chamberlain, because it turns out that piece of paper with Hitler's signature on it was worth precisely what you'd expect, and we needed an actual War Prime Minister soon enough. Now, the argument for appeasement is that sure, it doesn't actually work but it buys time. This is wrong because your opponents have the same extra time and they know precisely what they're doing whereas you're expending resources pretending (even if you correctly believe the appeasement won't work) that appeasement works.
intelVISA 3y ago
> Doing so prevents ISPs and governments from analyzing your traffic. However, a CDN operator such as Cloudflare terminates TLS for your website, and thus traffic would be visible to them either way. Cloudflare adopts the similar predatory Google posture of "we really really care about your privacy - nobody else should spy on you but us". Creepy!!
- vinay_ys 3y ago
  Well, not exactly. They are making privacy improvements in open standard protocols that you are free to use without using their service.
- deleted 3y ago
  [deleted]
tgsovlerkhgsel 3y ago
I disagree vehemently about this: > If we take away this last resort from governments, they would react by enforcing client side blocklisting and DRMization as suggested in France[2], or force root certificate installation using legislation[3], or blocking large swathes of the internet as is the case with China. You left out the fourth option, which is give up on their censorship aspirations. For most countries, censorship isn't important, and making it too hard will simply make it not worth it. China is of course different. Most countries made entirely ineffective laws and didn't bother following up.

josephcsible 3y ago

> while ECH provides a significant privacy improvement, I personally am against its implementation. Most ISPs enforce country-specific orders to block domains using a combination of DNS packet interception and SNI inspection. The legitimacy or sanity of such laws are a separate matter - countries would want to block websites that violate their laws. That's exactly why I'm in favor of it: it makes effective censorship impossible. > If we take away this last resort from governments, they would react by enforcing client side blocklisting and DRMization as suggested in France[2], or force root certificate installation using legislation[3] Note that those plans both thankfully failed. > or blocking large swathes of the internet as is the case with China. No free country would tolerate that.

ocdtrekkie 3y ago
We will almost certainly block ECH at my work, as we already block DoH. I expect any sane network to do the same. The natural alternative if blocking these protocols becomes unsustainable will absolutely be to require full decryption at our security edge. And that will provide drastically more information to us than we have now and will absolutely feel invasive. The idea of uninspectable client traffic is somewhat unhinged, and is already heavily used by malicious actors.
- josephcsible 3y ago
  > I expect any sane network to do the same. Why? Sane networks shouldn't block anything. Even super dangerous stuff like ports 135-139 and 445 are a morally gray area. > The idea of uninspectable client traffic is somewhat unhinged, and is already heavily used by malicious actors. How is privacy unhinged? Isn't that basically the same as the argument that we need to gut the Fourth Amendment because of terrorists and pedophiles?
  - 4death4 3y ago
    I don’t think morals factor in to the decision to allow / disallow traffic on a private network. That’s definitely morally neutral and to suggest otherwise is immoral.
    - josephcsible 3y ago
      I didn't mean private networks. I meant the ISPs that do that.
      - ocdtrekkie 3y ago
        ISPs are also private networks, unless operated by a government entity. And I would absolutely uphold the same expectation from an ISP as an organizational or personal network.

silverwind 3y ago

Why is DNS required to encrypt a TLS handshake? Why are there two SNIs in a ClientHello? ECH seems like a overengineered implementation when they could just have released TLS 1.4 which encrypts that section of the handshake.

stefan_ 3y ago
How do you "just encrypt it"? Encryption in TLS starts after you have verified who you are talking to via the certificate, otherwise you might just be doing encryption with whoever happens to MITM you. However to do the verification, the server must know what domain you are actually trying to reach - hence the SNI. This is why there is the DNS side channel.
andrewaylett 3y ago
Bootstrapping the encryption is a problem: until you've run the handshake, you don't have a key with which you could encrypt the handshake. And you don't want the key to live for too long, so folk are going to end up trying to use expired keys. Between the article and the linked introduction, all of what you are looking for is explained.
tialaramex 3y ago
Other people already explained that there's a bootstrap problem which prohibits "just encrypt that section of the handshake". But the two SNIs are because of GREASE particularly. They might be avoided if you didn't want to enable GREASE, but we definitely want GREASE. The idea of GREASE is, whenever we might want to do something that's visible to third parties, we must sometimes do it anyway, at least as much as they can tell, so as to ensure they tolerate this when it happens so that when we did want it we can do it successfully. For example GREASE extensions are just nonsense extensions you propose in a TLS connection today. Chrome does this. "Hey server, can you do BINGLE BONGLE?" and of course your server doesn't do BINGLE BONGLE because that's nonsense, but to a "Security device" which is "Inspecting TLS connections as part of our Next Generation Firewall Technology" it seems like maybe we want to do BINGLE BONGLE. How should it react? Well, it should do nothing because the specification is clear that if you don't understand what is said you should ignore it, but without GREASE we know in SSL, and TLS 1.0, TLS 1.1 and TLS 1.1 these devices would freak out for each new extension. 1.6GB of customer personal information in a CSV file POSTed to a competitor's Dropbox? Fine. Your web browser wanted to use NEW FEATURE? Alert! Attack detected - lock down the network, summon armed guards! So hence the invention of GREASE. For ECH GREASE works by just always pretending we're doing ECH. If we want to talk to old-web-site.example we send an outer SNI of old-web-site.example and it doesn't matter what our inner SNI is, it can be random nonsense encrypted to nobody, because old-web-site don't use ECH anyway. If we want to talk to ech-enabled-site.example our browser discovers oh, here's a key for ECH for ech-enabled-site.example and it says we should ask to talk to boring.example, so the browser encrypts the inner SNI of ech-enabled-site.example with the key, and provides an outer SNI of boring.example. In both cases this looks the same to snoops, there's an outer SNI they can read and an inner SNI they can't read. Which is genuine? No way for them to know. But the server knows easily.

1vuio0pswjnm7 3y ago

"I see a lot of confusion here, probably Clouflare should have included an explanation of how ECH works in TFA instead of referring to their other article[1]." Even better would be to explain why SNI exists. This in turn explains why CDNs like Cloudflare are interested in it. SNI allows CDNs to operate as intermediaries on a www where HTTPS is increasinglty mandatory for every website. With respect to the "privacy" of TLS it is peculiar to put ISPs and governments in one category and CDNs in another. If ISPs (without ECH) or CDNs (with or without ECH) are getting a list of every domain the user visits, then governments can get the same list by requesting it from the ISP or CDN. The question, IMHO, is whether there are other possible technical solutions besides TLS SNI to allow multiple HTTPS sites to be hosted on the same IP. Is it possible to obviate the need to use a third party such as a CDN to solve this problem. Is it possible to obviate the need for duct tape solutions like ECH. ECH is proposed as a solution for the "plaintext domain names over the wire" problem. But that problem only exists because it's created by the use of SNI. And SNI exists to enable one to host multiple HTTPS sites on the same IP. Today, CDNs are the primary benefactors of SNI. They host 10s or 100s of 1000s of HTTPS sites on a limited number of IPs. These are the primary users and benefactors of SNI. For example, consider this prototype, which some believe inspired the advertising company-sposonsored "QUIC": https://curvecp.org/addressing.html https://curvecp.org/addressing.html "An ISP or site administrator can easily run a huge number of CurveCP servers on a single global IPv4 address, even if the servers are independently operated with separate long-term public keys. This feature is provided by a simple extension mechanism in CurveCP addresses. CurveCP servers are inherently anti-aliased, providing automatic virtual hosting and fixing some of the deficiencies in the "same-origin" policy in web browsers. This feature is provided by a simple domain-name mechanism in CurveCP addresses. If a site has two server addresses, and one server is down, a CurveCP client will quickly connect to the other address. A CurveCP connection remains fully functional even if the client changes IP address. CurveCP is fully compatible with existing NAT (network address translation) mechanisms; none of the above features require clients or servers to know the global addresses of their gateways."

xg15 3y ago

> Now, to the non-technical part of it: while ECH provides a significant privacy improvement, I personally am against its implementation. Most ISPs enforce country-specific orders to block domains using a combination of DNS packet interception and SNI inspection. The legitimacy or sanity of such laws are a separate matter - countries would want to block websites that violate their laws. You don't even have to start with governments. ECH can just as well be used by trackers/ads/app telemetry etc to stop you from blocking them via Pihole.

dharmab 3y ago
If you control the client you can block trackers there, such as Brave and Orion do natively.
4death4 3y ago
Your pihole could MITM the traffic. It doesn’t need unencrypted SNI to work.
josephcsible 3y ago
No it can't. If it's in a browser, then extensions can still block it, and if it's in an app, then they could make it unblockable without needing DoH or ECH just by putting the trackers/ads/app telemetry on the same domain as the rest of what the app uses.

ceilingcat0 3y ago

They're going to resort to blocking IPs and not caring about collateral damage and force CDNs and anyone running multi tenant to turn the specific site targeted off or move them onto a separate pool of IPs that is easily blockable.

josephcsible 3y ago
The hope is that the CDNs explicitly refuse to do that, so that the collateral damage leads to pressure that forces the censor to relent.
- jiggawatts 3y ago
  Narrator: they didn't relent. Do you think for a second anyone in power in China, Russia, or North Korea care if some random 20-year-old kid can access English-language sites or not?
  - shaky-carrousel 3y ago
    Then we'll massively switch to VPNs, like Russians do.
  - josephcsible 3y ago
    I know North Korea is happy to cut off the entire rest of the world, but even China and Russia are not.
    - justsomehnguy 3y ago
      For China your 'entire rest of the world' ie US + Europe is less than China population.

costco 3y ago

> If we take away this last resort from governments, they would react by enforcing client side blocklisting and DRMization as suggested in France[2], or force root certificate installation using legislation[3], or blocking large swathes of the internet as is the case with China. Not every government has the leverage, capability or power to do this. Client side blacklisting will be trivially circumvented if it actually goes into effect. The browser vendors all rejected the proposed Kazakh root certificate. And plenty of countries with pervasive Internet censorship don't have enough of a "domestic internet" to block large numbers of websites without a lot of people getting upset.

ignoramous 3y ago

> plaintext DNS is avoided in order to prevent a MITM on the ClientHelloInner key. Is MiTM possible unless the attacker is in possession of a sufficiently advanced quantum computer? What's published as HTTPS/SVCB record is the public part of the key. Afaik, DNSSEC isn't even a requirement for zones publishing HTTPS/SVCB ECH records? > Doing so prevents ISPs and governments from analyzing your traffic. Don't think traffic analysis is thwarted. ECH plugs inspection of the only plaintext bits in TLS, which is not only abused by censors, but also by various 'well-meaning' middleware that made bringing upgrades to TLSv1.3 a nightmare. > If we take away this last resort from governments... You mention GFW, and we got GFW without ECH. Governments will government, nothing will stop them. That shouldn't stop us from shoring up our side of the equation. Because by that logic, Meta shouldn't e2ee WhatsApp or Browsers shouldn't OCSP / CRL. In fact, not having those sound scary to me; because governments aren't the only power hungry actor around. It wasn't long ago Meta was caught spying on the users of its data saver VPN (Onavo) for half a decade, if not more.

Obscurity4340 3y ago
Can someone chime in with how quantum computers effectively at least double the output of traditional "classical" computers? I legitimately don't understand why its not easier and in some bottom-line sense cheaper just to like double up your (classical) computing power. What is it about QC that's so damn sepcial when you could theoretically achieve the same maximal idealized output with a simple increase in classical inputs? It seems with QC, there's this collective magical thinking that they offer this magical free lunch that is inaccessable via more traditional means. I don't get what the seemingly non-existent tradeoffs or optimizations that are being made to achieve this...
- infinityio 3y ago
  I'm speaking in very abstract terms as a non-expert, but the critical distinction in this case is that prime factorisation (the basic underpinnings of RSA / similar encryption) is known to be an NP problem (more precisely - sub-exponential) for a classical computer but is polynomial for a quantum computer To achieve the same computing power on a classical computer, it would need to be exponentially more powerful - this is because (abstracting heavily) the quantum computer can test all possible inputs to a function at once, where a classical computer must test them one at a time

tialaramex 3y ago

> If we take away this last resort from governments, they would [...] Appeasement doesn't work. Maybe it's easier to remember that if you're British and so you had to watch Chamberlain's "Peace for our time" news reel in history class. The British Prime Minister, Neville Chamberlain, negotiated a deal with rising star German Chancellor Adolf Hitler, you've heard of him. Hitler agreed that Germany wouldn't start a massive European war in exchange for the British turning a blind eye to smaller wars he'd already started. You may never have heard of Chamberlain, because it turns out that piece of paper with Hitler's signature on it was worth precisely what you'd expect, and we needed an actual War Prime Minister soon enough. Now, the argument for appeasement is that sure, it doesn't actually work but it buys time. This is wrong because your opponents have the same extra time and they know precisely what they're doing whereas you're expending resources pretending (even if you correctly believe the appeasement won't work) that appeasement works.

intelVISA 3y ago

> Doing so prevents ISPs and governments from analyzing your traffic. However, a CDN operator such as Cloudflare terminates TLS for your website, and thus traffic would be visible to them either way. Cloudflare adopts the similar predatory Google posture of "we really really care about your privacy - nobody else should spy on you but us". Creepy!!

vinay_ys 3y ago
Well, not exactly. They are making privacy improvements in open standard protocols that you are free to use without using their service.
deleted 3y ago
[deleted]

tgsovlerkhgsel 3y ago

I disagree vehemently about this: > If we take away this last resort from governments, they would react by enforcing client side blocklisting and DRMization as suggested in France[2], or force root certificate installation using legislation[3], or blocking large swathes of the internet as is the case with China. You left out the fourth option, which is give up on their censorship aspirations. For most countries, censorship isn't important, and making it too hard will simply make it not worth it. China is of course different. Most countries made entirely ineffective laws and didn't bother following up.