
Technology preview: Private contact discovery for Signal - stablemap
https://signal.org/blog/private-contact-discovery/
======
ohthehugemanate
I cringed in anticipation of the HN comments on this one.

Cue the inevitable HN complaints that it's not perfect security, that you
still have to trust your CPU manufacturer, that the app permissions are too
invasive, that it uses phone numbers as identifiers, and that it runs on
Google play services.

Pull your head out of the trees and look at the forest: humanity desperately
needs privacy herd immunity, and you are taking the part of digital anti-
vaxxer.

Signal is one of the best options available for privacy: thoughtfully
architected by a leader in the field, reliable, with a good UI and reasonable
adoption, and genuinely open source. People NEED an alternative to Facebook
messenger, Facebook WhatsApp, closed source Viber and Telegram, and carrier
SMS. By refusing to recommend this extremely good, strong contender, you are
actively hurting the causes of privacy and open source. Stop being a digital
anti-vaxxer.

If you have complaints, submit a PR or make a compatible fork. But stop
discouraging people from protecting themselves.

Or alternatively: if you're going to be a digital anti-vaxxer, hit up
Facebook, Google, or the NSA to see if they'll send you a paycheck for it.
Because doing their jobs for free is just dumb.

~~~
snaky
> People NEED an alternative to Facebook messenger, Facebook WhatsApp, closed
> source Viber and Telegram

In a broad sense, they don't actually - being pretty much happy with all these
messengers.

~~~
dijit
Telegram is not closed source. Unless they mean the server.

And in terms of server, Signals is "open source" but you can't run one
yourself so how can you be sure really. :\

~~~
snaky
You're right, but I mean there's no messenger problem at all for vast majority
of the people, and privacy and security aren't features people tend to choose
over any other feature.

------
rdl
This is definitely interesting (and probably the first end-user-valuable SGX-
on-server application I've seen), but there are two issues IMO:

1) Intel SGX isn't really capable of resisting moderately serious physical
side channel attacks by someone with physical proximity or access to the
server. It's decent for low-value, or widely deployed apps where compromise of
a single instance only hurts once user, but for a central singular service,
less so. Inferior to, say, a conventional HSM with code run inside it. (SGX
would be great for client-side stuff, or for, say, a Tor or multi-server VPN
server array, which is something I worked on using TXT before.)

2) Intel's still a gatekeeper on what SGX applications can be meaningfully
distributed; to run in release-mode, you need a key signed by them, and to get
this requires a commercial agreement. If you run in debug or pre-release,
anyone with a debugger can pull keys.

If Intel were to fix the latter (even if it cost, say, $100 to get the signing
rights, or some non-discriminatory "you must do X, Y and not A, B" were
published), the former wouldn't be a deal-killer for some things. If the
server operator were a mostly-trusted third party (e.g. a cloud provider), and
the people writing and signing the code were never able to get physical access
to the hardware, it might work a lot better in most server threat models.

In Signal's particular case it's probably true that most Signal users trust
Moxie/OWS, and this is really about putting a much higher bar in place for
government compulsion to tamper with or disclose the contact info, so this is
a net win.

