5 ms·

Arguably, no one except a Cloudflare employee could know the reason why they took this decision. A random person speculating “maybe they did this for privacy re

Arguably, no one except a Cloudflare employee could know the reason why they took this decision. A random person speculating “maybe they did this for privacy reasons” doesn’t strike me as better than Cloudflare saying “we did this for privacy reasons”. And while the second answer is a statement, not an analysis the rest of what I said holds. You will only accept their statement as the truth if you assume good intent of them.

113 7y ago
Corporations operate for profit.
- tedk-42 7y ago
  Indeed - but there are other ways to make money than to sell of your personal information to the highest advertising bidder.
  - jgrahamc 7y ago
    Such as, in Cloudflare's case, selling our service (the DDoS protection, the caching, the firewalling etc.) to companies that pay for that service because it helps them. While at the same time working to preserve people's privacy with things like giving out SSL for free, pushing for eSNI, running a public DoH server, building a service that makes sure all data from your phone to us is encrypted etc. etc.
    - denton-scratch 7y ago
      "like giving out SSL for free" The market rate for standard SSL certs is zero.
      - jgrahamc 7y ago
        It wasn't in 2014 (https://blog.cloudflare.com/introducing-universal-ssl/ https://blog.cloudflare.com/introducing-universal-ssl/) when we launched it.
    - cnst 7y ago
      It's been shown that Cloudflare's DoH service is a lot ado about nothing, and is actually worse for privacy, not better: * https://news.ycombinator.com/item?id=21071022 https://news.ycombinator.com/item?id=21071022 Likewise for 1.1.1.1 — when taking into consideration the local caching appliances that the ISPs have invested in, the lack of ECS would make the clients go all the way through the internet for the same content that's already cached locally by the ISP for users of all other decent resolvers — this will only contribute to increased costs for the individual ISPs, extra latency for users, and more competitive advantage of your products due to you diminishing the technological advantages of your competitors, without regard to the actual user experience of the users, or the reliability and scaling of the internet infrastructure at large. Not to mention that such Netflix/YouTube usage, when going directly through transit providers and through the whole internet, would also subject the users to a greater chance of surveillance at large compared to users of resolvers that would access local copies on the caching appliance.
      - pixl97 7y ago
        Except in the US the ISPs are some of the biggest surveillance organizations themselves. They are also highly monopolized so most people in the US are on one of a very small number of ISPs
        zrm 7y ago
        Which is a good argument for not using your ISP's DNS either, but those are not the only two options. One of the better alternatives is to get a VPN you trust that puts multiple users behind the same IP address and then operate your own recursive DNS from behind there. The VPN service itself could still log your queries, but at least they have plenty of competitors, and you chose one you trust, right? Or if you don't want to trust any one party, use Tor.
      - andreareina 7y ago
        It has been argued, I wouldn't say that it has been shown. Both my ISPs operate a DNS blacklist. So did my previous ISPs, in the country I previously lived in. And in a third country, where I was on holiday. ISPs even in the USA are gnashing their teeth at the prospect of losing visibility into DNS. Why would they care if they weren't using that data? Why do they need a subscriber -> [domain] mapping? Routing tables don't care about domain names. Edge caching of web content doesn't work with https. I might care about DNS caching if the ISPs haven't demonstrated time and again that they will abuse my privacy for a buck, after I've already paid them for the privilege. I trust Cloudflare much more than I trust any ISP I've had to deal with, including American ISPs when I lived there. I trust Google much more than any ISP, and I'm not particularly charitable towards Google. Centralized DoH isn't perfect, but it's better than the status quo. The SNI hole is shrinking. My threat model does not include defending against the Mossad doing Mossad things with my email^H^H^H^H^HDNS[1]. [1] https://www.usenix.org/system/files/1401_08-12_mickens.pdf https://www.usenix.org/system/files/1401_08-12_mickens.pdf
    - tomp 7y ago
      If you're trying to preserve people's privacy, why doesn't the 1.1.1.1 VPN service also mask originating IP?
      - jgrahamc 7y ago
        Warp isn't trying to "hide your IP from the sites you are visiting". It's there to help prevent intermediaries from observing your traffic. A huge percentage of the web is still unencrypted HTTP. And Warp+ aims to be about that plus performance. If you want to be totally anonymous on the Internet then I recommend you use Tor. If you just use a VPN then you may hide your IP address from sites you visit but there are tons of other fingerprinting techniques that can be used.
        tomp 7y ago
        I understand all that, and you didn't answer my question. Why do you push the narrative that 1.1.1.1 DNS resolver protects user privacy (by hiding originating IP / subnet) whereas 1.1.1.1 VPN gladly reveals that data? In both cases, the destination is hidden to any eavesdroppers, but in the latter case (VPN) the source IP is visible to the destination website, whereas you keep insisting how vital it is to hide source IP in the former case (DNS).
        jgrahamc 7y ago
        In the case of Warp, we add the connecting IP information as a header to the HTTP request for sites on Cloudflare. This will typically be inside TLS to the origin server, and so the source IP information will be encrypted and only visible to the web site being visited. In the case of DNS information about the subnet, the query etc. is sent around unencrypted. One is open to eavesdropping, the other is not.
        zzzcpan 7y ago
        Someone capable of eavesdropping on that query sure as hell capable of eavesdropping on incoming connections to 1.1.1.1 where they can see actual IP address that initiated the query. There is no way to justify this as a privacy feature. Well, unless people don't understand enough to believe you.
