>we proactively rolled out an opt-in for this on our Android client a few weeks ago and are rolling out the opt-in for this in 2.0.6 of our iOS Client, pending App Store approval.

"Proactively?" How do you get into the Social Networking business and not see this issue coming before the first line of code is written?

[re: hashing] >This is a good alternative solution which we'll look into. Thanks for the idea.

Again, no. That no competent system design talent/time was dedicated to this process is a damning critique of your organization's ability to be trusted to safeguard user data.

I think the simplest explanation is that he's playing dumb.

He almost certainly is either playing dumb or is dumb. If you're not dumb, you have to play dumb, because otherwise you'll be crucified.

Playing dumb. Hashing the information is such an obvious choice, there's really no plausible explanation for the developers to have not to consider it. They probably just figured "everyone else is doing this so what's the harm?"

It's been a long time since Plaxo.

> How do you get into the Social Networking business and not see this issue coming before the first line of code is written?

"It is difficult to get a man to understand something, when his salary depends upon his not understanding it." -- Upton Sinclair (http://en.wikiquote.org/wiki/Upton_Sinclair)

> "Proactively?" How do you get [...]

was about to say exact the same. the only thing I can add here is that if this wouldnt make headline, noone would have thought of opt outs.

If all they care about is matching users up, couldn't they just use hashes of the relevant data?

EDIT: possibly even better, they could use a Bloom filter, similarly to how Chrome uses them to filter malicious websites without sharing your entire browsing history with Google.

You really don't need to upload address book for that. Sending just hash sum of each of phone, address, name, and email would be enough to make the matching.

Hashing phone numbers doesn't do much since the space is so small.

Not that small. It's comparable to a weak password. There are about 5 billion active phone numbers in the world [1].

Besides, a small search space can only be searched quickly if it takes little time to a hash a phone number. Doing a few billion MD5-sums is not so difficult. If the hashes are computed with an expensive bcrypt then it's just a matter of increasing the number of iterations to make brute force attacks unfeasible.

Edit: I realize that the hashes can't be salted (because different phones must produce the same hashes for the same phone numbers), so a rainbow table can be created for the entire database.

[1] http://www.cbsnews.com/stories/2010/02/15/business/main62097...

The client could do 'signed' hashes using the local phone number and the friend number (sending the server both the local:friend pair and the friend:local pair).

That wouldn't really stop anybody from reversing the hashes, but it would make a global rainbow table useless.

It would make reversing the hashes substantially harder for any given hash function, though, right? Thanks very much for this idea. I'd thought about tracking social connections by sending hashes (on an explicit and opt-in basis) for my research app, Mappiness[1], but gave up the idea mainly because hashing seemed so hopelessly weak. But I think this + bcrypt might make it workable.

1. mappiness.org.uk

At that point it's also useless for matching.

It wouldn't be a strong signature, it would simply be the other half of the number pair. Numbers A and B both have easy access to A:B and B:A.

The hashes for a given user could still be attacked using their phone number, but a global table wouldn't work.

That's clever. You can then even improve the algorithm by only sending the hash of A:B for every phone number, where A < B (numerically). Then you don't have to worry about whether it's Friend:Local or Local:Friend.

Key strengthening can help. If you do a bcrypt-style hash and set the cost so as to take one second on a modern CPU, brute-forcing each phone number would take about 57,000 days :)

I would be more comfortable with this than giving them my entire address book, anyway.

But how long would it take to bcrypt your entire contact-list on an IPhone? (no idea.. but might be too long..)

PBKDF2 with a high iteration count.

Hashing doesn't let you match Kate, Katie, Katherine as the same person like Facebook does, however.

Normalization could be done on the client, however I don't think Path matches users by name anyway.

I'm sure if the Path guys had thought of that, they would be in a less bad place right now :)

I actually think that Dave's response was pretty lame. That was a typical PR/B2C response, neglecting that he is talking to techies here.

Everybody knows "why" Path is doing this and the response should have been more of "why this way".

As an engineer at a different social network -- not Facebook, but not small, about 30 million users -- he's right. That fuNctionality is important. But we do it in way that preserves privacy. IMO this is just sloppy...

Are you in a position to elaborate on your method? Does it involve hash comparisons?

I understand wanting this from a usability perspective, but is there some way to opt-out if our data is already on their servers? I, for example, in just browsing around the app out of curiosity ended up on the "find my friends" screen and without warning Path now has all of my contact data.

I have yet to open the app again.

This appears to be a sound response to a sensitive issue. Certainly handled far better than some others have handled their PR (debacles) recently.

You should not have been downvoted for your opinion on this, but I have to respectfully disagree. There MUST have been somebody at some point who mentioned that they were storing the details of non-users and making a massive database of connections without authorization, and as the CEO he must have been aware of this, and as the CEO he made a bad decision to go ahead and do it anyway.

He didn't even respond that they were checking your address book against their database for matches and then making those connections and dumping the rest of the data. He actually confirmed that they are storing non-user data in the hope of one-day making a connection. But if that was correct, the new user would make that connection when they signed up. You don't need two independent sources to make the connection through the address book.

I'll admit I only really superficially followed this through HN, and it seems you're more informed than I am - but my point was this was handled FAR better than AirBnB's debacle.

Hopefully this feature will not just prevent the Address Book from being uploaded but also remove any data already stored on their servers.