Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We are sorry

blog.path.com

Post reply on HN
Print view View original

111–120 of 220 posts

Re: We are sorry

#111

Post by gma »

Call me a cinic, but suggesting that we shouldn't be concerned by saying "It is also stored securely on our servers using industry standard firewall technology" seems somewhat naïve. As if that means that our data was adequately protected from prying eyes...

I'd be impressed if they'd turned round and said "We realise it looks like we were trying to expand our business off the back of your private data, and have therefore decided that in our next release we will stop uploading user's contact details altogether. We'll make our social network so compelling that it'll go viral without abusing your privacy."

Re: We are sorry

#112

Post by Me1000 »

erikpukinskis wrote: post #95
Me1000 wrote: post #91

Earlier quoted context omitted.

Preface: I will joining Path this Summer, but I do not speak for the company in any way, nor have I spoken with them about the situation. This is a purely technical reply... You cant guarantee a unique hash. When you hash users' data there is the possibility of collision; this probability grows with every new user. Without identifying data of some sort, it's difficult (impossible?) to get the exact user.

It doesn't matter. The purpose of the hash isn't to uniquely identify users, it's to narrow the list of users that need to be sent down to the phone. If Path could send their entire user database to the phone, they wouldn't need to send the contacts to their server.

The main purpose is to send you a push notification when your friend joins, since a push notification can't execute client side code... that wouldn't work.

Re: We are sorry

#113

Post by jacquesm »

nbm wrote: post #64
mikeash wrote: post #52

Earlier quoted context omitted.

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 ad…

Facebook is trying to push the responsibility for the privacy of your friends to you with this, and by doing so they are violating EU privacy laws.

See: http://en.wikipedia.org/wiki/Data_Protection_Directive

This is one of the few areas where the EU is (still...) ahead of the rest of the world. Facebook should not be able to collect data on your friends even at your request unless your friends explicitly consent to this.

Clearly your friends have no business passing on your data and Facebook has no business collecting it. "Make sure your friends are comfortable" is no excuse for facebook to go ahead and break the law.

Re: We are sorry

#114

Post by Me1000 »

jwegan wrote: post #106
Me1000 wrote: post #91

Earlier quoted context omitted.

Preface: I will joining Path this Summer, but I do not speak for the company in any way, nor have I spoken with them about the situation. This is a purely technical reply... You cant guarantee a unique hash. When you hash users' data there is the possibility of collision; this probability grows with every new user. Without identifying data of some sort, it's difficult (impossible?) to get the exact user.

That is incorrect. SHA1 still has no known collisions despite years of research and computing power dedicated to finding just one collision. Edit: Furthermore since the set of valid emails and phone numbers is a very restricted set of input, it is extremely likely that there are literally no two valid email/phone numbers that SHA1 hash to the same value.

That's a fair assessment,

Re: We are sorry

#115

Post by jacquesm »

ellie42 wrote: post #108
54mf wrote: post #13

Earlier quoted context omitted.

The fact that they've already deleted all user address book data, and have an updated version of the app available today with a privacy option, is a big deal. I don't know how they managed to get an update to the app approved so quickly (24-48 hours?), they must have worked directly with Apple. A good sign, either way.

There is no proof of that they really deleted all user address book data.

You can't prove a negative. You can only prove the existence of certain data on a particular server, you can not prove that a company does not have certain data unless you are prepared - and they are willing - to give you full access to audit each and every byte on their systems and to wipe any parts that they can't explain and you can't find a way to decrypt.

Clearly that is not practical so we'll have to take them at their word, as it stands I think that if path is found out to be lying about this that it will come back to haunt them big time.

Re: We are sorry

#116

Post by hythloday »

Me1000 wrote: post #91
benwerd wrote: post #47

It's not a perfect solution, but I don't understand why Path don't hash the contact details before uploading them, and check against the hashes. You can still infer all kinds of social graph information, of course, but they're at least not consuming raw contact details.

Preface: I will joining Path this Summer, but I do not speak for the company in any way, nor have I spoken with them about the situation. This is a purely technical reply... You cant guarantee a unique hash. When you hash users' data there is the possibility of collision; this probability grows with every new user. Without identifying data of some sort, it's difficult (impossible?) to get the exact user.

