4 ms·

> Apparently there aren't any groups reverse engineering every WhatsApp update to figure out if it's still encrypting everything. If that were true--in the cas

by md_ 5y ago

> Apparently there aren't any groups reverse engineering every WhatsApp update to figure out if it's still encrypting everything. If that were true--in the case of WhatsApp, I'm pretty sure it's not, as another poster here pointed out--it would be equally true for any open source app. Like, I dunno, Debian (https://jblevins.org/log/ssh-vulnkey https://jblevins.org/log/ssh-vulnkey). There's absolutely a place for reproducible builds and binary transparency in the ecosystem. But those seem to me to be examples of what Moxie described: using cryptography to provide privacy and security guarantees while building on top of centralized infrastructure. Would you rather binary transparency, or would you rather run Sendmail on your Debian server in your closet because, hey, it's physically yours? The conclusion that the latter is better is just nonsensical. (And of course, Bitcoin Wallet is in the Play store, distributed in exactly the same way as Signal...)

mike_hearn 5y ago
You can do both, they aren't exclusive. There's a class of problems you can't solve with cryptography. See the discussion up-thread about browsers. Would I rather have binary transparency or run my own mail server? Well, I might like an auditable Gmail but what I can actually get today is my own sendmail. So it's an academic point. Moreover, there's no particular reason running a mail server has to be as painful as it is. It's a PITA because nobody with usability skills has invested time to make it point-and-click, self maintaining etc (+ of course, finding a good reputation block of IPs). Nonetheless, if someone sat down and wanted to make messaging more decentralized today, making self-hosted email easier would actually be a tractable problem you could start on. Changing Facebook or Google policies, not so much. That has value even if it seems hard to imagine a great outcome today. Bitcoin Wallet is in the Play Store, can also be sideloaded, is open source, forkable, and connects directly to a P2P network. It doesn't rely on infrastructure run by the developers. It'd be even better if Android let you (or another app) audit installs but it's not a bad foundation.
- md_ 5y ago
  > Well, I might like an auditable Gmail Who proposed binary transparency for Gmail (the server)? The whole premise of tools like Signal is that enough happens in the client--which is amenable to binary transparency--that the server is immaterial. Sure, if you attack that strawman sufficiently, the only alternative is running your own Sendmail. And yes, it could suck less. My point was a bit bolder than that, though: not only does binary transparency (which, to be clear, is about client code, not the server itself) substantially mitigate the concerns you might have trusting a centralized service, but running a computing stack of millions of lines of code yourself does not at all mitigate those concerns. Sendmail isn't "yours", even if it's open source. It's a bunch of random patches from random people, some of which will erroneously "fix" a Valgrind error and remove cryptographic entropy from the RNG, others of which will contain intentional backdoors, etc, etc. The fact that you're running it yourself in your closet just doesn't matter. Physical locality--and hardware ownership--don't make a difference.
  - mike_hearn 5y ago
    But there's only one client. And, that's deliberate - Signal doesn't allow federation for philosophical/iteration speed/competitiveness reasons. So in practice, if the client changes you're out of luck. It's encryption that lasts as long as the service owner thinks it should last, but if it's going to be like that, they could also just promise not to look. The point of defining an adversary in cryptography is to stop them from doing things, not just noticing if they do. Hence, we end up back to my point about threshold signatures. With a threshold software update system and a network of auditing firms, you can actually enforce good behavior on the adversary because they no longer fully control the client, and the client is treating the server as untrusted. This is a form of decentralization, albeit very different to the classical kind (p2p networks, multiple clients, federation etc). It should also be amenable to rapid iteration. Totally agree that open source is often a bit of a black box and maybe nobody is auditing it properly. But if you do become aware of a bad change / back door, and the system is at least somewhat decentralized and a part of it is physically yours, you can just switch to a better implementation. No such luck with a centralized system: the client may be open source but if only the official client is allowed to connect to the servers it's irrelevant. And all E2E messengers today (except Telegram?) have such a policy.
    - md_ 5y ago
      Wow. Where to begin. :) > …there’s only one client…It’s encryption that lasts as long as the owner thinks it should last… I think this is a big leap. It’s a open source client with verifiable builds. If a future version removes encryption, users will migrate to Wire, or Threema, or Matrix, or whatever. How does there being only one client make the encryption non-resistant to an adversary? It’s genuinely unclear to me what you consider the difference between: - Multiple open source clients, distributed as source or prebuilt binaries, possibly signed and verifiable, possibly downloaded over TLS, depending on what Linux distro you use. <— This is the state of the art for most open source software. - A single open source client, developed in the open and distributed with verifiable builds where feasible via broadly reliable and unlikely-to-collude third-party distribution mechanisms (the app stores). <- This is how Signal works. - A single open source client, developed in the open and distributed with verifiable builds everywhere. <— This would be nice, if the app stores would support it! > The point of defining an adversary is…not just noticing if they do Well, no, I disagree. As a prominent example, Certificate Transparency. “Noticing”—aka accountability—is extremely useful. As I noted above, there is a multitude of free, secure Signal competitors. The only thing that keeps millions of users using Signal is trust based on accountability. Building better accountability mechanisms means that if Signal violates that trust, users can switch, before they discuss hiring hitmen/buying meth/overthrowing the government on an unencrypted channel. > …threshold signatures… TBH, I didn’t read this part of your post that closely. There is a lot of work being done on binary transparency, and your proposal seems broadly in the same direction, but I’m not following this space very closely. What I don’t follow is why you think it requires multiple clients. > …you can just switch to a better implementation… Aha. And here’s your point—not that a single client thwarts encryption, but that a single client for a sufficiently sticky centralized service would reduce the ability of users (who may not care that much) to switch away, should the encryption be disabled. And sure, I think this is true to a degree. But as Aol/Google Talk/WhatsApp-post-ToS-change can tell you, messaging is not that sticky! Anyway, ultimately the market has spoken. Ping me when everyone is using XMPP/Matrix/whatever. In the meantime, I hope the Signal Foundation keep building usable secure products for people like me. When they sell out, I’ll switch to Threema.