- nindalf 7y ago
  And so you accept the first answer. That’s fine. Cloudflare has repeatedly said that while they operate for profit, they take the long term view. By doing the right thing now, by being privacy focussed, they will be profitable for decades to come. This seems logical to me, which makes the second answer more believable.
  - nathanpotter 7y ago
    Do you remember "do no evil"? Pepperidge Farms remembers.
yc12340 7y ago
Nah, I will assume it as truth only when it makes sense.
- nindalf 7y ago
  And whether it makes sense depends on your initial bias. Make sense?
cm2187 7y ago
You are assuming companies make decisions for a single reason.
thrwway4298 7y ago
>A random person speculating “maybe they did this for privacy reasons” doesn’t strike me as better than Cloudflare saying “we did this for privacy reasons”. you are saying the accessor function getX() which returns a value of X but you don't trust it, you think it's giving you crap, should not be treated any differently depending on whether the getX() function even has access to X or has absolutely no such access. (For example if the value of x isn't even on the same network partition as the getX() function you don't trust.) You're saying if you don't trust it, it doesn't matter if the function itself even has access to X or doesn't. In one sense that might be true, but in another sense that seems silly. If getX itself has access to X, you can try to determine whether it is giving it to you. if getX doesn't have any access to X, then it doesn't really matter what it's doing, its process is irrelevant. so to me there's a huge material difference. We can try to judge the process by which getX() returned Cloudflare's motivations. What steps did it perform to return that value? What's the code? etc. huge difference. that knowledge is somewhere in the company.
- krageon 7y ago
  To summarise, your position is that what Cloudflare says is more trustworthy because they know the truth. You do not really address the fact that they are not required to say the truth, or that when the truth is harmful for their public image they are directly incentivised to not speak the truth. The only way you do address this is by saying that this is something that needs investigating. I would posit that the grandparent has done this already, and come to the sensible conclusion: There is less reason to trust someone incentivised to lie than there is to trust someone who knows nothing. Aside from that trust, we have to evaluate the validity of statements. Given prior knowledge, for Cloudflare in the bad case the likelihood of a valid statement approaches zero. For the random yelling things as they pop into their mind, it is completely unknown.
  - thrwway4298 7y ago
    My position is only that there's a difference. In some sense we could treat it as though it's just garbage, but it's worth investigating. For example if it was written by an outside PR person who has no access to the people who made the decision, that also changes things. It's not so pure. For example an outsider here on HN who says "A close relative of mine works at cloudflare on the team that made this decision, and he confided in me..." -- then again you have to somehow judge if this is true or not, but it is worth treating it differently from someone writing "I don't have any insider information and this is pure speculation, but maybe..." I mean it just doesn't make sense to treat these cases as exactly the same. I wanted to give another example. say you don't trust the gps coordinates you're being given when you make an API call on a device. would it make sense to treat it exactly the same as making the API call on a device that doesn't even have a gps module, such as a microcontroller without gps or wifi/cellular access or anything that can be a proxy for gps? if there's a physical module and you don't trust the output, at least you can investigate. it doesn't make sense to treat it exactly the same as if the information isn't even on the same device. it depends on the details of the process that's giving you the output you don't trust. What's the process by which getX returns its output? What's the process by which Cloudflare employees make statements about their motivations (which they do have access to)? These are questions we can investigate. if we find that the statements are written by a PR agency who hasn't even stepped in their building and has no contact with the teams they're lying on behalf of, that's a possible result too. but it's worth looking into.

