Post by Jani Monoses
What about the possibility of lazy contact discovery?
For those opting out of having their address book used to discover
the contacts intersection, allow picking contacts directly from the
address book when messaging. Unless the server returns a no such user
error (which happens now if you try messaging a number) the session
This may complicate the UX, risk having users opt out
uninitentionally without knowing the implications and would not be in
line with the 'as few options as possible' policy.
I think this could be done with minimal changes on Android and small
changes on iOS.
For Android, the flow goes like this:
- Hit the FAB (pencil button)
- Select a contact
- Type your message
- During this time, your phone queries Signal's servers about this
number. While this is happening, there is a spinner where the send icon
usually is, and you are unable to send.
- If the number is registered, spinner resolves into the blue,
encrypted send button. If not, it resolves into the gray button for sms.
For iOS, the difference is that now all of your contacts show when
trying to compose a message, but you're simply unable to send a message
to some contacts. I'm not familiar with iOS, but I assume there's a way
to link to the iMessage app? We could use that so that the screen "You
can't message this contact because they're not on SIgnal" can link to
iMessage with an invite link.
My analysis of this approach is:
- Potentially far more requests.
- Should be offset by each request being smaller and far fewer
numbers being transmitted.
- Signal servers could receive additional metadata about how often you
correspond with a given contact, even if you're just sending them sms.
- But, you already trust OWS with that metadata for messages you send
through Signal. And of course there's the huge gain that you don't need
to share your whole social graph.
- Clients could possibly obfuscate some of this data by bundling some
less frequent contacts or random numbers each time a request is made.
- Potentially worse UX, if you have to sit there waiting to know if you
can message someone.
- There is a purely technical side: How long does it take for a
request to return?
- There's also the element of "I thought you (Signal) said I could
message them, but now you're telling me I can't?!".
- While this is certainly a bit annoying, it's also not
substantially different from other ubiquitous messaging systems. If I
send you an sms, but I have the wrong number or your phone is out of
service, delivery may fail. Likewise with email.
- Can't give notifications that a contact has joined Signal without
messaging them, first.
- There's no way around this one. It is a bit anti-network effect.
Not to mention, it's fun seeing people join Signal for reasons other
than me bugging them to :P.
I conclude that it would be reasonable to offer this feature either as
an opt-in or opt-out. We can re-purpose the "New contacts notification"
setting to also control whether your full contacts are sent to the
server, so there's little additional complexity added.
If there's anything I'm overlooking, please step in and point it out!
Post by Jani Monoses
On Tue, Feb 21, 2017 at 12:09 PM, Stefan Kamphausen
Post by Stefan Kamphausen
Post by Moxie Marlinspike Post by Stefan Kamphausen
Would the space spanned by both numbers be large enough to protect
against pre-calculated hash tables?
I don't think so. Seems like you're thinking about it in terms of
"Here's a hash token, what numbers does it correspond to?" But the
question you're actually worried about is "Here's Stefan's phone number,
who are his contacts?" At that point, it's 10^10 again. Just iterate
over the set of all possible phone numbers once, and you've got your
matches. Narrow your query down a region and it's even smaller.
If I understand that correctly, the approach may protect against
pre-calculated tables. But if it does or does not is irrelevant,
because you can just iterate over all possible contact numbers (and
the combined hashes) when needed. That means, calculating 10^10
hashes is considered doable, even with bcrypt or other slower
hashing algorithms, that can not be made too slow, because they need
to be fast enough to lookup possible contacts.
So, I was starting off the wrong question.
I guess, that was the crushing I was waiting for. Thanks for taking
the time to consider this.