- PaulDavisThe1st 5y ago
  > Nonetheless, if someone sat down and wanted to make messaging more decentralized today, making self-hosted email easier would actually be a tractable problem you could start on. This is the point I was making on the original Moxie/web3 thread here on HN. However ... > Changing Facebook or Google policies, not so much. One of the issues with "making self-hosted email easier" is that it does, at least in part, depend on Facebook (and particularly) Google policies regarding email acceptance/forwarding, and while these are somewhat more technical than some of the policies you're referring to, they are still policies, and still pretty hard to change. You can't make reliable exchange of email dependent on IP block reputation. Getting back to a world where self-hosted email worked as well as Gmail on the receiving side and SES-like services on the other would be a huge plus, but I don't think it's particularly easy to accomplish. Still, it could be tractable, and that is the adjective you used.
  - mike_hearn 5y ago
    I used to work on the Gmail spam filter. There weren't any rules or policies specifically about punishing small operators of course, but: 1. PBL (policy blocklist) was used like in all spam filters, to stop residential IPs sending mail. You can get yourself removed from this if you have a static IP normally just by asking. 2. Smaller senders are often sitting in cheap IP blocks that aren't too picky about the neighbours. Spam filters do use IP proximity as a signal for better or worse, so if you sign up with a company that doesn't do anti-abuse work then, well, all your IPs will have been heavily abused in the past. An individual IP can still stand out from the crowd but to do that, you have to get people to mark your mail as not spam, so there's a nasty catch 22 there. But fixing it seems fundamentally difficult. Something like what Authenticode does with EV certs might have worked. One way to make progress here might be to have a SOCKS proxy service for SMTP-TLS connections, that does ID verification, requires large crypto deposits or has some other way to try and discourage spammers from signing up. Then if you have an account, the service will find and buy clean IPs and let you proxy through them. The service can sign up to exchange ARF spam reports from the major providers to locate abusers and shut them down before it's too late. I'm not sure SOCKS provides quite enough detail to fight outbound spam properly, but you could also experiment with an SGX enclave. That way basic anti-spam logic like "is it DKIM signed, does it advertise SPF, is there an abuse reporting address in the headers" could be made auditable. You still face the question of "pray I don't alter the deal further", but just running some SMTP proxies isn't a very difficult task - kinda like a VPN service - so there'd hopefully be a competitive market of them.