113 7y ago

Corporations operate for profit.

tedk-42 7y ago
Indeed - but there are other ways to make money than to sell of your personal information to the highest advertising bidder.
- jgrahamc 7y ago
  Such as, in Cloudflare's case, selling our service (the DDoS protection, the caching, the firewalling etc.) to companies that pay for that service because it helps them. While at the same time working to preserve people's privacy with things like giving out SSL for free, pushing for eSNI, running a public DoH server, building a service that makes sure all data from your phone to us is encrypted etc. etc.
  - denton-scratch 7y ago
    "like giving out SSL for free" The market rate for standard SSL certs is zero.
    - jgrahamc 7y ago
      It wasn't in 2014 (https://blog.cloudflare.com/introducing-universal-ssl/ https://blog.cloudflare.com/introducing-universal-ssl/) when we launched it.
  - cnst 7y ago
    It's been shown that Cloudflare's DoH service is a lot ado about nothing, and is actually worse for privacy, not better: * https://news.ycombinator.com/item?id=21071022 https://news.ycombinator.com/item?id=21071022 Likewise for 1.1.1.1 — when taking into consideration the local caching appliances that the ISPs have invested in, the lack of ECS would make the clients go all the way through the internet for the same content that's already cached locally by the ISP for users of all other decent resolvers — this will only contribute to increased costs for the individual ISPs, extra latency for users, and more competitive advantage of your products due to you diminishing the technological advantages of your competitors, without regard to the actual user experience of the users, or the reliability and scaling of the internet infrastructure at large. Not to mention that such Netflix/YouTube usage, when going directly through transit providers and through the whole internet, would also subject the users to a greater chance of surveillance at large compared to users of resolvers that would access local copies on the caching appliance.
    - pixl97 7y ago
      Except in the US the ISPs are some of the biggest surveillance organizations themselves. They are also highly monopolized so most people in the US are on one of a very small number of ISPs
      - zrm 7y ago
        Which is a good argument for not using your ISP's DNS either, but those are not the only two options. One of the better alternatives is to get a VPN you trust that puts multiple users behind the same IP address and then operate your own recursive DNS from behind there. The VPN service itself could still log your queries, but at least they have plenty of competitors, and you chose one you trust, right? Or if you don't want to trust any one party, use Tor.
    - andreareina 7y ago
      It has been argued, I wouldn't say that it has been shown. Both my ISPs operate a DNS blacklist. So did my previous ISPs, in the country I previously lived in. And in a third country, where I was on holiday. ISPs even in the USA are gnashing their teeth at the prospect of losing visibility into DNS. Why would they care if they weren't using that data? Why do they need a subscriber -> [domain] mapping? Routing tables don't care about domain names. Edge caching of web content doesn't work with https. I might care about DNS caching if the ISPs haven't demonstrated time and again that they will abuse my privacy for a buck, after I've already paid them for the privilege. I trust Cloudflare much more than I trust any ISP I've had to deal with, including American ISPs when I lived there. I trust Google much more than any ISP, and I'm not particularly charitable towards Google. Centralized DoH isn't perfect, but it's better than the status quo. The SNI hole is shrinking. My threat model does not include defending against the Mossad doing Mossad things with my email^H^H^H^H^HDNS[1]. [1] https://www.usenix.org/system/files/1401_08-12_mickens.pdf https://www.usenix.org/system/files/1401_08-12_mickens.pdf
  - tomp 7y ago
    If you're trying to preserve people's privacy, why doesn't the 1.1.1.1 VPN service also mask originating IP?
    - jgrahamc 7y ago
      Warp isn't trying to "hide your IP from the sites you are visiting". It's there to help prevent intermediaries from observing your traffic. A huge percentage of the web is still unencrypted HTTP. And Warp+ aims to be about that plus performance. If you want to be totally anonymous on the Internet then I recommend you use Tor. If you just use a VPN then you may hide your IP address from sites you visit but there are tons of other fingerprinting techniques that can be used.
      - tomp 7y ago
        I understand all that, and you didn't answer my question. Why do you push the narrative that 1.1.1.1 DNS resolver protects user privacy (by hiding originating IP / subnet) whereas 1.1.1.1 VPN gladly reveals that data? In both cases, the destination is hidden to any eavesdroppers, but in the latter case (VPN) the source IP is visible to the destination website, whereas you keep insisting how vital it is to hide source IP in the former case (DNS).
        jgrahamc 7y ago
        In the case of Warp, we add the connecting IP information as a header to the HTTP request for sites on Cloudflare. This will typically be inside TLS to the origin server, and so the source IP information will be encrypted and only visible to the web site being visited. In the case of DNS information about the subnet, the query etc. is sent around unencrypted. One is open to eavesdropping, the other is not.
        zzzcpan 7y ago
        Someone capable of eavesdropping on that query sure as hell capable of eavesdropping on incoming connections to 1.1.1.1 where they can see actual IP address that initiated the query. There is no way to justify this as a privacy feature. Well, unless people don't understand enough to believe you.
