Live data from Hacker News

We are sorry

blog.path.com

131–140 of 220 posts

Re: We are sorry

#131
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…

[deleted]

Re: We are sorry

#132
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…

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. Well, you can make a mistake intentionally . As in: "I intentionally opted for course A, and I realize it was a mistake".

True. What I meant was that they try to make it sound (at least to me) like the action of stealing the contacts of its users was a mistake. They do this by saying: We believe you should have control when it comes to sharing your personal information. etc. etc. It makes it sound that it somehow was a mistake for those believes to be violated. It wasn't.

And if you ask me, that breach of their users trust is not something that you can just turn around. If they didn't understand that their users might get upset that only makes it worse (when it comes to trusting them).

Re: We are sorry

#133
Path is one of the most well-managed apps I have had the privilege of using to date. Their response to this 'scandal' was as close to flawless as it gets.

Not only did they take full responsibility for what they did and apologize instead of making excuses, they deleted all the data people were concerned about, wrote a well-worded blog post about it that hit the top of hacker news within a couple hours, AND pushed a fix for the issue to the app store all within less than a day of the concern becoming public.

Path's attention to detail not only in the gorgeous design and user experience of their app, but in the way they handle PR crises like this one only makes me trust them more. Well done Path, well done.

Re: We are sorry

#134
post #91
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.

You can guarantee a unique hash for all practical purposes. If you manage to find a collision in a robust cryptographic hash then the world of computing will have far more important things to worry about than a social network getting slightly confused.

Re: We are sorry

#136
post #120
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 whic…

Sorry to pick on semantics, but wanted to clarify this because I initially was confused when reading your post: you meant "immoral," correct? "Amoral" does not mean "morally wrong," but rather refers to things which are morally agnostic. It actually seems to me that Path believed their actions were amoral, that is, not registering anywhere on the moral spectrum (neither right nor wrong).

Re: We are sorry

#138
post #64

Earlier quoted context omitted.

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

Your neighbours to the north also have laws like this that are on par with the DPD. The EU treats PIPEDA as essentially an implementation of the DPD so that DPD compliant orgs can share data with Canadian businesses.

Re: We are sorry

#139
post #106

Earlier quoted context omitted.

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.

I agree that it's practically not a concern, but the local part of an email address[0] is up to 64 characters in an alphabet of size 72, and the domain part is 253+ characters in an alphabet of size 38, giving the valid email space a size of greater than 3e519, which is enough to guarantee collisions in SHA-512 and all of the SHA-3 finalists. [0] http://tools.ietf.org/html/rfc3696

If the set of data did contain 3e519 entries then yes it certainly would generate collisions, however it you look at a more restrictive set of data, lets say 5 emails per person alive then you're looking at about 2^35 email addresses which could easily be hashed by MD5 with out a significant chance of collision.

Instead of an MD5 they could just as easily upload a bloomfilter which would expose even less data and would compress it significantly, however it would be more computationally expensive to generate matches that way vs. hashing.

Re: We are sorry

#140

This is a welcoming move from Path. However, "industry standard firewall technology" is gibberish.

Translates as "We don't use encryption because it would cost too much, but we have ACLs so only our staff can look at your personal data"

Hmm, I read it more as "We actually have no idea what we're doing with any of this stuff and we're not giving you any more reasons to trust us with ANY data".

Written by their CEO => icing on the cake.

Post reply on HN