by md_ 5y ago

mike_hearn 5y ago

You can do both, they aren't exclusive. There's a class of problems you can't solve with cryptography. See the discussion up-thread about browsers. Would I rather have binary transparency or run my own mail server? Well, I might like an auditable Gmail but what I can actually get today is my own sendmail. So it's an academic point. Moreover, there's no particular reason running a mail server has to be as painful as it is. It's a PITA because nobody with usability skills has invested time to make it point-and-click, self maintaining etc (+ of course, finding a good reputation block of IPs). Nonetheless, if someone sat down and wanted to make messaging more decentralized today, making self-hosted email easier would actually be a tractable problem you could start on. Changing Facebook or Google policies, not so much. That has value even if it seems hard to imagine a great outcome today. Bitcoin Wallet is in the Play Store, can also be sideloaded, is open source, forkable, and connects directly to a P2P network. It doesn't rely on infrastructure run by the developers. It'd be even better if Android let you (or another app) audit installs but it's not a bad foundation.

md_ 5y ago
> Well, I might like an auditable Gmail Who proposed binary transparency for Gmail (the server)? The whole premise of tools like Signal is that enough happens in the client--which is amenable to binary transparency--that the server is immaterial. Sure, if you attack that strawman sufficiently, the only alternative is running your own Sendmail. And yes, it could suck less. My point was a bit bolder than that, though: not only does binary transparency (which, to be clear, is about client code, not the server itself) substantially mitigate the concerns you might have trusting a centralized service, but running a computing stack of millions of lines of code yourself does not at all mitigate those concerns. Sendmail isn't "yours", even if it's open source. It's a bunch of random patches from random people, some of which will erroneously "fix" a Valgrind error and remove cryptographic entropy from the RNG, others of which will contain intentional backdoors, etc, etc. The fact that you're running it yourself in your closet just doesn't matter. Physical locality--and hardware ownership--don't make a difference.
- mike_hearn 5y ago
  But there's only one client. And, that's deliberate - Signal doesn't allow federation for philosophical/iteration speed/competitiveness reasons. So in practice, if the client changes you're out of luck. It's encryption that lasts as long as the service owner thinks it should last, but if it's going to be like that, they could also just promise not to look. The point of defining an adversary in cryptography is to stop them from doing things, not just noticing if they do. Hence, we end up back to my point about threshold signatures. With a threshold software update system and a network of auditing firms, you can actually enforce good behavior on the adversary because they no longer fully control the client, and the client is treating the server as untrusted. This is a form of decentralization, albeit very different to the classical kind (p2p networks, multiple clients, federation etc). It should also be amenable to rapid iteration. Totally agree that open source is often a bit of a black box and maybe nobody is auditing it properly. But if you do become aware of a bad change / back door, and the system is at least somewhat decentralized and a part of it is physically yours, you can just switch to a better implementation. No such luck with a centralized system: the client may be open source but if only the official client is allowed to connect to the servers it's irrelevant. And all E2E messengers today (except Telegram?) have such a policy.
  - md_ 5y ago
    Wow. Where to begin. :) > …there’s only one client…It’s encryption that lasts as long as the owner thinks it should last… I think this is a big leap. It’s a open source client with verifiable builds. If a future version removes encryption, users will migrate to Wire, or Threema, or Matrix, or whatever. How does there being only one client make the encryption non-resistant to an adversary? It’s genuinely unclear to me what you consider the difference between: - Multiple open source clients, distributed as source or prebuilt binaries, possibly signed and verifiable, possibly downloaded over TLS, depending on what Linux distro you use. <— This is the state of the art for most open source software. - A single open source client, developed in the open and distributed with verifiable builds where feasible via broadly reliable and unlikely-to-collude third-party distribution mechanisms (the app stores). <- This is how Signal works. - A single open source client, developed in the open and distributed with verifiable builds everywhere. <— This would be nice, if the app stores would support it! > The point of defining an adversary is…not just noticing if they do Well, no, I disagree. As a prominent example, Certificate Transparency. “Noticing”—aka accountability—is extremely useful. As I noted above, there is a multitude of free, secure Signal competitors. The only thing that keeps millions of users using Signal is trust based on accountability. Building better accountability mechanisms means that if Signal violates that trust, users can switch, before they discuss hiring hitmen/buying meth/overthrowing the government on an unencrypted channel. > …threshold signatures… TBH, I didn’t read this part of your post that closely. There is a lot of work being done on binary transparency, and your proposal seems broadly in the same direction, but I’m not following this space very closely. What I don’t follow is why you think it requires multiple clients. > …you can just switch to a better implementation… Aha. And here’s your point—not that a single client thwarts encryption, but that a single client for a sufficiently sticky centralized service would reduce the ability of users (who may not care that much) to switch away, should the encryption be disabled. And sure, I think this is true to a degree. But as Aol/Google Talk/WhatsApp-post-ToS-change can tell you, messaging is not that sticky! Anyway, ultimately the market has spoken. Ping me when everyone is using XMPP/Matrix/whatever. In the meantime, I hope the Signal Foundation keep building usable secure products for people like me. When they sell out, I’ll switch to Threema.
