hardwarescope

That doesn't solve the case for when you get a new device or reinstall the app. Any keys you had are lost.

As a consequence of this choice, they store all of your unencrypted contacts (or unencrypted Wire contacts) on their servers. I don't think that's "additional privacy," compared to what Signal stores (nothing, it appears). Or it is at least not as simple a question as you make it seem.

If I remember correctly, as a consequence, they store all of your unencrypted contacts on their server, or at least all of your unencrypted Wire contacts on their server. Unlike Signal, which stores nothing about you other than the date your account was created. That may be the "complexity" you're not understanding, in this case.

I think this issue is more complicated than people realize. There are really only three options here:

1. Use the device's address book (phone numbers).

2. Use Facebook Connect (FB id).

3. Store the entire social graph on the server (custom identifiers).

I think #3 is what every messenger that offers non-phone identifiers does (Snapchat, Twitter, Telegram, Wire, Viber, etc).

The reason is simple: if someone does manage to create a social network by slowly discovering a bunch of usernames from their friends, but then they reinstall the app or get a new phone, it would be pretty unusable if that entire social graph was just... gone. It's bad enough to have to create this social graph from scratch, but to do it every time you reinstall, lose your phone, or get a new device?

The consequence is that many people advocating for this feature (or using other messengers because of it) probably don't understand what it is that they're really advocating for or getting themselves into.

Right now Signal is much more "private" than any other messenger, if you measure that by how much Signal knows about you (timestamp of account creation is the only thing iirc). By supporting a custom identifier, they would have to store your entire social graph, like other less private messengers.

> They assume that no side channel attacks will be mounted to determine the processes that occur in side the chip.

They do? 2/3rds of this blog post are about side channel attacks. The majority of the technical aspects of the article are about memory side channels in SGX and how they overcome those challenges. I haven't looked at the code yet, but it sounds as if they wrote it to be branchless so that attackers can't monitor control flow and so that memory access patterns don't leak anything.