~~~
davidad_
From what I can tell, it's worse than just Intel being a gatekeeper - every
execution of "remote attestation" essentially relies upon the Intel
Attestation Service to actually perform verification (or at least as the
certificate authority). In a (hypothetical) world where all of Intel's
security features are owned by the US intelligence community, this type of
pattern seems like an awesome vector for deception ("false sense of
security"), where surveillance groups have a large supply of Intel-certified
EPID keys, which they can use to arbitrarily fool remote-attestation clients.
It's concerning to me that the OP article doesn't even mention Intel's highly
trusted role in this process.

------
mintplant
In case someone from Open WhisperSystems is reading: please add stickers.
Seriously, I know _so many_ people who are on Telegram just because of its
sticker system and won't consider anything without that feature. This comes up
again and again in online discussions where Signal is mentioned, and it hurts
to see all the care and effort the OWS team has put into providing real
security rejected out of hand because of it.

For the uninitiated, stickers are essentially a UI layer on top of image
sending. Each user has a collection of stickers which they can add images to.
This collection can be scrolled through quickly and any sticker can be sent to
a chat with a tap, like a sort of custom emoji. Other users who see a sticker
can add it to their own local collection by tapping on the sticker message. I
see no technical reason why this couldn't be built on top of the Signal
Protocol.

~~~
thinkloop
In case someone from Open WhisperSystems is reading: please do NOT add
stickers and junk to your clean and pretty system. I know a lot of people that
would leave the service if it turned into WeChat (including me). Stick to the
fundamental engineering of privacy as you are doing, and forget the gimmicks.

~~~
mintplant
I don't understand your motivation here. Every time I advocate using Signal I
run into a wall of "but it doesn't have stickers"; for those users, all the
privacy engineering is moot if the app doesn't fill their needs. Adding
another attachment type would do nothing to degrade your experience, nor would
it turn Signal into WeChat.

~~~
thinkloop
It does degrade it tho. There have to be ui elements to interact with them,
you need to be up to date on packs, a market needs to be implemented, maybe
payment needs to be introduced, the chat looks ugly full of graphics, etc.
Plus, every feature adds vectors of attack and things to maintain. I want this
to be a Snowden'ish tool for adults, not giffy. I'm not saying my preferences
are any better than yours, just highlighting that there are varied preferences
out there. If signal started looking like WeChat or Messenger I'd probably
leave.

~~~
mintplant
> you need to be up to date on packs, a market needs to be implemented, maybe
> payment needs to be introduced

You don't need any of that. Certainly none of that is present in Telegram. I
don't think you read my original comment in full.

> I want this to be a Snowden'ish tool for adults, not giffy.

Ironically Signal already has Giphy integration, but I suppose you didn't
notice because you don't use it—as would be the case with stickers.

------
nkobeissi
Signal is applying SGX secure enclaves to engineer a new contact discovery
server design. This is doubtlessly promising and innovative.

My only question is the following: what protection is there against the server
sending a correct remote attestation for the code being executed to the
client, and then, right after this attestation is validated, the server
rerouting the network pipe so that the contact list the client sends goes to a
different server running different, non-SGX code?

I ask that as a non-expert in SGX, so this might be something that has an
obvious answer.

Edited to add: Also, isn't it the case that verifying SGX remote attestations
requires phoning home to Intel? If that's the case here (and I'm not sure that
it is,) is Intel consequently able to build an IP address graph of Signal
users?

