Live data from Hacker News

We are sorry

blog.path.com

61–70 of 220 posts

Re: We are sorry

#61
I see a trend of pushing the envelope of what is admissible. If users don't like it they are quick to apologize (lusers..., we'll iterate over this...)

If they do it often enough, in the end one of them will even claim they're using the "standard industry practice"

Re: We are sorry

#62

Earlier quoted context omitted.

a cryptographic hash of a phone number on their server should match a cryptographic hash of a phone number in a contact list on a phone. The app sends the hash to the server, the server looks up users via the hash and responds with user data for matches. To be honest this should be a third party service, since it sounds like every major social networking app is doing the same exact thing.

In my opinion, giving out your number, along with the hash of each phone number in your address book to an authority with millions of such hashes isn't appreciably better than giving them in plaintext. (Hi Dan?)

But you wouldn't give out your number. I haven't completely thought it through but the service provider would provide an api for common platforms. All it would do is 2-way encrypt contact numbers (SSL?). Then the service would do a basic lookup using the encrypted data as a key. If there is a hit for this particular platform it'll return the platform specific data (in this case, like a path specific user id).

Of course the other side would be maintaining users in this service, which again is pretty straight forward.

(Hi David?... I'm the OTHER DJB, probably not the one you are thinking of)

Re: We are sorry

#63
post #45

Earlier quoted context omitted.

That wouldn't add any real protection. Phone numbers is a very small set (100 million possible in the U.S. and Canada). A rainbow table of all possible combinations can be created in only a week or two.

However, phonenumber+userid creates lots of nice unique hashes. If they are going to hash the data, they should salt it (and possibly use key strengthening a la bcrypt, etc).

Hashing phonenumber+userid does absolutely nothing for them, though.

The purpose of uploading your contacts is so that if Jack's phone number is (555) 555-5555, and Sam uploads a contact list saying that he is friends with a guy whose phone number is (555) 555-5555, Path can match up those two phone numbers (or hashed versions of them) and tell Sam that Jack is a member. That match-up doesn't work if the phone number is stored as (a hashed version of) 5555555555jack and 5555555555sam.

Re: We are sorry

#64
post #52

Honestly, I keep hoping Apple adds a permission check for the contact list (like they do for GPS location). If the user says no, they should just return a blank contact list (to keep old apps happy that aren't expecting the call to fail).

It's crazy that they haven't added this already. Facebook needs to get my permission to find out where I am, but not to scrape a hundred names, phone numbers, and addresses out of my phone? Bizarre.

I realise you might be using Facebook as an example in a theoretical sense (i.e., that Apple believes protecting your location is more important than protecting your contact database), but in case you weren't, Facebook's "find friends" feature does give you an explanation of what is going to happen, asks you to confirm.

Here's the explanation:

"If you enable this feature, all contacts from your device (name, email address, phone number) will be sent to Facebook and be subject to Facebook's Privacy Policy, and your friends' profile photos and other info from Facebook will be added to your iPhone address book. Please make sure your friends are comfortable with any use you make of their information."

Re: We are sorry

#65
A proper apology. Unlike what Google did with their fiasco in Kenya a few weeks ago, the company actually did away with any benefits they derived from the bad conduct. Google simply apologized (great because it's free) yet didn't mention deleting all data scraped, deleting all contact information collected for the businesses, and cancelling all orders for hosting and other such services. I presume they must have maintained all profits generated by their conduct. It's good to see that Path at least understand what it actually means to be contrite.

Re: We are sorry

#66

Honestly, I keep hoping Apple adds a permission check for the contact list (like they do for GPS location). If the user says no, they should just return a blank contact list (to keep old apps happy that aren't expecting the call to fail).

Totally agree. Same thing before letting apps dump the entire iPod library, while they're at it.

https://developer.apple.com/library/ios/#DOCUMENTATION/Audio...

Re: We are sorry

#67
post #45

Earlier quoted context omitted.

That wouldn't add any real protection. Phone numbers is a very small set (100 million possible in the U.S. and Canada). A rainbow table of all possible combinations can be created in only a week or two.

However, phonenumber+userid creates lots of nice unique hashes. If they are going to hash the data, they should salt it (and possibly use key strengthening a la bcrypt, etc).

But if you do this then you can't match phone #s in a users phone book against phone numbers in your database.

Re: We are sorry

#68

Earlier quoted context omitted.

"We made a mistake. Over the last couple of days users brought to light an issue concerning how we handle your personal information on Path, specifically the transmission and storage of your phone contacts." Dave explained the issue well enough in the first paragraph.

If you put yourself in a user's shoes that doesn't know what the issue was then that is still generic. As a user who doesn't know the story I'd be wondering: - Did they get hacked and now some unknown party may have the contents of my address book? - Were they selling my information to others? - Did something happen as it relates to storage that mixed up or deleted information - Was my data being transmitted in the c…

Paragraph four, which answers questions 2 and 4 in your list and suggests that the answer to 1 and 3 is "No":

"In the interest of complete transparency we want to clarify that the use of this information is limited to improving the quality of friend suggestions when you use the ‘Add Friends’ feature and to notify you when one of your contacts joins Path––nothing else. We always transmit this and any other information you share on Path to our servers over an encrypted connection. It is also stored securely on our servers using industry standard firewall technology."

The actual problem was number 5, and they tell you exactly how they are fixing this: by deleting all existing data and letting people opt in to sharing it.

Re: We are sorry

#69
post #45

Earlier quoted context omitted.

However, phonenumber+userid creates lots of nice unique hashes. If they are going to hash the data, they should salt it (and possibly use key strengthening a la bcrypt, etc).

Hashing phonenumber+userid does absolutely nothing for them, though. The purpose of uploading your contacts is so that if Jack's phone number is (555) 555-5555, and Sam uploads a contact list saying that he is friends with a guy whose phone number is (555) 555-5555, Path can match up those two phone numbers (or hashed versions of them) and tell Sam that Jack is a member. That match-up doesn't work if the phone number…

They could take the phone numbers, sort them and hash them together. So if Sam is 5 and Jack is 6, they both upload the hashed social relationship 56 to the system and it can match them up.

It wouldn't keep someone with access from checking if a social relationship existed in the database, but it should make recovering phone numbers and the like from the hashes quite a lot harder.

Re: We are sorry

#70

Isn't it unfair that Path gets all this press for making a mistake and apologizing? What about all the apps that didn't make this mistake?

They're getting press because It's relevant to people like me, who are current users of Path that started freaking out over it...
Post reply on HN