moxie

A lot has changed since 2014, and this might actually be possible now. It could be tough to do this right and figure out what to do with the edge cases like importing a WA conversation that overlaps with an existing Signal conversation, or handling things like quoted replies, but this could be a fun project if anyone here wants to take a shot at coding it up.

Yeah, bummer. There were some iOS 14 changes that made this stop working as reliably, which was unfortunately right around the time people were getting new devices. It should be better now, and we're working on more stuff in this area.

They store your social graph in plaintext on their servers.

FWIW, there are a couple of things about Apple's and Google's systems that don't work for Signal:

1. There is no meaningful remote attestation. There's no way to verify that there are HSMs at the other side of the connection at all. The people who issued the certificates are the same people terminating the connections.

2. There's no real information about what these HSMs are or what they're running. Even if we trust that the admin cards have been put in a blender, we don't know what the other weak spots are.

3. The services themselves are not cross-platform, so cross-platform apps like Signal can't use them directly.

4. It's not clear how they do node/cluster replacement, and it seems possible that they require clients to retransmit secrets in that case, which is a potentially significant weakness if true. I could be wrong about this, but the fact that I have to speculate is kind of a problem in itself.

My impression is that you're suggesting the HSMs Apple uses are better than SGX in some way, but it's not clear that anyone could know one way or the other. I think all of the scrutiny SGX is receiving is ultimately a good thing: it helps shake out bugs and improve security. It's not clear to me that the HSMs Apple uses would actually fare better if scrutinized in the same way, which could be a missed security opportunity for them.

We didn't feel that it would be best for Signal to start with a system where we say "believe that we've set up some HSMs, believe this is the certificate for them, believe the data that is transmitted is stored in them." So we've started with something that we feel has somewhat more meaningful remote attestation, and hopefully now we can weave in other types of hardware security, or maybe even figure out some cross-platform way to weave in existing deployments like iCloud Keychain etc.

> As for Lyme disease: The actual infection can be treated with a standard course of antibiotics. The infection does not persist indefinitely, although some people experience long-lasting effects after the infection is gone.

I don't think it's possible to make an absolute statement like this with 100% certainty given the current state of the art. Lyme is a spirochete, and there also seems to be real research suggesting it can grow biofilm to make it antibiotic resistant or resurgent.

There are patients who test positive under CDC criteria, take antibiotics, and never see a transition from IgM to IgG.

There are also patients who test postive under CDC criteria, take antibiotics, see a transition, but still experience symptoms (what you would call 'long-lasting effects'). In some cases patients in that situation have extreme gland swelling that when biopsied, seem to contain Lyme.

Like all of medicine, I think it's squishier than what you're describing. There is also a lot of crazy shit on the internet, but like you say, that's because people are genuinely suffering and have no alternatives.

"Only 1400 kilograms of uranium and graphite mixture would have needed to hit the water to set off a new explosion. Our experts studied the possibility and concluded that the explosion would have had a force of 3 to 5 megatons. Minsk...would have been razed." - Vassili Nesterenko, director of the Institute of Nuclear Energy at the National Academy of Sciences of Belarus.

I am not a nuclear physicist, but at least some people who are did not find this to be "clearly nonsense."

I think there's a lot of uncertainty in talking about Chernobyl, since most of the information published by the Soviet authorities was intentionally incorrect or misleading, designed to downplay the significance of the accident.

One thing I've found interesting in talking about Chernobyl is that advocates of nuclear power are often willing to accept the Soviet numbers as fact, since they confirm the idea that nuclear power is still relatively "safe" even in case of disaster.

I don't know what the exact numbers are, and I'm not sure if any of us will ever know for sure, but one of the documentaries I like is Discovery's "Battle of Chernobyl," since it includes a lot of interviews with people who were actually there and participated in the events. They interview Nikolay Antoshkin, the colonel general in charge of the helicopter operations there, which is where the 600 pilot deaths number comes from. I'm more inclined to believe that account than what the state published.

Here's how WhatsApp group messaging works: membership is maintained by the server. Clients of a group retrieve membership from the server, and clients encrypt all messages they send e2e to all group members.

If someone hacks the WhatsApp server, they can obviously alter the group membership. If they add themselves to the group:

1. The attacker will not see any past messages to the group; those were e2e encrypted with keys the attacker doesn't have.

2. All group members will see that the attacker has joined. There is no way to suppress this message.

Given the alternatives, I think that's a pretty reasonable design decision, and I think this headline pretty substantially mischaracterizes the situation. I think it would be better if the server didn't have metadata visibility into group membership, but that's a largely unsolved problem, and it's unrelated to confidentiality of group messages.

In contrast, Telegram does no encryption at all for group messages, even though it advertises itself as an encrypted messenger, and even though Telegram users think that group chats are somehow secure. An attacker who compromises the Telegram server can, undetected, recover every message that was sent in the past and receive all messages transmitted in the future without anyone receiving any notification at all.

