3 ms·

> 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

by 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.
  - 5y ago

by md_ 5y ago

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.
- 5y ago