Well, this isn't quite right--the domain of the hash function is a numerical representation of the user, maybe a 64-bit int, so it's obvious that you can engineer a non-colliding hash (trivially: the hash function is XOR). What's more interesting is whether there's a hash function such that Path can't infer the social graph from user requests without the user's permission. It seems to me a hash would be both one-way (obviously) and dense (so that a randomly generated request from a user would have a good chance of matching another user).

I can't think of a hash function without a good public-key infrastructure, which is obviously beyond Path's remit. Anyone aware of a solution to this?

Re: We are sorry

#117

Post by benwerd »

erikpukinskis wrote: post #95
Me1000 wrote: post #91

Earlier quoted context omitted.

Preface: I will joining Path this Summer, but I do not speak for the company in any way, nor have I spoken with them about the situation. This is a purely technical reply... You cant guarantee a unique hash. When you hash users' data there is the possibility of collision; this probability grows with every new user. Without identifying data of some sort, it's difficult (impossible?) to get the exact user.

It doesn't matter. The purpose of the hash isn't to uniquely identify users, it's to narrow the list of users that need to be sent down to the phone. If Path could send their entire user database to the phone, they wouldn't need to send the contacts to their server.

Replying to Me1000, with hashes it would still be trivial to create a system that determines when a friend's signed up, and alerts you. That doesn't require a full address book entry - or any contact details at all beyond an identifier. It's not like Path is actually notifying using any of the contact details it stores, which means it's either representative of wasteful coding on their side, or of something else going on.

Re: We are sorry

#118

Post by jacquesm »

latchkey wrote: post #96

I wonder if when Path 'deleted' the data, they shredded the hard disks too? http://www.networkworld.com/news/2011/042511-google-hard-dri...

That's a good point, and then there are of course back-ups to be considered. Deleting data is surprisingly hard, but fortunately for path this is 'bulk' so that makes it a little bit easier.

Making sure you really lose a single record is a lot more expensive because then you have to selectively remove it from your spinning back-ups as well, in this case you can just wipe the back-ups of the file by opening the file for 'update' and overwriting it with random data.

Tapes are a bit harder again...

Re: We are sorry

#119

Post by tjoff »

Only problem is: It was not a mistake.

They did this only to cover their asses and that has been the only concern they've ever had. That they already tried to push the opt-in was of course only in fear of what just happened.

I'm sorry, I'm all for public apologies and I truly believe that it is in times like these companies have a chance to really prove themselves and really make a mishap something positive (and come out stronger than ever before). And they have tried to do that, for that I give them credit.

But. It was not a mistake. And this sentence really shows why: "Through the feedback we’ve received from all of you, we now understand that the way we had designed our ‘Add Friends’ feature was wrong."

They did it deliberately, there was not a mistake anywhere when implementing this nor with their intentions, and if they honestly didn't understand that what they did was wrong they don't deserve to be trusted again, not never. And if they did understand that it was unethical, which they undoubtedly did, it is even worse.

Their trust is not worth anything more than what they think they can get away with. The only thing that is different today from yesterday is that they think they can get away with less.

This desperately highlights why both android and iOS needs a way to spoof contacts for apps (return an empty list). Some android developers have solved this by having two apps in the market, one "private" version that requires fewer permissions. But that's a kludge (that I really appreciate) that almost noone uses.

Re: We are sorry

#120

Post by jxcole »

tjoff wrote: post #119

Only problem is: It was not a mistake. They did this only to cover their asses and that has been the only concern they've ever had. That they already tried to push the opt-in was of course only in fear of what just happened. I'm sorry, I'm all for public apologies and I truly believe that it is in times like these companies have a chance to really prove themselves and really make a mishap something positive (and come…

You seem to define a mistake as 'an error in the code'. However, their use of the term mistake to be 'an error in judgement' or 'an error in the value of user's privacy', is also valid. When someone does something immoral, saying that it was a mistake because they didn't think it was immoral at the time (but now they realise it is) can, in many situations, be a good response.

Of course, there are some things for which no amount of apology could ever bring about true forgiveness (think godaddy). I personally don't feel this is one of those times, but everyone is entitled to their opinion.

EDIT: Switching "amoral" to "immoral"

Post reply on HN