There's no way to publish an academic paper about that, though, because there's no "attack" to describe, because there's no encryption to begin with. Without a paper there will be no talks at conferences, which means there will be no inflammatory headlines like this one.

To me, this article reads as a better example of the problems with the security industry and the way security research is done today, because I think the lesson to anyone watching is clear: don't build security into your products, because that makes you a target for researchers, even if you make the right decisions, and regardless of whether their research is practically important or not. It's much more effective to be Telegram: just leave cryptography out of everything, except for your marketing.

> That defense, which happens to be the only defense, is turned off by default in WhatsApp. > You seem to argue they do so because it's bad UX to present such notification by default. That's - in my humble opinion - like suggesting browsers should turn off TLS chain errors by default because it's bad UX and just proceed with the connection as if nothing happened...

One thing we've learned over the years is that security warnings should not be displayed to consumers under "normal" (eg. non-critical) circumstances, otherwise it creates a condition of "warning fatigue."

TLS certificate errors are not something that should happen under normal circumstances. When a TLS certificate fails to validate, something is really wrong. As we've gotten better about ensuring those conditions, browsers have made it harder and harder to get past the warnings, because they're not warnings anymore -- they're error conditions.

Key changes in a messenger are totally different. They happen under normal conditions, so putting them in people's faces by default has the potential to do more harm than good. If we can make them workable, systems like CONIKS or Key Transparency might be in our collective future, but if you don't like systems that are fundamentally "advisory" (don't tell you until after the fact), you're not going to like those new systems at all either.

For now, I think a fact of life is that most people will not verify keys whether the warnings are there or not, so I think what's most important is that the server can't tell who is and who isn't.

I'd love to hear other ideas about how to improve the UX of interactions like this, but I think they have to include a basis in the assumption that we can't fundamentally change human behavior and that we can't just teach everyone in the world to be like us.

> This allows WhatsApp to MITM. Whatapps can rekey both Alice and Bob, decrypt both their messages from that point onwards (incl unsent messages) and forward them re-encrypted with their real keys. The only notification might be that rekeying warning, if the users have turned it on. In this scenario even the double-checkmarks are present. This is contrary to WhatsApp's claim that even they cannot snoop.

You've just described a "man in the middle" attack. It is endemic to any public key cryptosystem, including Signal and PGP, not just WhatsApp. The notification that you see in WhatsApp, Signal, SSH, PGP, or whatever is the defense.

> PS: I just check on my phone if those notifications were turned on. There were not. And I'd never turn those off myself, which leads me to conclude that the rekeying notifications are off by default (in their android app)

Key change notifications are off by default in WhatsApp. That's probably going to be a fundamental limit of any application that serves billions of people from many different demographics all over the world.

Even if they were on by default, a fact of life is that the majority of users will probably not verify keys. That is our reality. Given that reality, the most important thing is to design your product so that the server has no knowledge of who has verified keys or who has enabled a setting to see key change notifications. That way the server has no knowledge of who it can MITM without getting caught. I've been impressed with the level of care that WhatsApp has given to that requirement.

I think we should all remain open to ideas about how we can improve this UX within the limits a mass market product has to operate within, but that's very different from labeling this a "backdoor."

"Various activist groups" setup their own SMS service?

If all you want is for a few hundred people to be able to communicate, you don't need a federated protocol, you just need a VPN. It is much easier to use a centralized service and access it with a VPN than to use a rotating set of hosts across successively blocked federated services. At least when the VPN gets blocked you don't have to rediscover your entire social network when you start using a new one.

> Secondly it's not possible because their is not a finish list of providers. By the way 1) everybody should-could be its own provider 2) everybody must use its own domain name DNS to make addresses like greeting@name.

Just to be clear, this is never going to happen. We do not live in a world where computers are for "computer people" anymore. I've been running my own mail server since 1995, and I would not wish it on anyone.

Running my own mail server has not helped me with:

1) Metadata protection. Every email that I send or receive either has Google or Yahoo on the other end of it. Running my own mail server does not help me "own" my data at all.

2) Data protection. Federated protocols can almost never change (look at the history of IRC, XMPP, SMTP, HTTP). Email is stuck in time, which is why emails are still not encrypted. WhatsApp, on the other hand, had the freedom to deploy e2e encryption to over a billion people very quickly.

3) Censorship circumvention. Email is very easy to identify and filter using DPI. In a world where people are only doing host-based filtering, blocking 100 or 1000 hosts is no more difficult than blocking one. Whether or not there is "a finished list," if people can discover these services, so can the censors. It is much easier for the censors to add a single line to a block list than it is for people to switch to an entirely different provider with an entirely different namespace and try to rediscover all their friends.

If your idea is that every time a host gets blocked, everyone could move to a new one and somehow rediscover their entire social network, it would be way easier just to use a centralized service and access it with different VPNs as they are successively blocked instead. That would prevent you from having to rebuild your entire social network each time, but is still a terrible UX.