4 ms·
I think perfect really is the enemy of good in this case. Attack vectors will presumably always exist. I look upon any argument against openness - be it softwar
by Reelin 6y ago
I think perfect really is the enemy of good in this case. Attack vectors will presumably always exist. I look upon any argument against openness - be it software licensing, protocol federation, data export, binary blob usage, or anything else - with _extreme_ skepticism.
> ... I generally have to trust every single host that any of my contacts has decided to sign up with ...
In general, you should only have to trust a particular host with communications going to the specific contact that uses it.
> Am I the exception here? Does everyone here only have friends who are IT security experts ...
No, I think you're just looking at the problem the wrong way.
With a centralized model, you generally have to unconditionally trust the central authority.
A federated system offers much more flexibility. Metadata is likely to be spread piecemeal across multiple hosts and network paths, making it much more difficult for an adversary to analyze in the general case. Instead of a blanket trust decision, you make a per-contact decision based on the nature of the interaction you intend to have with them. If you feel the need, you can even self host and insist that a particular contact register with _your_ server to communicate with you.
If you absolutely can't trust someone to make good decisions with security critical information, it's unlikely Signal can do much to change the threat they pose to you in a real world scenario anyway. At the end of the day you're ultimately choosing how much trust to place in the person you're communicating with regardless of which system you use to do so.
> ... there will eventually appear "supernodes" which have a disproportionally high number of edges/connections to other nodes ...
That's certainly an interesting dynamic but it's hardly an argument against federation. Centralization is literally the worst case in that model (ie a single node and nothing else). In a federated network you have a choice of whether to make use of such supernodes. If it really matters, I can (for example) refuse to communicate with a particular contact regarding some sensitive topic via (say) gmail. A centralized system doesn't provide that option at all.
- codethief 6y agoI think we need to agree on a common threat model because right now I'm getting the impression that you and I are assessing things from very different angles. If any of the 3-letter agencies decide to target John Doe specifically and expend significant resources on this task, I think we can agree that chances are they will succeed. Neither a centralized or a federated approach will protect John from that because, unless John is a security expert and very paranoid and careful in everything he does online, there will be many other attack vectors. Signal's goal, however, is to protect the masses and, thus, society as a whole, by protecting as many people's privacy as possible. The things that are at stake here are not the data and the social graph of a handful of individuals, but the data and social graph of society as a whole. (I'm sure I don't have to mention the implications for democracy and social order.) My perspective, therefore, was that of an average user. The reason I mentioned my personal situation and the fact that I myself spend quite a bit of time on making sure my systems are safe, was to emphasize that if the situation is already overly complicated for me, it will be much worse for the average user. > In general, you should only have to trust a particular host with communications going to the specific contact that uses it. I don't think the word "only" is appropriate here. Let's say John Doe has roughly ~1000 contacts. This means that, in the worst case, he would have to research ~1000 hosts and their privacy policies. Now the "accumulation effect" I mentioned previously will reduce that number quite a bit but there are still going to be dozens of different hosts. I doubt we could expect John to look into each and everyone of them before he gets in touch with his contacts. (Note that this gets even worse when people can freely switch between hosts, as suggested e.g. by other replies to my comment, as John will then have to repeatedly do the checking.) Therefore, I think it is reasonable to expect that a significant number (millions, if not billions) of users will end up residing on insecure and untrustworthy hosts and their social graph and metadata – and possibly even their data (see below) – won't be protected at all. > With a centralized model, you generally have to unconditionally trust the central authority. In the federated model, John has to do that, too. Sure, he can self-host but how many people are actually going to do that? Put differently, the vast majority of all acts of communication in the network is going to get routed not through self-hosted nodes but through the servers of providers whose trustworthiness is at least questionable. I hope you will agree that, for society as a whole, this exacerbates the trust problem you mentioned. > A federated system offers much more flexibility. Metadata is likely to be spread piecemeal across multiple hosts and network paths, making it much more difficult for an adversary to analyze in the general case. A federated system also makes it much easier for adversaries to enter the game, as they don't have to compromise a well-known provider like Signal that is under the close scrutiny of the public. Instead, they can just create new hosts (just like they do in the case of the Tor network). What's worse, in this case they won't just be able to access their user's social graphs but very likely also the content of their messages, as the key discovery problem is usually solved by hosts distributing their users' public keys.
- Reelin 6y agoI'm arguing that the contact themselves, not the node they use, is the primary threat. > Signal's goal, however, is to protect the masses and, thus, society as a whole, by protecting as many people's privacy as possible. Sure, by positioning themselves as the only node, which you are then forced to trust. That hardly seems like an acceptable solution to me. The chance of a given mainstream node being actively malicious seems unlikely to me. Maybe that's misguided, but at least (as you point out) there will be relatively few big ones to research. Non-mainstream nodes don't pose a significant threat by virtue of having little to no use (and so seeing little to none of your traffic and contact graph). > ... the vast majority of all acts of communication in the network is going to get routed not through self-hosted nodes ... I hope you will agree that, for society as a whole, this exacerbates the trust problem you mentioned. Actually, it seems to diminish the problem to me. Instead of everything going through one central authority it's now being split across multiple actors. No single entity has access to the complete picture anymore. Moreover, you as the user have the freedom to avoid such supernodes if you feel the need. Yes, that will likely introduce usability hurdles, but at least you have the freedom to do so (as compared to a strictly centralized model). > Instead, they can just create new hosts (just like they do in the case of the Tor network). Doesn't this attack model fail to account for how users go about selecting and using servers? If I join the Mozilla instance to chat with them, that wasn't an arbitrary choice - I selected the instance that the organization I want to communicate with is using. So the other party, which I'm going to communicate with one way or another, is the real threat here. As far as MITM attacks go, that scenario seems to get a bit out into the weeds cryptographically. I'm not sure how viable a large scale attack would be here - presumably at some point odd traffic patterns would become noticeable? And you still have the issue of a malicious node that actively attacks all traffic needing to somehow manage to grow its user base to a significant degree.