Technology preview: Private contact discovery for Signal - <AUTHOR> https://signal.org/blog/private-contact-discovery/ <comment><USER3> 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.

<comment><USER4> > 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.

<comment><USER5> 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. :\

<comment><USER4> 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.

</comment></comment></comment></comment><comment><USER6> 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.

<comment><USER7> From what I can tell, it's worse than just Intel being a gatekeeper - <USER2> 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.

</comment></comment><comment><USER8> 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.

<comment><USER9> 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.

<comment><USER8> 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.

<comment><USER9> 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.

<comment><USER8> > 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.

</comment></comment></comment></comment></comment><comment><USER10> 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)

<comment><USER11> > 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.

<comment><USER10> That makes sense. In this case I think it would be interesting to analyze the state space for the network protocol involved.

</comment></comment></comment><comment><USER12> 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".

<comment><USER13> 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.

<comment><USER12> 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)

</comment></comment></comment><comment><USER14> 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.

<comment><USER15> "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?

</comment></comment><comment><USER16> 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!

<comment><USER17> 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.

<comment><USER18> > 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.

</comment></comment></comment><comment><USER19> When will I be able to sign up without a phone number? The phone number requirement is ridiculous and makes true anonymity incredibly difficult.

<comment><USER20> 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)

<comment><USER21> 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 :-)

</comment></comment></comment><comment><USER22> > "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)

<comment> 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.

</comment></comment><comment><USER23> 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.

<comment><USER24> 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.

<comment><USER25> 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.

<comment><USER26> 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.

</comment></comment></comment></comment><comment><USER27> 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.

</comment><comment><USER26> 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)

<comment><USER18> 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.

</comment></comment><comment><USER28> 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/)

</comment><comment><USER29> 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!

</comment><comment><USER16> 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)

</comment><comment><USER30> This is totally awesome technology, and it sounds like it is well designed and scalable. AWESOME.

</comment><comment><USER31> As always, Moxie impresses. :)

</comment><comment><USER32> 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.

</comment><comment><USER33> 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.

<comment><USER21> > 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)

</comment></comment><comment><USER34> 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...

</comment><comment><USER35> 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.

</comment><comment><USER36> Cool. It'd be nice if the app used the secure enclave on phones too.

</comment><comment><USER37> Can I use Signal on iOS without obligatory access to Contacts already?

<comment><USER38> Yes, they rolled this out in a relatively recent update.

</comment></comment><comment><USER39> 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?)

<comment><USER40> 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.

<comment><USER39> 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.

</comment></comment></comment><comment><USER9> > 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.

<comment><USER41> 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.

<comment><USER42> 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.

<comment><USER43> 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.

<comment><USER42> 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.

</comment></comment></comment></comment></comment><comment><USER44> 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.

<comment><USER45> 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)

</comment></comment><comment><USER46> 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!!!

</comment><comment><USER47> 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?

</comment><comment><USER48> 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)

<comment><USER49> > 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.

<comment><USER48> 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.

</comment></comment></comment><comment><USER45> 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...

</comment><comment><USER50> > __ _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

<comment><USER51> > 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.

<comment><USER50> hmm... I like your insight - thank you.

</comment></comment></comment><comment><USER52> > 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/)

<comment><USER22> 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?

<comment><USER52> 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.

<comment><USER22> 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.

<comment><USER53> 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.

<comment><USER22> 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.

</comment></comment></comment></comment></comment></comment><comment><USER54> 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.

<comment><USER55> 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...)

<comment><USER54> 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.

<comment><USER55> 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)

<comment><USER56> 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)

</comment></comment></comment></comment></comment><comment><USER28> 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."

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


Hello Santa - <AUTHOR> https://www.hellosanta.com/?utm_source=hacker_news&utm_medium=link&utm_content=1&utm_campaign=hacker_news

<comment><USER2> I'd love to use this, but I agree, I need to know the pricing up front. Also, can we see what a video message might look like? I'd like to evaluate the quality of the message before I send it to my friends kids.

Edit: never mind, you do have some edited samples. It's the same Santa throughout (which makes sense) so we have to take your word that the message we get will be of the same calibre. But that's the risk we take I suppose.

