[notphilatall]

How do you expect the app to find other users that are in your address book without uploading your address book? It can hardly send all other users to your phone in an attempt to match them up.

I agree that the second notification is a little bit annoying, but in the case of Voxer you DID have a chance to cancel out -- it didn't secretly do it in the background, which Path apparently did.

[masonlee]

I would recommend sending hashed canonical values like we do in Textie. I posted this explanation for our users and anyone interested:

http://blog.textie.me/post/17261989750/keeping-your-address-...

[masonlee]

While the security of the hash itself can be a concern, the technique is always valuable:

1. In particular, the domain of email addresses is less vulnerable to rainbow tables than the domain of phone numbers.

2. Using salts and a slow hash function improves security by requiring custom rainbow tables that take longer to build.

3. In a B2C situation, an easy appeal to justice can be made that a business should not be making a concerted effort to break its own customer privacy protection. This would not look good in court.

4. If additional consumer protection laws are needed, one-way hashing for the purpose of privacy could be considered a form of pro-consumer DRM. In that realm we have precedents for anti-circumvention laws and contracts.

[dvillase]

Since we give them access to our Address Book, I wasn't too surprised.

[jcoder]

They can hash the values they want and compare them with hashed values from other phones.

[sriramk]

The hashing won't let them do partial name matches and other 'fuzzy' matching where there isn't an exact text match but strong signals to indicate a match.

[quorn3000]

I'm sure it's possible to search within encrypted data.

edit: http://www.schneier.com/blog/archives/2009/07/homomorphic_en...

[rmc]

No, but you can hash on guarantee to be unique keys, like phone numbers. Just normalise all phone numbers, hash em, and upload them. Phone numbers are guaranteed to not have transposed characters or abbrevations.

[notphilatall]

Again, hashing won't do much except make you feel fuzzy inside. Since the hashing mechanism is stored on the phone and the possibility space for US phone numbers is extremely limited, it'd be trivial to hash all possible numbers and then do a reverse lookup of the hashed values of your stolen address books.

[brudgers]

Phone numbers stored in an address book are not guaranteed to be unique(at least in the US) because they can be stored with or without area code and with or without country code.

[notphilatall]

You can usually assume that the non-country/area-code numbers have the same country/area code as your current user, if you know their phone number (good thing to get during registration).

[baddox]

Hence the normalization step. You can probably guess the country code from other information (e.g. if your app is only in the US). If there's no area code included, then you can't match it up anyway, hashed or otherwise.

[notphilatall]

It's mostly a question whether they store it or not -- although they have to store it in order to support notifying you when new users who are in your address book join the service.

If their servers are compromised, a cracker could still get MOST of the info. Since the hashing function (and salting mechanism) lives on the phone, she could generate a rainbow table of all possible phone numbers and a set of emails for common domains.