PaulDavisThe1st 5y ago
> Nonetheless, if someone sat down and wanted to make messaging more decentralized today, making self-hosted email easier would actually be a tractable problem you could start on. This is the point I was making on the original Moxie/web3 thread here on HN. However ... > Changing Facebook or Google policies, not so much. One of the issues with "making self-hosted email easier" is that it does, at least in part, depend on Facebook (and particularly) Google policies regarding email acceptance/forwarding, and while these are somewhat more technical than some of the policies you're referring to, they are still policies, and still pretty hard to change. You can't make reliable exchange of email dependent on IP block reputation. Getting back to a world where self-hosted email worked as well as Gmail on the receiving side and SES-like services on the other would be a huge plus, but I don't think it's particularly easy to accomplish. Still, it could be tractable, and that is the adjective you used.
- mike_hearn 5y ago
  I used to work on the Gmail spam filter. There weren't any rules or policies specifically about punishing small operators of course, but: 1. PBL (policy blocklist) was used like in all spam filters, to stop residential IPs sending mail. You can get yourself removed from this if you have a static IP normally just by asking. 2. Smaller senders are often sitting in cheap IP blocks that aren't too picky about the neighbours. Spam filters do use IP proximity as a signal for better or worse, so if you sign up with a company that doesn't do anti-abuse work then, well, all your IPs will have been heavily abused in the past. An individual IP can still stand out from the crowd but to do that, you have to get people to mark your mail as not spam, so there's a nasty catch 22 there. But fixing it seems fundamentally difficult. Something like what Authenticode does with EV certs might have worked. One way to make progress here might be to have a SOCKS proxy service for SMTP-TLS connections, that does ID verification, requires large crypto deposits or has some other way to try and discourage spammers from signing up. Then if you have an account, the service will find and buy clean IPs and let you proxy through them. The service can sign up to exchange ARF spam reports from the major providers to locate abusers and shut them down before it's too late. I'm not sure SOCKS provides quite enough detail to fight outbound spam properly, but you could also experiment with an SGX enclave. That way basic anti-spam logic like "is it DKIM signed, does it advertise SPF, is there an abuse reporting address in the headers" could be made auditable. You still face the question of "pray I don't alter the deal further", but just running some SMTP proxies isn't a very difficult task - kinda like a VPN service - so there'd hopefully be a competitive market of them.