<comment><USER3> My deceptive senses were tingling... but for 20 and 10 bucks... it's a pretty nice service.

I can see why they wait on the price... probably converts better by getting people little pregnant. Maybe HN crowd is too sensitive to the practice.

</comment></comment><comment><USER4> I don't like that you capture all my data before even mentioning pricing. I get that you want to build your email list, but it is a bit backhanded to hide pricing that far in.

<comment><AUTHOR> Thanks for giving us a shot. We've found that by having parents make micro- commitments then hitting them with the price we convert better.

Did you really think it would be free? How can we better present the value of delivering high-quality theatrical performance on demand?

<comment><USER5> Santa call center in India?

<comment><AUTHOR> Of course, there's only on Santa. ;)

However we do have a distributed network of hundreds of highly trained, pre- screened performers all across the country.

</comment></comment></comment></comment><comment><USER3> Anyone go through the hurdles to get price? Not interested in the product... but am interested in what they charge.

Show HN seems misleading... says it's from the jib jab guys... isn't that a fairly established entity?

<comment><AUTHOR> We're charging $19.99 for a live video chat with Santa plus a recording of your call. We've also introduced $9.99 for a video message from Santa.

Last season was our first year. This year we teamed up with JibJab to help bring HelloSanta to the masses.

<comment><USER6> Put it on the front page. Not mentioning the price up front is creepy.

</comment></comment></comment><comment><USER7> Can I do more than one child at a time? I'm not trying to be cheap, but it would be odd to have one leave the room for 5 minutes, then switch them.

The information you ask for obviously assumes one child.

<comment><USER7> I'm replying as a follow-up after having used the service.

I ended up having to reschedule due to my internet connection going down an hour before my first scheduled call. It ended up coming back up (Comcast was working in the area) in time, but I didn't know if it would and decided to be safe rather than sorry. The reschedule process was flawless.

My boys are 7 and 8 and still "mostly" believe. They were the ones I did this for. My girls; 11 & 12 don't, so I didn't involve them.

The "Facetime" style live video option was, without a shred of doubt, worth every penny. The boys absolutely loved it. Santa was awesome, and him knowing their teacher's names was a convincing little tidbit of information. There were a couple of odd-placed "dings" during the call that I'm still not sure about (what they meant), but other than that, it was flawless. My older son was so excited he could barely sit still. He did throw Santa a curve ball at the end asking if Santa had anything for his sisters, but Santa was able to think on his feet and get through it without a hitch.

The only suggestion I can come up with is possibly providing some method of testing the live video feed 24-48 hours before the call. I had no issues on an iMac which has a good built-in webcam, but as a primary Windows user, I would have wanted to test things before the call to make sure it would work if I were using a Windows box.

Overall - great service, thank you for posting it, and if they still believe, I'll be doing it again next year!

</comment></comment><comment><USER8> What does a highly personalized video message mean ? Some of these things I've seen just follow a script and add names of the children and family members in. For $10 will your santa read a full script ?</comment>


I tried Silicon Valley's favorite 'brain-enhancing' drugs - <AUTHOR> http://fusion.net/story/58131/i-tried-silicon-valleys-favorite-brain-enhancing-drugs/

<comment><USER2> Garbage article. There are no "brain enhancers", only stimulants, both commonly used (coffee, tea etc) and pharmaceutical (amphetamines et al). Look up Bacopa on examine.com, specifically the studies on Memory Enhancement. For the ones with participants in the target (aka non-old) group of 18-45, it's about 50-50. After supplementing over several months.

<comment><USER3> > There are no "brain enhancers"

I wholeheartedly agree with you that the article is indeed one big garbage advertisement, alas there is a large number of non-stimulatory substances which reliably enhance cognition in measures that can be readily quantified and telling people otherwise is spreading ignorance and misinformation.

First of all, virtually all Adaptogens are non-stimulant cognition enhancers, of which these are the most notable:

