It sounds great and well thought through, as always for Signal. I wonder how they handle two potential security holes:
1. Imagine a journalist publicizes a username for a long time, then changes it. The old username would persist in data stores online and in address books, and would be used in error. An attacker could acquire the old username and impersonate the journalist. Perhaps a solution is to make at least some usernames, possibly at the user's option, non-reusable.
2. One strength of Signal is not only do they not collect much user data, they can't. Under some court order, they could retain the hashed usernames.
1. You use the username to connect to Bob.smith.123. This creates a conversation with the user who currently has that username.
2. You can’t see that user’s username, just “Bob Smith” or their name in your contacts, so them changing or deleting their username isn’t even visible to you. Your conversation is unaffected.
3. If, in the future, you add username Bob.smith.123 again, it may be a different person.
I think the name is a mistake, I’d have called it an “add code” or something. Clearer to explain a new thing than to say a word that means a dozen wrong things and always be correcting everybody.
I agreed with your suggestion. Username is a poor choice.
I’ll go ahead and repeat that I have said in previous comments:
> or their name in your contacts
This is a huge mistake on Signal’s part — even if both have saved each other’s numbers the username-to-username connection should not mix with any other “normal conversation” ever!!
They should also not try to show the ser “name” either - some other name or a named conversation.
I'm trying to imagine the code behind this ephemeral username strategy. I imagine a kv store under Signal's control where you are allowed to set a key "username23" and a value "773-510-8601" and the cool thing is I can make a lot of keys that point at my phone number.
It says the username values are hashed, so they can't actually see them. It just stores the hash.
So, you tell someone my username is "ABC", their Signal client hashes it and looks up the account and messages you.
Signal can keep the mapping of hash to number, but doesn't care about the plaintext value of the username.
After the person has messaged you/added you, then you can delete the mapping, at that point they're connected to you, even if they don't see your metadata like phone number.
Then, from the article, others can reuse the username too.
> that’s all Signal turned over because that’s all Signal itself had access to. As Signal’s website puts it, “It’s impossible to turn over data that we never had access to in the first place.”
Note that this is no longer the case and signal stores a lot of data in the cloud now (name, phone number, photo, and your contacts)
> It says the username values are hashed, so they can't actually see them.
Even if I didn't already believe that Signal was compromised this wouldn't inspire much confidence. When they're keeping your phone number in the cloud forever (along with your contacts) not having a username doesn't mean a whole lot. Phone numbers are trivial to match up to a name/address/credit card/billing address/location.
I don't blame you for not knowing about it. They were extremely unclear about it at the time it was implemented, and to this day they've refused to update their privacy policy the very first sentence of which is a lie. Make of that what you will.
Even if we forgive them for keeping/using phone numbers, all of the other data collection is entirely unnecessary and it's also exactly the kind of data the feds have been asking them to hand over.
IIRC it works something like this: You can use a password of whatever complexity you like. Signal adds a PIN to enhance the password's complexity, just in case a user might choose an insecure one.
They did change it to accept longer passwords while still calling it a PIN which most people associate with a 4 digit number and allowing short PINs. While it's good to increase the complexity on their end, the justification for all of this is so that users can restore their settings on a new device. That means that in the worst case the data is more secure on the server, but someone acting as if they are restoring their settings will only have to enter the weak password to get the data.
So I come up with a username, on my client side it is hashed and Signal's kv store is checked to make sure no one claimed the hash yet.
Next I tell the username to my peer via some other secure channel or IRL and their client sends the hashed username to this kv store to do the usual things.
I guess the hash still points at the phone number behind the scenes though?
> Then, from the article, others can reuse the username too.
This sounds like a potential security hole. You have to be sure that your contact hasn't reset their username as you add them. Or maybe that's what the username registration timestamp is for? To show that this username has been in use by the same person for a while?
It would seem to make sense for a persistant attacker to collect well-publicized usernames when the original owner changes them.
Imagine a journalist who publicizes a username, then changes it. The original username would linger on the Internet, in people's address books, etc. A persistant attacker might acquire it, and snap up contacts as they come in.
Maybe Signal should have made usernames non-reusable, at least as an option. They still could dissociate the username from the phone number when the user 'deletest' it. The deleted username would just be shifted to the null user.
No, ephemeral usernames are not differential privacy. Differential privacy is repeatedly sampling a database through a differentially-private interface which returns data samples which are either real or fake. The mean and variance of the sampled data match the true mean and variance of the dataset according to a system-defined epsilon value. The end user isn't able to know if any given piece of data is real or fake.
Won't be going back to Signal anytime soon, too secure (lost important stuff due to their poorly designed backup system) for me. But this has always been why I claimed Signal can't be trusted and I'm glad I can't say that anymore.
Assuming of course that you can use Signal on the desktop with usernames without ever involving a mobile app. If they haven't fixed that then I'm leaving them in the untrusted bin.
I did. I can't secure mobile phones due to their design and available OS. And the whole phone number thing is too similar to how the NSA encouraged PGP email encryption because of the metadata. Phone numbers identify you even better than your finger print, gps and ip combined in some situations. You start sharing sensitive stuff more because everyone telld you how great Signal is despite that.
I think wire and briar are promising but convincing people to use them is hard. I just use imessage on mobile and arrange more secure non-phone means of communication if needed.
All this would not be necessary if Signal did not collect phone numbers at all.
The usual excuse is that they need phone numbers to combat spam, but that is only because they allow arbitrary contact requests form random people. It would be easy to imagine accounts without arbitrary contact permission. Contact requests could still be exchanged by e.g. meeting offline in person or with time-limited friend request codes.
The article included comments from Signal devs and Whittaker about this exact issue. There are valid reasons that Signal does not want to stop using phone numbers.
> “You reach a threshold where you’re actually reducing privacy,” Whittaker said. She gave an example of a person who faces severe threats and normally maintains vigilance but whose mother is only on WhatsApp because she can’t figure out the numberless Signal. The high-threat person would be stuck using the less secure option more often.
How does that make sense? Signal just made phone numbers for contact discovery optional, in which case this person still couldn't find their mother, even though Signal has their number on file.
What people are asking for is for phone numbers to be optional for account creation and identification. Everybody that wants to could still provide (and verify) their phone number for contact discovery, and this could even remain the default for non-sophisticated users as the one described above.
So that seems more like a retroactive justification for an early design choice (Signal was originally TextSecure and used SMS as a transport layer, so making numbers the primary key made total sense back then). The only thing that still makes sense to me today is spam prevention:
> Requiring phone numbers also makes it considerably harder for spammers to abuse Signal. “The existence of a handful of small apps that don’t really have a large scale of users, that don’t require phone numbers, I don’t think is proof that it’s actually workable for a large-scale app,” Whittaker said.
One possible solution could be to tie numberless account creation to a nominal donation payment: Still not great, but spam prevention is unfortunately not free to Signal either.
It's probably also related to them not wanting to make Signal selfhostable. The server (and client) code is open source[0] but is reliant on an external SMS service to be self-deployed (as well as AWS for file storage, GCM and APN for push notifs but those aren't nearly as much of a barrier; AWS has numerous FOSS reimplementations while for GCM you can use ntfy), something which Signal devs have stated they don't want to happen (since providing libsignal implementations is, as far as I understand, part of how Signal makes money).
SMS is afaik the only real barrier they have to preventing that.
[0]: As in, AGPL and effectively a source dump with no instructions.
I remain unconvinced that phone manufacturers are unable to read the screen. Username obscurity is neat for p2p privacy, but does nothing against "the cops" if you're doing something they don't want you to.
Yeah. If you've come to the attention of the wrong sort of "the cops", you're fucked.
"Basically, you’re either dealing with Mossad or not-Mossad. If your adversary is not-Mossad, then you’ll probably be fine if you pick a good password and don’t respond to emails from ChEaPestPAiNPi11s@ virus-basket.biz.ru. If your adversary is the Mossad, YOU’RE GONNA DIE AND THERE’S NOTHING THAT YOU CAN DO ABOUT IT." -- https://www.usenix.org/system/files/1401_08-12_mickens.pdf
There's a lot of humour in that article, but some cold hard truth as well.
After an intelligence agency has knocked on your door to tell you just how interesting your online comments are and serve you legal paperwork, arguments like this suddenly become hollow.
While this advice suggests I should just give up, that's not a practical option.
I'm fortunate enough to have never had that knock on my door, but I'm certain I'm on several lists.
You don't need to "give up", you need to work out what stuff you do or talk about that "Mossad" isn't really interested in, and be much more circumspect about where and who you talk with about anything that they might be interested in.
Sadly, for anybody without my kind of middle aged white dude privilege, that's almost certainly a "chilling effect".
>I'm fortunate enough to have never had that knock on my door
What's the most subversive thing you've ever posted, repeatedly, with a large number of people seeing it? Chances are that it's not being "fortunate" that keeps you save but you simply aren't of interest to them.
In Communist China, you're perfectly safe as long as you aren't the "wrong" ethnicity and never prominently criticize the Party. In democratic country X, despite people getting to vote, it's not fundamentally different.
Nothing, practically speaking, can keep you safe from your phone.
If your adversary has access to your phone, directly, then encryption will not help (practically speaking - got to keep saying that because heroic efforts can be expended). If that adversary is the phone manufacturer (a) you are screwed and (b) the manufacturer is taking a huge business risk
Point is using Signal your messages and secrets cannot be found on a server over which you have no control. You do have control over your phone. You can switch to a more reputable manufacturer, you can keep it away from your adversary
> If your adversary has access to your phone, directly, then encryption will not help
One way to express it: The phone isn't much use unless you have access to the data. If you can access it, so can adversaries with access to your phone.
Convinced is a strong word, but phones are typically running code that is not user controlled in an environment where they are always expected to be connected to the internet.
Given the amount of spying that has been revealed (a lot of it seeming to be superficially illegal) it seems reasonable to assume that phones are compromised in all manner of ways unless proven otherwise. I'd prefer to be pleasantly surprised.
Anything that makes it more expensive for the government to read someone's communications is a bonus. Ideally panopticon states will remain uneconomic.
* Mobile-phone baseband chipsets are proprietary and secret a.f. and part of that is down to the carrier's insistence.
* Baseband chipsets run software that the carrier ships OTA to the phone.
* While baseband chipsets are ostensibly part of the wireless modem and meant to simply provide a service to the rest of the phone it looks like they generally have some form of access to the phone's main memory bus (just like any other PCIe device in a PC) and so could read the framebuffer (assuming it's backed in RAM at all) - or at least the back-buffers of the screens of running applications.
* Even 6-7 years ago, there existed definite causes for concern in (at least) the 32-bit version of iOS - but I can't find any hard evidence that the baseband chip in Apple Silicon-era phones wouldn't have at least some access. See https://github.com/userlandkernel/baseband-research
Having nothing at all to go by except for the platform's documentation and if we're lucky a pinky promise that they'd never backdoor their chips or devices if the state strong armed them into it seems to require a whole lot of faith. It'd be a lot nicer to have verifiable/auditable hardware and software so that we could be reasonably confident what it was capable of and could see exactly what it was doing instead of having to trust the black box.
You've given up the argument at this point. If you don't trust your phone's manufacturer not to backdoor their own chips, the baseband doesn't matter. If you're concerned about the Qualcomm baseband chips in an iPhone, you're talking about what is probably (depending on your phone) just a USB peripheral.
The baseband parts here are not, as message board C.W. would have it, top secret unknowable wizard hardware. You can get the part numbers and look them up.
There's a lot of weird mythology about these modem parts. The thread you linked to included someone claiming that basebands were DMA'ing into host memory --- you couldn't even do DMA over the HSIC USB the parts were using. Like, it wasn't even physically possible.
(I have no idea what a 5G Snapdragon Xwhatever can do today, but I assure you that Apple's security team does).
Having nothing at all to go by except for the platform's documentation and if we're lucky a pinky promise
We have way, way, way more than that. Both the GP and you are arguing about the security deficiencies of modern phones as you've imagined them, rather than as they are but that gap is trivial to close with relatively little reading.
> you are arguing about the security deficiencies of modern phones as you've imagined them, rather than as they are
I appreciate the strength of your conviction - but I'm not an phone industry insider, and have no access to the kinds of reading-material I assume you're pointing to - for example, Qualcomm put their docs behind a verify-your-employer-wall (which is outrageous): https://www.qualcomm.com/products/technology/modems/snapdrag...
...if Qualcomm's attitude towards openness and transparency is representative of the mobile comms industry in general then they have little hope of correcting any misinformation or misconceptions other technology folk like ourselves might have, let alone the general public.
No, this doesn't require access to internal documentation of anything, just googling a little. Like the sibling comment points out, the whole baseband thing is a bit of a messageboard trope and has been for about decade. This is one of these things you can sort of guess from first principles! I.e. how likely is it that this well-known problem (the potential security implications of DMA/memory mapped peripherals) has remained completely unmitigated and unaddressed by smartphone designers for 10+ years?
I can highlight text on the application switching screen (swipe up on android, press and hold over text on any of the applications in that view, you can highlight text that's otherwise not highlightable)
Someone should write a Wikipedia article on a glibly labeled law to the effect of, "any opportunity for forensic information to be exploited, will be done so."
OS level and apps can record the screen. With root access the State or someone who knows the triggers could issue a capture and store to a remote site without user knowledge.
A GPS transponder with microphone and camera under the control of billionaires seems like a mistake
It's not this binary. Remote compromise of phones with 0 days is expensive and risky. Phones aren't commonly believed to have purpouse built stable backdoors allowing screen recording for cops.
1. Imagine a journalist publicizes a username for a long time, then changes it. The old username would persist in data stores online and in address books, and would be used in error. An attacker could acquire the old username and impersonate the journalist. Perhaps a solution is to make at least some usernames, possibly at the user's option, non-reusable.
2. One strength of Signal is not only do they not collect much user data, they can't. Under some court order, they could retain the hashed usernames.