nindalf 7y ago
And so you accept the first answer. That’s fine. Cloudflare has repeatedly said that while they operate for profit, they take the long term view. By doing the right thing now, by being privacy focussed, they will be profitable for decades to come. This seems logical to me, which makes the second answer more believable.
- nathanpotter 7y ago
  Do you remember "do no evil"? Pepperidge Farms remembers.

yc12340 7y ago

Nah, I will assume it as truth only when it makes sense.

nindalf 7y ago
And whether it makes sense depends on your initial bias. Make sense?

cm2187 7y ago

You are assuming companies make decisions for a single reason.

thrwway4298 7y ago

>A random person speculating “maybe they did this for privacy reasons” doesn’t strike me as better than Cloudflare saying “we did this for privacy reasons”. you are saying the accessor function getX() which returns a value of X but you don't trust it, you think it's giving you crap, should not be treated any differently depending on whether the getX() function even has access to X or has absolutely no such access. (For example if the value of x isn't even on the same network partition as the getX() function you don't trust.) You're saying if you don't trust it, it doesn't matter if the function itself even has access to X or doesn't. In one sense that might be true, but in another sense that seems silly. If getX itself has access to X, you can try to determine whether it is giving it to you. if getX doesn't have any access to X, then it doesn't really matter what it's doing, its process is irrelevant. so to me there's a huge material difference. We can try to judge the process by which getX() returned Cloudflare's motivations. What steps did it perform to return that value? What's the code? etc. huge difference. that knowledge is somewhere in the company.

krageon 7y ago
To summarise, your position is that what Cloudflare says is more trustworthy because they know the truth. You do not really address the fact that they are not required to say the truth, or that when the truth is harmful for their public image they are directly incentivised to not speak the truth. The only way you do address this is by saying that this is something that needs investigating. I would posit that the grandparent has done this already, and come to the sensible conclusion: There is less reason to trust someone incentivised to lie than there is to trust someone who knows nothing. Aside from that trust, we have to evaluate the validity of statements. Given prior knowledge, for Cloudflare in the bad case the likelihood of a valid statement approaches zero. For the random yelling things as they pop into their mind, it is completely unknown.
- thrwway4298 7y ago
  My position is only that there's a difference. In some sense we could treat it as though it's just garbage, but it's worth investigating. For example if it was written by an outside PR person who has no access to the people who made the decision, that also changes things. It's not so pure. For example an outsider here on HN who says "A close relative of mine works at cloudflare on the team that made this decision, and he confided in me..." -- then again you have to somehow judge if this is true or not, but it is worth treating it differently from someone writing "I don't have any insider information and this is pure speculation, but maybe..." I mean it just doesn't make sense to treat these cases as exactly the same. I wanted to give another example. say you don't trust the gps coordinates you're being given when you make an API call on a device. would it make sense to treat it exactly the same as making the API call on a device that doesn't even have a gps module, such as a microcontroller without gps or wifi/cellular access or anything that can be a proxy for gps? if there's a physical module and you don't trust the output, at least you can investigate. it doesn't make sense to treat it exactly the same as if the information isn't even on the same device. it depends on the details of the process that's giving you the output you don't trust. What's the process by which getX returns its output? What's the process by which Cloudflare employees make statements about their motivations (which they do have access to)? These are questions we can investigate. if we find that the statements are written by a PR agency who hasn't even stepped in their building and has no contact with the teams they're lying on behalf of, that's a possible result too. but it's worth looking into.