Edit 2: Matthew Green has provided a credible answer to my initial question:
[https://twitter.com/matthew_d_green/status/91274558241391820...](https://twitter.com/matthew_d_green/status/912745582413918208)

~~~
JoshTriplett
> My only question is the following: what protection is there against the
> server sending a correct remote attestation for the code being executed to
> the client, and then, right after this attestation is validated, the server
> rerouting the network pipe so that the contact list the client sends goes to
> a different server running different, non-SGX code?

The same thing that prevents contacting an HTTPS server and having your
connection re-routed after verifying the server certificate: the code
elsewhere (e.g. outside the enclave) doesn't have the keys.

~~~
nkobeissi
That makes sense. In this case I think it would be interesting to analyze the
state space for the network protocol involved.

------
Confiks
I don't really understand why this is an improvement on the existing
architecture.

In the current contact discovery implementation you need to fully trust the
server, namely the open source component that is the contact discovery
service.

In this proposed new implementation, you still have to trust the server; you
need to trust closed source processor hardware offering the Software Guard
Extensions.

Those extensions need necessarily be kept away from user control, because
otherwise you could pretend to attest a particular program, while actually
running a different program. So this encourages a centralization of trust into
a private key managed by processor manufacturers, which with server hardware
is primarily Intel.

(note that you fully need to trust the processor hardware in both cases; I'm
only arguing that this scheme possibly isn't an improvement)

Could anyone shed some light onto why this is an improvement, assuming you
don't trust the CPU manufacturer? This is kind of the premise of the article,
which notes that "more fundamentally for us, we simply don’t want people to
have to trust us", "that’s not what privacy is about".

~~~
permanentdecaf
I am by no means an SGX expert, but my understanding has been that it allows
you to shorten the "trust stack."

What you're referring to as "the server" is really a technology stack that
starts with the CPU hardware and extends to the service operator. Without SGX,
the trust stack probably looks something like: Intel, the OS, the VM, the
cloud provider (Amazon, Google, Microsoft), the server software, the server
operator.

Any of those points on the trust stack can be compromised by their principals
or by an attacker (for example, Amazon could choose to interfere with Signal,
or someone could hack Amazon and do the same). This is true for the OS, the
software, the service provider, and everything else in the stack. Users have
to trust all of those points, and additionally trust them not to be
compromised.

SGX shortens the trust stack all the way down to the CPU. It takes the OS, the
VM, the cloud provider, the service operator, and everything else out of the
equation. Clients no longer have to trust any of them, either to be honest or
to avoid compromise.

If trusting the CPU isn't acceptable to you, then that might be a bigger
problem than you realize, since all computing has to. If you'd rather put your
trust in AES, the problem is that you still have to trust the CPU to perform
AES the way you would like it to.

~~~
Confiks
I understand that you will have to trust the CPU to do any computation. In a
sense, it indeed shortens the 'trust stack', and as said in another comment
"now, you need only trust that Intel hasn't backdoored their hardware".

Maybe the main point should have been that that this scheme "encourages a
centralization of trust into a private key managed by processor
manufacturers". You might say that by integrating SGX mechanisms into your
security model, you create a set of 'feudal lords' [1] which can wield their
power over you.

A manufacturer may legitimately establish an enclave in you most trusted
hardware which you may not audit or even measure. And if that security model
becomes commonplace, for example when only allowing Widevine DRM inside SGX,
you eventually cannot use your self-chosen hardware, but will have to pick a
feudal lord.

[1]
[https://www.schneier.com/blog/archives/2013/06/more_on_feuda...](https://www.schneier.com/blog/archives/2013/06/more_on_feudal.html)

------
Asdfbla
Cool idea. When I read the title I thought that maybe they have discovered a
practical private information retrieval method or some oblivious transfer-
based method after all since their 2014 blog post (well, they kinda do
something like that with oblivious accesses to the RAM I guess), but using the
secure enclaves for running verifiable code seems like a very pragmatic and
creative solution too.

Granted, how secure those enclaves against state-level attackers also remains
to be seen (that recent attack on ARM Trustzone was pretty cool and
effective), but it surely is an improvement after all if you want some defense
in depth.

~~~
betterunix2
"practical private information retrieval"

For single-server PIR that is almost certainly an impossibility, since no
matter what sort of techniques you use you must scan the entire database on
every request (there may be some batching that can be done if several requests
are from the same user, but if you have millions of users that is not terribly
helpful). Multi-server PIR is already practical, but deployment is a bit
difficult: who will be the other server? How will you ensure the other
server's database is synchronized with yours?

------
scienhack
It is actually really neat how DRM tech is being reversed to benefit the
consumer and privacy for once!

Almost daily you read about yet another new "innocent" tech being exploited
and used for some corporate gain, taking advantage of the end-users. It's
refreshing to see it go the other way!

~~~
MichaelGG
Trusted computing, TPMs etc have always been about this scenario. It's just
the anti DRM crowd has some people that think the end user is always the
person sitting in front of the terminal, and there should never be a way to
reduce that person's access.

~~~
forapurpose
> It's just the anti DRM crowd has some people that think the end user is
> always the person sitting in front of the terminal, and there should never
> be a way to reduce that person's access.

That may be extreme (if it's not a strawman), but a major problem with TPM is
that there is no way to give control to the end-user, with the possible
exception of customers large enough to demand hardware customization.

------
canjobear
When will I be able to sign up without a phone number? The phone number
requirement is ridiculous and makes true anonymity incredibly difficult.

~~~
fattire
I don't think anonymity is one of Signal's design goals-- privacy is. But fwiw
there is also Wire Messenger, which looks to me to be a kind of Signal w/o the
phone # requirement (you can use an email address). It claims to use the
signal (axolotl double ratchet) algorithm for texts and video/audio uses
webrtc [https://wire.com/en/privacy/](https://wire.com/en/privacy/) with
encryption and it's GPL'd.

Beyond that I haven't used it so can't vouch for it. Anyone else got an
opinion on this Swiss app?

[https://play.google.com/store/apps/details?id=com.wire](https://play.google.com/store/apps/details?id=com.wire)

~~~
unhammer
Anonymity is not the only reason for usernames though: People sometimes switch
phone numbers, and some switch them more often than others (exchange/phd
students going to different countries/, moving to different countries for new
jobs etc).

Re: Wire, I tried it back when it had video chat (one of the few options
between iPhone and Android) and Signal didn't. But I found Wire to be too
unstable to be really usable. That is to say, my family members quickly got
annoyed and demanded I buy an iPhone. Signal video chat solved that issue :-)

------
bascule
> "It gets worse! The amount of encrypted RAM available to an enclave is
> limited to 128MB, which isn’t enough to store a large data set of registered
> users."

(So they used ORAM)

That's all very neat, but before a 128MB limit scares anyone off from playing
with SGX, it's no longer a limit.

As of the Linux SGX SDK v1.9, enclaves can be up to 64GB (31.75GB heap space
and 31.625GB buffers). The Baidu Rust SGX SDK supports this, for example:

[https://github.com/baidu/rust-sgx-
sdk#v020-release](https://github.com/baidu/rust-sgx-sdk#v020-release)

~~~
Ar-Curunir
Just to clarify, they didn't use ORAM, but designed a special algorithm for
their specific access pattern. In particular, they do a linear scan of the
entire user database, whereas ORAM would afford them polylogarithmic running
time.

------
sigil
So this looks better than the status quo, but is it really trustless? Couldn't
OWS still be compelled to drop something in that walks & talks like this
secure enclave, but enables remote collection of address books? It seems we've
just moved the trust down the stack into hardware.

Kinda depressed that we seem to have given up on the scalable Private Set
Intersection problem. It's a hard problem but an important one for privacy-
preserving social apps.

~~~
tptacek
The point of SGX is that the enclave is cryptographically verifiable. You
can't simply emulate the enclave's software and interface; you also have to
have the corresponding private key.

~~~
rightos
So is that key produced and provided by OWS? Or is it an Intel signed key?

Either way, it's far from trustless, but it does provide a benefit in that if
the initial setup was done correctly a compromise of OWS servers can no longer
result in leaked contact hashes.

~~~
hdhzy
The key is created by Intel during CPU manufacturing process. Of course it's
not trustless but it shortens the list of companies you have to trust.

Running remote software and attestation that it indeed is what you think
without trusting anyone can be... hard.

------
mbid
Wait, but the Signal Server does not need to store the contact graph, it
stores only (some of) its vertices. Moxie wants to make it hard for somebody
to learn about the edges from the way clients ask whether a vertex is in
signal's subgraph of the social graph.

Why don't the clients simply use Tor to retrieve information about the numbers
they're interested in? To avoid the server from using the time of the requests
to correlate them, you could let the clients sleep a random amount of time in
between requests, and sometimes request information they already have. Maybe
you could even ask volunteers to spam the server with nonsense requests, so
that the genuine requests are drowned in this noise.

------
hdhzy
For anyone interested in the design and functioning of Intel's security
components there is a book freely available by one to the lead engineers here:
[https://link.springer.com/book/10.1007/978-1-4302-6572-6](https://link.springer.com/book/10.1007/978-1-4302-6572-6)

~~~
forapurpose
Agreed, Platform Embedded Security Technology Revealed by Xiaoyu Ruan should
be the first thing anyone reads about it. Much else will become irrelevant or
be revealed as ignorant.

------
mtgx
Would AMD EPYC's encrypted memory also be of use here?

[https://semiaccurate.com/2017/06/22/amds-epyc-major-
advance-...](https://semiaccurate.com/2017/06/22/amds-epyc-major-advance-
security/)

Also, it seems to have its own flaws, just like SGX:

[https://www.theregister.co.uk/2016/12/08/amd_virty_encryptio...](https://www.theregister.co.uk/2016/12/08/amd_virty_encryption_not_quite_there_boffins/)

------
twic
I wondered what it was written in, so i clicked on the Github language details
bar. Prolog 1.4%! What could it be using Prolog for?

[https://github.com/WhisperSystems/ContactDiscoveryService/se...](https://github.com/WhisperSystems/ContactDiscoveryService/search?l=prolog)

Fooled again!

------
scienhack
There's a typo in the link to the Signal-Service (server) source code
repository, the actual link is: [https://github.com/whispersystems/Signal-
Server](https://github.com/whispersystems/Signal-Server)

------
elijahwright
This is totally awesome technology, and it sounds like it is well designed and
scalable. AWESOME.

------
nobodyorother
As always, Moxie impresses. :)

------
lifeisstillgood
In case someone from Open WhisperSystems is listening, please could you
implement a UI plugin environment and allow OSS developers to produce
"keyboards" for anyone to implement their own preferred features - stickers or
classic or neon-80s-retro Of course that's probably waaay more work than the
secure enclave was but its cheap to ask :-)

Ok so that is a bit tongue in cheek but just how much of signal is OSS and how
much can the community contribute (it seems that adding gif transparency would
be one of those items - but really I don't "get" the requirements.

------
Abishek_Muthian
While they are at it, Signal should improve SMS integration capabilities as
well. If Signal is used as default SMS client (Which IMO is a good use case),
the search implementation is by far the worst search implementation ever on
the application. Searching local SMS DB shouldn’t be security concern,
Android’s SearchView should basically do it by itself. I haven’t looked
through their code yet, there’s minor possibility that they have ditched some
default android frameworks for added security.

~~~
unhammer
> Searching local SMS DB shouldn’t be security concern

Actually, it is, since Signal encrypts your messages and only decrypts them
when the app is "open". See
[http://esl.cs.brown.edu/blog/signal/](http://esl.cs.brown.edu/blog/signal/)
and See [https://github.com/WhisperSystems/Signal-
Android/issues/1232...](https://github.com/WhisperSystems/Signal-
Android/issues/1232#issuecomment-299583255)

------
captainmuon
Why don't they just use hashed _pairs_ of telefone numbers for discovery? I'm
more worried that they have my whole telefone contact list, than that they
know with whom I am chatting. They could probably find out the latter by
manipulating the client anyway.

Also, don't they neccessarily have a mapping of telefone number -> IP address?
They could just show all contacts, and attempt to send if you write to
somebody. If they want to only show mutuals, use the hashed pairs to get the
IP address (or ID, or status, or whatever they need).

I don't want to be too negative, but this seems to me like an unnecessary
complex solution to a problem I don't have. I'd rather have the option to
register anonymously, or to use alternative clients and servers.

Also, as a layperson, _they could be making all of this up and I would never
be able to tell_. Somebody could have bought or coerced a couple of security
experts that I know and trust, and I would never be able to find out. So, in a
sense, a dumber and less secure solution might actually be better...

------
aboodman
Super interesting.

A related problem I think about frequently is this: how do users know/trust
the client software they are running works as they expect?

I wonder if there is some way to use SGX to enhance trust in the client side
too.

------
gok
Cool. It'd be nice if the app used the secure enclave on phones too.

------
andreif
Can I use Signal on iOS without obligatory access to Contacts already?

~~~
ali_af
Yes, they rolled this out in a relatively recent update.

------
skybrian
Even if Signal's server can't do it, what's to prevent a client from using a
really large list of contacts? (Say, millions of contacts captured via a
security leak?)

~~~
kijiki
Assuming OWS doesn't rate limit, all that would do is let you tell what phone
#s use signal. Which is slightly sensitive info, but radically less so than
"who is communicating with whom", which is what the older method could leak.

~~~
skybrian
Good point and I agree it's less sensitive.

But to avoid minimizing it, there is a scenario I've heard where it matters:
crazy ex-boyfriend discovers you're using a new messaging service, just
because he still has your phone number in his contacts.

Ideally, nobody should know you're using a new messaging service unless you've
given explicit consent to share that info with them.

------
thinkloop
> The obvious problem with this method is that the hash of a user identifier
> can almost always be inverted. Regardless of whether the identifier is a
> phone number, a user name, or an email address, the “keyspace” of all
> possible identifiers is too small.

What does "inverted" mean here? And why is the keyspace too small? And how do
these problems relate to not trusting the server? The problem definition and
proposed solution don't seem to match to me, even though what they have solved
is cool.

~~~
chrissnell
Take every possible 10-digit U.S. phone number, for example, and perform a
SHA-256 hash on each. Put those phone numbers and their hashes in a lookup
table. Now, when a hashed phone number comes in from an anonymous user, look
it up in that table and you now know the actual phone number.

~~~
abovemypaygrade
I'm not an expert, so bear with me. Could this be thwarted by, say, having
Signal add a random salt to every registering number and then advertising the
hash of (number)+(random salt) as the final contact, invisible to the end
user? Or would that involve Signal maintaining too much information on their
users? If that's the case, I could see that being a problem.

~~~
azdle
The problem with salting the hashes is that they then become useless for
contact discovery. The only way I can think of to make it work would require
sharing the salt with people trying to find you, but then at that point you
just share a real user identifier and short-circuit the whole process
happening here.

~~~
abovemypaygrade
The way I was initially picturing it would involve Signal keeping track of the
salt they assigned to the contact number, with that specific salt maybe
'expiring' after a certain number of days (to get rid of salts where someone
registered with Signal, didn't like it, and never registered again). After
thinking about it some more, I realized that this would probably lead OWS to
collecting big lists of registered users and their contact patterns, which
goes against their policy of trying to retain as little data as possible.

------
nullc
It doesn't say a word about running inside SGX without the insecure developer
mode... or about the use of SGX meaning they're stuck with hardware which has
the highly questionable ME layer.

SGX as an additive layer for things you can't make strongly private is
interesting... though I wonder if it wouldn't have first made sense to
implement a private intersection so that signal users wouldn't have to send
numbers that are guaranteed to have no hits.

~~~
jerheinze
You'll get downvoted to oblivion here just for mentioning the ME.

By the way for those unconvinced that this is a serious issue just lookup this
one from 5 days ago:
[https://news.ycombinator.com/item?id=15298833](https://news.ycombinator.com/item?id=15298833)

------
veeragoni
completely unrelated. I looked at 3 key words. "contact", "discovery" and
"signal". and then i added 4th key word "NASA". and thinking NASA Discovery
made a private(alien) contact via a signal.! what am I thinking!!!

------
Spearchucker
Started reading this article and it starts off ok and then gets all technical
and I got bored.

Because, regardless of how good that solution is technically, I cannot
understand what's so difficult about simply making contact discovery optional.
At the user's discretion. Like you'd exchange PGP certificates.

Why, and how did user control and consent become so hard?

------
DINKDINK
The security assumptions that SGX is built on are flawed. They assume that no
side channel attacks will be mounted to determine the processes that occur in
side the chip. You can even build software to do side channel analysis on the
physical chip:

7:16:26 Daniel Gruss / Michael Schwarz - Cache Attacks on SGX
[https://youtu.be/eCE2OzKIab8?t=26193](https://youtu.be/eCE2OzKIab8?t=26193)

~~~
hardwarescope
> 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.

~~~
DINKDINK
You're correct. My original statement was wrong regarding Intel's assumption.
The principle issue is that developers shouldn't assume that processes that
occur in SGX are obfuscated in any sense because you can build SGX sidechannel
detection within software that runs inside the enclave The lecture I pointed
to shows an example of this attack.

------
jerheinze
This is much better than the current state but there's still the issue of
Intel's Management Engine (ME) that clings on those chips and that has access
to pretty much everything...

------
samstave
> __ _clients will be able to efficiently and scalably determine whether the
> contacts in their address book are Signal users without revealing the
> contacts in their address book to the Signal service._ __

This should be the fucking defacto standard!

We really need Privacy-as-a-service and security-as-a-service

~~~
daeken
> We really need Privacy-as-a-service and security-as-a-service

We can provide food-as-a-service, but we can't provide digestion-as-a-service.
Which is to say, we can provide many useful services but privacy and security
are things that can't be outsourced, just like you can't hire someone to
digest your food for you. They require deep integration and planning, and
they're difficult to pull off in the best of cases. Trying to service-ify them
is just asking for pain.

~~~
samstave
hmm... I like your insight - thank you.

------
zeveb
> There are a range of options that don’t work, like using bloom filters,
> encrypted bloom filters, sharded bloom filters, private information
> retrieval, or private set intersection.

He just takes as a given that private set intersection doesn't work, and in
the original 2014 document[0] writes, 'There are cryptographic protocols for
performing privacy-preserving set intersections, but they generally involve
transmitting something which represents the full set of both parties, which is
a non-starter when one of the sets contains at least 10 million records.' This
is just flat-out _wrong_ though: the sets to be intersected are the contacts
of two users, not Signal's registered users and the contacts of one user.

[0] [https://signal.org/blog/contact-
discovery/](https://signal.org/blog/contact-discovery/)

~~~
bascule
Who are the two users in this case? How did they discover each other? From the
OP:

> "Very few people want to install a communication app, open the compose
> screen for the first time, and be met by an empty list of who they can
> communicate with."

Signal needs to bootstrap itself automatically in order to solve this problem.
Can you explain how two users doing a private set intersection of their
contacts solves this bootstrapping problem?

~~~
zeveb
The two users are two folks who wish to communicate who hold their phones
back-to-back and let NFC validate who they each are. Both parties are now able
to perform a private set intersection to find people whom they know in common
who also use Signal, and are able to then use private set intersection with
each of _those_ people to find more.

The idea is that users bootstrap via the social graph of folks they physically
know (or, of course, they could fall back to manually entering keys, for
experts). Users place their trust in one another, rather than in the server.

~~~
bascule
So you want to completely punt on the "open the app to an empty contact list"
problem and force people to perform what's effectively a GPG keysigning
party...

Call me crazy, but I think that'd be a bad user experience of the sort that
held back encrypted messaging for decades.

~~~
tveita
They could at least allow it. Signal is the odd one out among secure messenger
apps for having no way of adding a contact in a face to face setting without
uploading all your contacts to their servers.

~~~
bascule
Signal allows you to send messages to numbers which are not in your contacts,
which by definition implies it can be done without uploading your contacts to
your servers.

In person you can also exchange "safety numbers" via QR code which provides
key verification.

------
kuschku
Considering that Signal is advertised (with Snowden as face) for people who
need privacy from governments (including the US government), I am doubtful if
this is useful for the advertised purpose. (For normal users this is already
overkill, of course).

Even if we assume the NSA has no backdoors in the secure enclave, there have
been countless demonstrations against secure enclaves in today’s real-world
processors on conferences.

Additionally, the same problem applies here that has been used before to break
Google’s SafetyNet solution (which does the same, but the opposite way around,
to ensure the client is running, and can’t prevent tracking): You can simply
have two systems, and for attestation you question the true device, but for
actual code execution you run it on an emulated one, where you can extract all
data. Alternatively, you can still emulate this system completely and
circumvent it via that path, too.

The only way to truly verify SGX is by having a signature of the processor
manufacturer – but in that case, you still don’t get protection from the NSA,
or the processor manufacturer.

~~~
cvwright
This attitude is a big reason why doing constructive work in security is hard.

Yes, there are huge challenges and lots of different attack vectors. No, that
doesn't invalidate the progress that's made when someone invests a lot of time
and effort to solve 80% of an extremely difficult problem.

Sometimes it feels like you could solve world hunger and world peace, but
unless you also gave everyone a puppy, half of the security community would
still complain.

(And then there's always someone who wanted a kitten instead of a puppy...)

~~~
kuschku
Well, it is a major step – but Moxie always sells his solutions, even if
they’re just a puppy, as solutions for world hunger.

As I mentioned, advertising with Snowden leads to a promise that Signal can
not fulfill. Not even with this.

But, you know, there is already a solution for all the issues here: Don’t use
phone numbers, use usernames! As it turns out, that is far more private and
secure.

~~~
cvwright
First, you're not wrong about Signal being insufficient against nation state
adversaries. The Grugq has a nice talk about opsec that I can't seem to find
atm. He sums up the issues with Signal nicely in a Medium article. [1]

That said, this particular development is a lot more than a puppy. It's at
least a full grown, happy, friendly Golden Retriever who's already house
trained and knows how to fetch your slippers.

They've removed one of the biggest remaining weaknesses of their system, where
they still required the users to "just trust" them. That's pretty cool,
especially for the vast majority of us whose primary adversaries are smaller
or profit-driven.

[1] [https://medium.com/@thegrugq/signal-intelligence-free-for-
al...](https://medium.com/@thegrugq/signal-intelligence-free-for-
all-5993c2f72f90)

~~~
indiv0
Are you by any chance referring to this [0] talk?

[0]:
[https://www.youtube.com/watch?v=9XaYdCdwiWU](https://www.youtube.com/watch?v=9XaYdCdwiWU)

------
mtgx
In a previous comment on that Moxie interview story posted here, I complained
that OWS doesn't do a great job of building a community or making it excited
about its product.

Something I forgot to add then: why doesn't Signal have a public roadmap?
Almost all open source projects that I've seen have one. Why? Because they are
typically community-driven and developed projects and because they rely on the
community to buy into the project's future, and give a hand developing it or
funding it.

But we don't see that with Signal. Why does the roadmap have to be secret? I'm
not even talking about deadlines and schedules. Just decide on a bunch of
features and present them on the site. You may get more volunteers willing to
help if they see an interesting new feature popping up on the horizon.

Also, please do something about the call routing speed. It takes too long for
a call to connect. If it's a funding issue, then say so. In fact, it wouldn't
hurt to have "crowdfunding campaigns" for the various features on the roadmap.
Show progress lines and whatnot, and then start developing that feature when
it's fully funded, etc

The whole project needs to become more open towards the community and less
"we'll just be here in our basement for the next 2 years developing an awesome
secret feature."

~~~
snthd
previous comment of parent -
[https://news.ycombinator.com/item?id=15282210](https://news.ycombinator.com/item?id=15282210)

