Here's to hoping the next fine will exceed their cash reserves and we can put an end to this madness.
The post is proof positive that path still uploads phonebooks from the app to their servers right after installing it.
Is it? The texts were coming from his phone number, which suggests they were sent from his phone (not necessarily, I know, but you said "proof positive").
I don't know how Android text message sending works, but there is likely some rate limiting to how many texts you can send so they certainly could have been queued up to be sent later.
1. Path was fined, not for anything involving address books, but for allowing 12 year olds to sign up for the service.
2. Yes... it is proof that Path uploads your phone book. Of course, they ask you. The OS won't even give you access to the phone book without prompting the user. So somewhere along the way, the user knowingly gave Path access to their contacts.
It would be rather trivial for a real reporter to do some research here. Does Path actually say "We're going to invite all your friends via SMS", even in fine print? It might be sleazy, but it would certainly change a lot. But instead, we're just going to sit here and speculate about things and irrationally talk about a fine that didn't have anything to do with this.
The thing that burnt the poster is that while a social app asking for access to their contacts might not rise a brow, the user has no way to know what they are going to do with that data without looking at the reviews or around the internet for complaints/testimonials.
Yes and no. Google often hides the most offensive permission requests under that "see more" arrow. And the permission requests (and accompanying explanations) are too vague and ambiguous. For example: Does "request access to network" mean they're able to sniff all my incoming/outgoing data, granting the app access to everything?
It's got the title and button at the top, taking up a large chunk of space (1/3rd on my Nexus 4), and then a vague list of - to most users - technical-sounding "stuff".
My guess is a large majority of users never look past the button.
<uses-permission android:name="android.permission.READ_CONTACTS"/>
Go to play.google.com. Search for path. First result in the app store. Click on Permissions.
"This application has access to the following:
... blah blah blah ...
This permission allows the app to use the camera at any time without your confirmation.
... blah blah blah ...
read your contacts Allows the app to read data about your contacts stored on your tablet
... blah blah blah ...
read call log Allows the app to read your tablet's call log, including data about incoming and outgoing calls.
... blah blah blah ...
Now users have been trained to click "yes" to all requests without even reading them, so I you can get into philosophical arguments about if the "really" have permissions. Just like most users randomly click thru "click thru licences".
I'd assume the reason Google is somewhat hesitant to offer this officially is that many apps don't deal well with this -- some do degrade gracefully, while others end up throwing task-ending exceptions because the app code just never planned for not being able to do some task which requires permissions declared in the manifest.
Every app already has to consider the case of GPS being unavailable indoors, the contact list only having one person (yourself) in it, or the camera picture being black in darkness.
I'm sure some apps will fail anyway because they just never expected a contact list of 0 entries, but the list should be much smaller in that situation (mostly limited to those who do virtually no QA).
It would be easy enough for developers to catch security exceptions that Google would find little or no developer fall-off due to a requirement like this.
>Does Path actually say "We're going to invite all your friends via SMS", even in fine print?
No one -- in their right minds -- would suddenly want to share (non-existent) photos with all their contacts. Seems like an odd way to say "We're going to invite all your friends via SMS". Your address book doesn't consist primarily of your Twitter followers. It doesn't matter if they intended it to be a feature; someone at the company should have raised a Big Red Flag and made any such SMS feature explicitly opt-in-only. With a big fonts, high-contrast colors, dancing bananas or whatever else you can use to grab attention to that fact.
This is an order of magnitude beyond sleazy.
Many users just mash on the "next" button on app intro screens. Again, it's all just speculation until someone takes the time to start researching and documenting the facts instead of just yelling "KILL IT"! :/
I'm not unsympathetic when someone says "oh, I didn't read that bit" (I'm guilty of that too), but surely they have usability experts who would have warned them about it. The original author is technically inclined to make an informed decision. That's a big deal to me. That tells me, they never gave the guy any settings options to begin with or hid it in an obscure panel.
What's worse, according to the author, texts were sent possibly after he uninstalled the app. Which means they still keep the data!
For what it's worth, I disagree with Path and Me1000's arguments. Doesn't mean us here at HN should be attacking him or ignoring his points because of that, nor does it mean that doxing him is acceptable.
Really disappointed with HN in this thread :/
I don't know what the details are on those audits, but if these texts were sent without consent it seems like the kind of misuse of personal information that they would be concerned about.
That's not true, is it? According to the FTC[1], they were fined for "collecting personal information from their mobile device address books without their knowledge and consent."
2. Yes... it is proof that Path uploads your phone book. Of course, they ask you. The OS won't even give you access to the phone book without prompting the user. So somewhere along the way, the user knowingly gave Path access to their contacts.
Giving them permission to read the address book (which might be useful and perfectly legitimate) and giving them permission to send everyone in that address book spam is two very different things.
> The OS won't even give you access to the phone book without prompting the user. So somewhere along the way, the user knowingly gave Path access to their contacts.
The introduction of address book privacy in iOS was in large part prompted by the publication of Path's behavior. Up until the Path and eventually iOS update after the controversy first arose, Path didn't explicitly ask the user for access to their address book.
http://www.engadget.com/2012/02/15/iphone-address-book-issue...
> Path was fined, not for anything involving address books, but for allowing 12 year olds to sign up for the service.
Path was fined for the 12 year old signup thing specifically, but they were still charged with privacy violations regarding the address book kerfuffle.
For example, I'd want to be able to use the facebook app and many users might even want to have it scan their address books in order to find friends. However, if the app attempts to read my address book when I'm just checking someone's status update that is clearly not okay and I want to be able to block it.
The free pass to pillage my phone upon installation doesn't sit well with me.
Most definitely. This has always been my argument against the whole system: installing apps that need excessive permissions is basically blackmail. Just like "Do you agree to the terms of service?", you hardly have a choice. I was very surprised to see people not even glance at the permissions before clicking Accept.
But as I said, it's blackmail anyway whether you look or not. You don't want them to have all your contacts, your exact location, all data on your sdcard, and full network access? Fine then, you won't get [whatsapp] (or pretty much any other app), that what everyone else has and that you're almost socially obliged to have (at least in my age category).
It even goes so far that the android user has no permissions to use the permission manager to deny or allow permissions for apps. There are commands ("pm grant x" and "pm revoke y") that lets you change apps' permissions... but you can't use it by default, even as root ("java.lang.SecurityException: Neither user [your uid] nor current process has android.permission.GRANT_REVOKE_PERMISSIONS"). It's totally messed up.
Same odious behavior, just a bit different this time.
By your logic, it would be completely useless to even read the fine print, because giving them access to the addressbook would imply my consent for them to do anything technically possible with it.
Well, from a technical perspective that is indeed the case. Once they physically have your contact info they may do as they please.
You, as the iOS or Android user, are not giving them permission to use your contacts "properly" or "nicely"--you're giving permission to access them, the raw data of all of them, and once that's done all bets are off. If the app is untrustworthy it is free to go crazy (one of the reasons I always say "no" to that question).
I don't see how Apple or Google can stop this in a technical way without making the permissions more fine grained which in turn makes it more confusing to users (who probably mostly click "OK" anyway).
Apple could, however, make better app policies so that they can pull apps when they attempt this kind of shady crap. I'm not familiar with the Android app store policy, so I won't speculate there.
It's been about nine months since I've worked at Path and as you may know (although, given how baseless your comment is, perhaps you wouldn't know)... startups move quickly, Path has released many updates since I've left. It's incredibly disingenuous to suggest what I'm saying is untrue (since both statements I made are provable with empirical evidence) or that I had any motive other than trying to get people to think before they go on a witch hunt.
Droithomme, if I know you personally, I would appreciate you contacting me privately.
Lots of people know Randy. He's had posts on the front page of HN.
As much as a developer can be a "public figure", I think he is one.
If John Resig posted about DOM libraries and someone mentioned that he wrote jQuery, I don't think anyone would suggest he'd been doxed.