Bacopa - [http://examine.com/supplements/Bacopa+monnieri/](http://examine.com/supplements/Bacopa+monnieri/) Rhodiola - [http://examine.com/supplements/Rhodiola+Rosea/](http://examine.com/supplements/Rhodiola+Rosea/)

Second, there are the profound alas very situational cognition enhancers, such as:

Piracetam & Noopept in stroke victims, former Alcoholics (quite common) and as you pointed out the elderly. NSI-189 & PRL-8-53 for poverty-stricken adults who grew up sleep deprived and/or malnutritioned (common).

Then there are substances widely reported as helpful in healthy subjects, alas with insufficient studies:

Tianeptine, Centro & CDP/GPC Cholines, Sulbutiamine ...hell even Creatine is a slight cognitive enhancer.

Now - to your point: are any of these life changing? In damaged individuals, perhaps. Alas like you said in healthy young adults, many of these substances will produce either mild improvements or no improvements at all save for extreme neurological outliers.

But to claim that Stimulants are the only cognitive enhancers especially when you seem to've done some basic research... why?

<comment><USER2> >But to claim that Stimulants are the only cognitive enhancers especially when you seem to've done some basic research... why?

>Now - to your point: are any of these life changing? In damaged individuals, perhaps. Alas like you said in healthy young adults, many of these substances will produce either mild improvements or no improvements at all save for extreme neurological outliers.

I'm only addressing perceptible cognitive enhancement with regards to otherwise healthy + young individuals (the target demo of the products listed in the article). I've gone through every study on examine.com for all the usual suspects (racetams, choline, rhodiola, bacopa etc) and have even tried them all personally for ~6 months. I feel pretty confident in saying that they are worthless for people in that demo.

</comment></comment></comment><comment><USER4> One giant advertisement.</comment>


YubiKey 4C Nano unveiled - <AUTHOR> https://www.yubico.com/2017/09/family-growing-yubikey-4c-nano-unveiled-microsoft-ignite <comment><USER2> Does anyone know whether there is a USB-C (plug) to USB-A (socket) adapter? I'd like to be able to use the USB-C Yubikeys on my regular ports of my computer.</comment>


A trip down NBA Jam graphics pipeline - <AUTHOR> http://fabiensanglard.net/nbajamte/index.html <comment><USER2> The main programmer behind NBA Jam was Mark Turmell. He's basically from my hometown and I remember reading about him in the local paper, he took computer classes at the local community college and was selling Apple II games when he was 16 or so.

He also worked on other coin-op hits like NFL Blitz, Smash TV, and WWF Wrestlemania.

</comment><comment><USER3> I am always interested in articles that detail the process of developing video games during the late 80s and early-to-mid nineties.

I especially love anything documenting the sometimes strange transition to 3D - (the Sega Saturn actually used 'quads' - or scaled sprites, as polygons instead of triangles...) - there is something really fascinating about it to me.

<comment><USER4> A Cambrian explosion with a ton of funky software / hardware approaches. 3D accelerators around the Riva TNT and NV Geforce killed off most of the other approaches.

</comment></comment><comment><USER5> Note: this is an article about the hardware used to render an arcade game called NBA Jam. It has nothing to do with JAM stack graphics.</comment>


How can cars keep up with gadget innovation? - <AUTHOR> http://arstechnica.com/cars/2014/06/industries-collide-how-automakers-are-adapting-to-consumer-tech-life-cycles/

<comment><USER2> Standardized interfaces. Bluetooth audio and phone is a good start. A standardized Bluetooth video and touchscreen proxy would also be a fantastically powerful tool. (And useful in other places, too!)

Expose the hardware over standard interfaces, let the market work its magic. Sandbox as appropriate, but when you're not letting code run rampant in the car itself it's more like a browser sandbox than a Java sandbox.</comment>


Poor Man's CI – A course on creating your own CI pipeline from scratch - <AUTHOR> https://www.subtle.press/course/poor-mans-ci/ <comment><AUTHOR> Hey all! Author here! This is a course on building a CI pipeline on top of git hooks using Nodejs. Leave a comment if you've got any questions!</comment>


Hardest Super Mario Maker level ever Made cleared by the creator only so far - <AUTHOR> https://www.youtube.com/watch?v=_sxY8pELhqM <comment><AUTHOR> In theory, is "twitch plays.." able to beat this level?

<comment><USER2> Latency is way to high if I had to guess.

<comment><AUTHOR> Good point, that's why they usually play games like pokemon</comment></comment></comment>