[HN Gopher] Ephemeral usernames safeguard privacy and make Signa...
___________________________________________________________________
Ephemeral usernames safeguard privacy and make Signal harder to
subpoena
Author : georgecmu
Score : 48 points
Date : 2024-03-04 14:24 UTC (8 hours ago)
(HTM) web link (theintercept.com)
(TXT) w3m dump (theintercept.com)
| dang wrote:
| Recent and related:
|
| _Keep your phone number private with Signal usernames_ -
| https://news.ycombinator.com/item?id=39444500 - Feb 2024 (872
| comments)
| johndough wrote:
| 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.
| contact9879 wrote:
| 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.
| lxgr wrote:
| > "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.
| evbogue wrote:
| 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.
|
| Maybe it's more complicated than that?
| alexwasserman wrote:
| 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.
| evbogue wrote:
| This is smarter than what I was imagining.
|
| 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?
| alexwasserman wrote:
| > I guess the hash still points at the phone number behind
| the scenes though?
|
| AFAIK, from the article, yes. But, you can create/delete
| that hash->phone mapping at will.
|
| Hence the recommendation to just create when required, or
| frequently change them if you're concerned.
|
| Or, use the QR code/link generation too. Those work the
| same way.
| Jabbles wrote:
| > 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?
| brnt wrote:
| So security is also a function of nick length?
| andrewjl wrote:
| I might be missing some background on the topic but is this a
| real-world example of a differential privacy[1] technique?
|
| [1]: https://privacytools.seas.harvard.edu/courses-educational-
| ma...
| mr_spothawk wrote:
| 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.
| dotty- wrote:
| What convinced you that they _are_ able to read the screen?
| bordercases wrote:
| 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."
| gryn wrote:
| you need to write it elsewhere so that can be used as a
| source for the wikipedia article.
| DaiPlusPlus wrote:
| Baseband chipsets.
|
| * For example, see
| https://news.ycombinator.com/item?id=10905937
|
| * 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
| pvg wrote:
| The comment you linked doesn't support your argument, it
| pretty much says the opposite.
|
| _walled-off from the rest of the phone (somehow) from what
| I can tell it looks like_
|
| A useful search term here is IOMMU, the major phone
| platforms have readily available documentation describing
| the architecture and its security goals.
___________________________________________________________________
(page generated 2024-03-04 23:01 UTC)