If they do it often enough, in the end one of them will even claim they're using the "standard industry practice"
We are sorry
61–70 of 220 posts
Re: We are sorry
#62Earlier 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?)
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
#63Earlier 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).
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
#64Honestly, 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.
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
#65Re: We are sorry
#66Honestly, 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).
https://developer.apple.com/library/ios/#DOCUMENTATION/Audio...
Re: We are sorry
#67Earlier 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).
Re: We are sorry
#68Earlier 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…
"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
#69Earlier 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…
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
#70Isn'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?