This comment is a great example of how people are so quick to rush to judgement with emotional reactions. Let's look at the facts:
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 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.
> 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.
Android's permission system also doesn't require apps to ask for permission before they access your phonebook - it requires you to give permission to install the app, and it tells you the app can view your phonebook, but you have to either trust the app not to abuse that ability or not install it at all. There's no way of telling the difference between an app that can use your phonebook to provide useful optional functionality and one that'll upload the entire thing to the mothership the moment you start it.
I really think Android should add another layer of protection here, similar to the "This app wants to use your ___location" prompt in iOS. I'd like to be able to install an app that might need to access my phonebook in some use case but be able to deny it when it attempts to access that information when I don't want it to.
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.
> I really think Android should add another layer of protection here, similar to the "This app wants to use your ___location" prompt in iOS
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.
On a rooted android phone, it is possible to install apps but not give the the permission. Of course, that usually means they will crash then they try to do something, but it gives you a layer of protection if you want to try the app out or something.
I'm well aware of what prompted the change to iOS. We talked about that last year. I'm not defending anything, but that's not really at issue today, though.
Specifically in this case: pretty sure Android and Path alike might be informing you about address book access, but nowhere is the user going to be prompted for Path to share with your contacts after uninstalling the app.
Same odious behavior, just a bit different this time.
1. Path was fined, not for anything involving address books, but for allowing 12 year olds to sign up for the service.
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.
1. The sub title: "Company also Will Pay $800,000 for Allegedly Collecting Kids' Personal Information without their Parents’ Consent" The fine was only with regard to the violation of CIPA.
You are equating "grant access to the address book" with "spam all 'friends' at 6 o'clock in the morning to tell them lies"
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.
> ...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.
I agree, there's no easy solution. Maybe public debates like this are the best we can hope for anyway. My approach is to be extremely cautious with apps that depend on network effects to be useful or profitable.
>Does Path actually say "We're going to invite all your friends via SMS", even in fine print?
Should it? More importantly, will anyone download the app in the first place if it did?
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.
"I think it's be more appropriate if the box bore a great red label: 'WARNING: LARK'S VOMIT!!!’"
— "Our sales would plummet!”
— "Well why don't you move into more conventional areas of confectionary??!!"
Without addressing the opt-in point, which I agree with...
You're also assuming there is no "continue without doing this" button, which of course, I was assuming there would be...
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 agree, we're just all shooting the breeze here until we get a proper word from Path, and/or a journalist does a proper investigation into what exactly did happen.
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!
Classy. Interning at a company and having not been there for 9 months (see above) obviously counts for nothing.
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.
Me1000, you should mention to the folks here that you actually worked on the address book stealing code during your time working at Path so you are particularly aware that the statements in your post there are both untrue and self-serving.
I've never hidden that I interned at Path. The address book debacle happened long before I ever joined. The code you're talking about did little more than normalize phone numbers so it could be hashed _before_ it was sent to the server.
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.
FWIW, while I disagree with your stated opinion, I can also see how you came to it. I think most of us here realise that your opinion is separate from your past employment.
There's a big difference between "X would like to access your contacts" and "X would like to access your contacts, then store everything on their servers for reasons/duration of their determination"
But not from the OS's point of view. iOS (and Android) can only warn about the contact crossing the threshold into the app. After that the app can do as it pleases...
Path's settlement with the FTC for the last address book incident was that they create a privacy program and get independent privacy audits every other year for the next 20 years.
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.
Android shows the permissions each app is requesting before you install, and even lets you know if they change their permissions between updates. While what Path did is crappy, they didn't subvert the Android permissions system.
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.
"Android shows the permissions each app is requesting before you install"
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?
That, and the page is designed so most people will click the "Accept & Download" button without even reading the top-level permission requests.
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.
But Android also doesn't allow you to deny specific permissions. It's all or nothing at time of install - if it ever gets ___location, it always gets ___location. This is one of the reasons I like iOS.
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".
Read data about contacts doesn't sound unreasonable for an app like Path though. Facebook uses that permission to sync contacts if you want, and I don't see any problem with that. Unfortunately, reading data means they can store it, off device, independently of the install state. That's a difficult problem to solve, but I don't think users should be expected to expect this as a result of that permission.
Exactly. WhatsApp wants permission to practically everything possible, because it offers various features on top of these permissions. Yet it never spammed anyone so far from what I can tell.
There is no official support for this AFAIK. Some 3rd party ROMs like Cyanogenmod have this functionality built in, though, and if you root your phone there are apps like "Permissions Denied" that you can run to do this.
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.
There is a simple solution for managing permissions for poorly built apps: serve them empty or fake data.
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).
I have always wondered why Google doesn't add this feature. Creeping up the ladder of permissions is a problem in Android, and the user's choice is all or nothing. This can become a bad choice: Add a permission, or lose access to the data an app is keeping for you.
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.
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.