This is actually nothing new. A lot of apps have been doing this for a very long time. However, it is one of the best kept secrets in our space. I kind of have a feeling no one talks about it because they don't want word to get out. Can you imagine the scandal if this made it on the front page of CNN or Drudge?
Ever since I learned this was possible, I've been very careful about which apps I download, and actually have downloaded very few since, as a result. There are a lot of random iPhone developers that I really don't think need to have access to my entire contact list.
Apple doesn't prompt the user to ask for permission when the APIs are used (like what happens with location), so this is the desired behavior. It's very simple:
17.1 Apps cannot transmit data about a user without obtaining the user's prior permission and providing the user with access to information about how and where the data will be used
It's likely that this app will be pulled from the App Store within the next few hours.
All that means is that it has to be mentioned in a very long terms of service somewhere. If Apple cared about address book information like they currently do for location data they would make the API query the user.
I noticed that Path did this a few weeks ago when I initially installed it. My reaction was much the same: WTF?! I proceeded to file a bug report with Apple that the API should prompt for access just like the Core Location API does (somebody having ALL my contacts' info is more important to me than an app knowing where I currently am). My bug was closed as a duplicate; hopefully a change is in the works.
Yep, which makes the address book a hack for (high-latency, obviously) cross-app communication. E.g., last I knew, TextExpander added an entry to your address book with your abbreviations, so that other apps e.g. Simplenote can use those abbreviations as you type. Very well intentioned hack, which shouldn’t be necessary, but is, using an API that really just shouldn’t be open…
This sort of behaviour is almost certainly illegal in the European Union. You may not store personal information unless you have a clear and legitimate reason to store it. If you affected by this, you should contact your local data protection office.
Facebook, Foursquare, Twitter, basically any app that allows you to "search my address book for friends" will do this.
All these services require either a email or phone number to sign up, so to search for friends who have also signed up for the service, you need to compare two data sets: emails or phone numbers of users you already have, and those in the person's address book.
You obviously wouldn't download your entire database of users contact information to the phone to compare the data sets, so you send the data set up to the server.
The addresses from the user's address book should be hashed before sending to the server and compared to hashed addresses on the server. Then only positive matches are registered, and the server doesn't see more private information than it needs.
Hashing data from address book doesn't work because people write the same addresses and even phone numbers in many different ways. Normalizing it on the client is not really an option either because it requires a lot of data to do decent normalization - not practical to send it all to each client.
Phone numbers are easy to canonicalize: convert to international form.
Email addresses can be effectively canonicalized by lower casing. Not many mail servers are case sensitive these days. Additionally, for the local part, you can generally strip off anything after a "+", and with gmail, you can drop any period in the local part. (Granted, it's not perfect-- so make sure that's not a security concern.)
These techniques have been working fine so far in my app for my "Find My Friends" feature.
If so many apps do this, why all of the sudden uproar with Path doing the same? I'm not condoning it, just curious why it still happens and so frequently. It seems to me that the "industry best practices" actually need to be best practice.
I was operating under the assumption that this is not possible as I am sure many other people were. What sort of imbecile at Apple decided that allowing apps do that was even remotely acceptable to the phone owners?
Android asks for your permission on what information you want to give the app. iOS just simply gives it whatever it asks for, without asking you first.
Interesting. What else can an iOS app get access to without permission? location? browser history? other installed apps list? emails? notes? pics? vids? music list? podcast list? itunes username?
Browser History: There is no way to communicate directly with what Mobile Safari stores.
Other installed apps list: Apps are sandboxed so it is impossible to know what else is installed. If you've developed one of the other apps you can share the same App ID which gives you access to the same storage space so you could create a flag to indicate one of your apps has been installed. Some apps respond to certain protocols so you can ask iOS if a given protocol will be handled and if it returns yes then you know the app is installed. Again because they are sandboxed you really can't do anything harmful and responding to the protocol only allows the other app to receive information, not expose it.
Emails: No, the only way you can do anything with email is prompt the user to compose an email.
Notes: Same as Mobile Safari.
Pics: You can display a popup to the user that asks them to select an image from their camera roll/iPhoto and if they select a photo you then get a reference to an object that represents the photo. You can't just search their camera roll.
EDIT: rbritton points out that with the AssetLibrary framework you can actually search through all pics/videos and for some reason it gives a location access prompt when you do. http://news.ycombinator.com/item?id=3563336
Vids: Same as pics.
Music List: You can get a list of every song in the users library without asking for permission:
Podcast list: Same as music list.
iTunes Username: To my knowledge there is no way to access this but I've never been asked to so I really haven't spent time looking. In theory because you can access the Address Book you could make a best guess at which contact is the user and then assume one of their emails is their iTunes username.
You can access the Picture/Video library since iOS 4. It does prompt at least once for location access (apparently since they can contain GPS metadata), but it does not mention anything about why it's asking for that location access.
Ah that would make sense. So that would mean that if you turn off location services any app could access your asset library without any prompt then. Good to know.
I can say for sure that iTunes username is not exposed. In fact, they won't even provide an opaque user ID, which makes correlating purchases through in-app purchase with server-side user accounts very frustrating. You can sort of fake it by correlating with a device UDID, but that is leaky and has a lot of edge cases.
Android apps must explicitly request a READ_CONTACTS permission. But even there, no one actually reads those permissions lists, and apps routinely ask for far more than they need. User authorization is a very weak security mechanism in the consumer space.
Like FB apps, even legit Android apps ask for the moon, with no option to dole out granular permissions.
"The Weather Channel" is a default icon suggesting a free download on the Kindle Fire.
It asks for:
Set the wallpaper
Send SMS messages
Write to external storage
Access info about Wi-Fi networks
Access coarse location
Initiate a phone call without going through the Dialer user interface for the user to confirm the call being placed
Write (but not read) calendar data
Read calendar data
Required to be able to access the camera device
Open network sockets
Access fine GPS location
Access vibration feature
Access info about networks
Record audio
I haven't installed it, so I have no idea why it should be able to silently dial out without my permission or send SMS messages.
If legit apps are demanding all this, then a Chinese weather app dialing those toll numbers in the Caribbean could do the same.
With FB apps, you can go into your App settings and revoke individual permissions that you don't want to give. They still have to be granted to auth the app, but at least you can clean it up very quickly and easily.
Where is this setting? This is the second time I've heard someone say you could do that but I cannot find any options like that. Settings just has Refresh interval and options to configure notifications.
FWIW, if you have a rooted Android phone, you can install an app called "LBE Privacy Guard". It lets you install apps which require permission to send SMS, make calls, read contacts, access the network and a bunch of other things, but then prompts you when an app tries to do any of these things and lets you block/allow it temporarily/permanently.
CyanogenMod allows the user to remove specific permissions frmo specific apps. If more users used CyanogenMod, more app developers would become compatible.
From what I have seen you can only remove those permissions "late". Ie you have to black list permissions, you cannot deny them right away. From my understanding this would not protect me fully since apps could do their thing before I disabled it.
If you do not open them manually or restart you phone (if they have the permission RECEIVE_BOOT_COMPLETED) They are not executing. You can install them and revoke certain permissions before they are running for the first time.
Asking upfront is also a problem. Asking on demand is much more annoying to the user, but also makes them think about what the app is asking for - as opposed to a list of permissions at install time, which are skimmed over and then forgotten.
But even there, no one actually reads those permissions lists, and apps routinely ask for far more than they need.
Lots of people do read those permission lists, and they are one of the most commonly referenced complaints in app reviews. A firestorm arose when an Angry Birds update inexplicably added the ability to send SMS'.
Further it focuses a spotlight when an app does request a permission that seems out of place. Ideally when Google evaluates app for their "staff's picks" (the "optional curation") they consider threat surface area.
Honest question: Isn't this within the kind of behavior that AppStore reviews are supposed to prevent, at least if there isn't an app specific functional explanation for it? Does Apple have a list of what kind of behavior like this is tolerated or does word just get out about what they don't reject?
The app explanation for it will be 'path can hook into your address book' - presumably for sending invites or messages to friends. However at this point the cat's out the bag and path can do what they like with this data (albeit against app store policy).
The problem is surely one of governance - it must be that the app reviewers simply don't (whether through sheer volume of apps they have to review, or lack of ability) see what's being posted, and where.
What's more if Path used https and a CA, would we ever have found out what was being posted short of live debugging?
D'oh. Would this man-in-the-middle attack have worked if path validated against a CA or stored cert and only submitted the data when it was sure it wasn't being snooped on?
I've come across the latter, but it's not a difficult thing to get around if you're willing to play with the binary. You might be able to recognize the stored cert and sub it out with your own, or you can just ensure the branch that validates it never runs.
Honest answer: This is the kind of behavior that justifies the expense of writing multiple native versions of an app rather than just developing a single website accessible from any browser but having limited access to data stored on the users' computing device.
Well, since you only ever only submit the compiled application binary to Apple, it'd be pretty darn hard for them to detect behaviour like this. Especially if the code to do so is obfuscated, and/or the data is smuggled out via SSL (or worse, steganography-style piggy-backed on to other data).
Sometimes it's tempting to speculate whether the real purpose of the app store review team is just to ensure developers aren't trying to access Private Frameworks (i.e. non-public APIs) or try to upsell the customer while bypassing the 30% Apple tax?
They could do the same thing this guy did in an automated way (seed the device with unique data, sniff traffic for that that data), but as you said there are many ways to obfuscate it.
Certainly. An even easier way is to have the app call home to a web service that returns "stealUserData: false" until the app is approved, after which you switch the web service response over to "stealUserData: true"....
Pulling contact data requires API calls that can be detected in the compiled binary (this is one way that Apple detects calls to unpublished API's).
That said, it's humorous how a blatant abuse of trust such as this gets through unscathed but god help you if you try to access the iPod library the wrong way!
Well, the app could have legitimate reasons for linking to the required API (such as pretending to only use it after obtaining user confirmation), but then you could add additional obfuscated calls to the same API without prompting the user. So that wouldn't really help.
Perhaps, however when calls like this are noted additional scrutiny of the application could be applied to ensure they are not abused (such as using a proxy in the way described by the parent).
There are other actions allowed by the SDK that seem to have little non-nefarious use, such as the ability to hide the fact that an application is transmitting and receiving data (the network "spinner" can be disabled by the application); as others have mentioned it's interesting which API calls require authorization from the user while others do not.
I've received a rejection for using a "private" ivar (it was actually a framework doing it).
The ivar was in a public header, and was not marked @private, which is the only correct way to designated an ivar as private in Objective-C. Putting a comment above it saying "this is private" (which they did) doesn't count. It's protected, by definition.
Eh, I don't think you're quite right here. @private means "Only accessible by this class and its instances, not parent, sibling or child classes." What Apple means by "private" in that case, though, is "Only for use by Apple, not outside vendors." If NSActionCell has private subclasses that need the variable, marking it @private would be flat-out wrong.
No, the correct way to do it in that case would be to mark the ivar as @private, and have a private category on the class with a @property definition for that ivar (or just getter/setter methods). Leaving the ivar as protected and relying on a header file comment is just sloppy. Protected implies that any subclass can use it, not just Apple-blessed subclasses.
Interesting. Quick question, how would you deal with things that call APIs via, for example, NSSelectorFromString, where the String is built in an obfuscated way?
(I'll go back and read the paper in more detail soon)
Apple would simply tell their SSL library to dump the raw data, I mean they wrote it (or at least have source access to it) and have absolute control of the devices used to test. Nothing hard at all.
Our app was recently rejected specifically for this reason, though we had a "skip" button, contacts weren't just automatically 'farmed'. So we had to add a popup with explicit allow/deny buttons and then the app passed subsequent reviews.
Two 'by review' app stores I've had experience with are iTunes App Store and Amazon App Store. Here's what I've seen:
- iOS app review is very minimal. For the initial submission, they'll play around with the app for ~5 minutes. I've had updates approved without the app even being launched, and other times it's approved with simply logging in and launching the app on different devices. They are mainly concerned about policies, private APIs, etc. Things get stricter when you submit in-app purchases, but again those are more administrative than functional. So, I don't think they would ever catch something like this.
- Amazon's testing is insanely detailed compared to Apple's(at least, for the first submission - I haven't submitted updates yet). They tested the app on several Android devices, and also were looking at data over the wire using, presumably, a client proxy. They will reject the app if you send up passwords/usernames without using SSL, for instance. They hit all the menu buttons and try most features. And they review all permissions your app needs.
So I download an IM app that automatically finds your friends based on your phone directory. I launch it and scrolling through my friend's list I see my mom. Some contacts later, I see the real name of the hooker. Both my mom and the real hooker are on this IM platform...just a click away from chatting with me under the same identity. This can be more than creepy, fortunately this is a made up example ;)
I thought about this with whatsapp. This is scary because while we are used to having multiple emails for different parts of our lives, juggling multiple phone numbers is still a chore despite services like google voice.
It's a double edged sword. Many users like it that they don't have to create a user name, remember a password, confirm an account (usually), etc and that all of their other friends 'automagically' appear on the app who've installed it. Whatsapp has something like %90 of smartphone users in sweden.
Phone numbers cost money, and multiple emails are usually a chore still.
Quora best handles this situation. There can be a lot of benefit for the user to have the contact lust on the server, but it needs to be (1) transparent, (2) obvious, and (3) come with a delete button.
Yeah, but you still have to store the hashes server side in the case where you want to notify people when their friends join (which is how Path was using the data).
Moral of story: don't target techies as your end users. They'll just look under your hood to make sure you're not doing anything embarassing like this, and passing back clear-text password in JSON.
Here's a question: was there a concept of privacy 100 years ago? Or 500? Whenever someone had a baby, or bought a cow, or had an affair on their spouse, didn't everyone in town know about it? Did they ask people's permission when the first telephone book was published?
Or was the first response, "hey, that's an invasion of my privacy!" I doubt anyone said that before the 1950's.
I think privacy is an invention of the late 20th century. I am truly curious if any real notion of "invasion of privacy" existed for most of man's history.
Your comment seems trollishly silly, but... the internet and residential electricity are also both inventions of the 20th century - I guess we could destroy those too without bothering you?
I haven't heard an assertion so patently foolish and I'll considered since the Path CEO claimed that uploading every users "little black book" onto the Path servers without permission or notification was an "industry standard best practice."
The responsibility entirely rests in a large part on the shoulders of the geek community - the enablers. I find this entire thread surreal. These were the obvious issues that were front and center way back when chat servers showed up. Some have been raising this issue both publicly and privately since early 90s if not earlier and were marginalized precisely for being bad news bears.
Here is to RMS and his kind.
At this point, if you want a solution, you need to contact your representative and demand data and electronic privacy laws like that which is written in the constitution of Switzerland.
>Arun, thanks for pointing this out. We actually think this is an important conversation and take this very seriously. We upload the address book to our servers in order to help the user find and connect to their friends and family on Path quickly and effeciently as well as to notify them when friends and family join Path. Nothing more.
>We believe that this type of friend finding & matching is important to the industry and that it is important that users clearly understand it, so we proactively rolled out an opt-in for this on our Android client a few weeks ago and are rolling out the opt-in for this in 2.0.6 of our iOS Client, pending App Store approval.
You really don't need to upload address book for that.
Sending just hash sum of each of phone, address, name, and email would be enough to make the matching.
Not that small. It's comparable to a weak password. There are about 5 billion active phone numbers in the world [1].
Besides, a small search space can only be searched quickly if it takes little time to a hash a phone number. Doing a few billion MD5-sums is not so difficult. If the hashes are computed with an expensive bcrypt then it's just a matter of increasing the number of iterations to make brute force attacks unfeasible.
Edit: I realize that the hashes can't be salted (because different phones must produce the same hashes for the same phone numbers), so a rainbow table can be created for the entire database.
The client could do 'signed' hashes using the local phone number and the friend number (sending the server both the local:friend pair and the friend:local pair).
That wouldn't really stop anybody from reversing the hashes, but it would make a global rainbow table useless.
That's clever. You can then even improve the algorithm by only sending the hash of A:B for every phone number, where A < B (numerically). Then you don't have to worry about whether it's Friend:Local or Local:Friend.
It would make reversing the hashes substantially harder for any given hash function, though, right? Thanks very much for this idea. I'd thought about tracking social connections by sending hashes (on an explicit and opt-in basis) for my research app, Mappiness[1], but gave up the idea mainly because hashing seemed so hopelessly weak. But I think this + bcrypt might make it workable.
Key strengthening can help. If you do a bcrypt-style hash and set the cost so as to take one second on a modern CPU, brute-forcing each phone number would take about 57,000 days :)
I would be more comfortable with this than giving them my entire address book, anyway.
If all they care about is matching users up, couldn't they just use hashes of the relevant data?
EDIT: possibly even better, they could use a Bloom filter, similarly to how Chrome uses them to filter malicious websites without sharing your entire browsing history with Google.
I understand wanting this from a usability perspective, but is there some way to opt-out if our data is already on their servers? I, for example, in just browsing around the app out of curiosity ended up on the "find my friends" screen and without warning Path now has all of my contact data.
>we proactively rolled out an opt-in for this on our Android client a few weeks ago and are rolling out the opt-in for this in 2.0.6 of our iOS Client, pending App Store approval.
"Proactively?" How do you get into the Social Networking business and not see this issue coming before the first line of code is written?
[re: hashing]
>This is a good alternative solution which we'll look into. Thanks for the idea.
Again, no. That no competent system design talent/time was dedicated to this process is a damning critique of your organization's ability to be trusted to safeguard user data.
Playing dumb. Hashing the information is such an obvious choice, there's really no plausible explanation for the developers to have not to consider it. They probably just figured "everyone else is doing this so what's the harm?"
> How do you get into the Social Networking business and not see this issue coming before the first line of code is written?
"It is difficult to get a man to understand something, when his salary depends upon his not understanding it." -- Upton Sinclair (http://en.wikiquote.org/wiki/Upton_Sinclair)
As an engineer at a different social network -- not Facebook, but not small, about 30 million users -- he's right. That fuNctionality is important. But we do it in way that preserves privacy. IMO this is just sloppy...
You should not have been downvoted for your opinion on this, but I have to respectfully disagree. There MUST have been somebody at some point who mentioned that they were storing the details of non-users and making a massive database of connections without authorization, and as the CEO he must have been aware of this, and as the CEO he made a bad decision to go ahead and do it anyway.
He didn't even respond that they were checking your address book against their database for matches and then making those connections and dumping the rest of the data. He actually confirmed that they are storing non-user data in the hope of one-day making a connection. But if that was correct, the new user would make that connection when they signed up. You don't need two independent sources to make the connection through the address book.
I'll admit I only really superficially followed this through HN, and it seems you're more informed than I am - but my point was this was handled FAR better than AirBnB's debacle.
Arun, thanks for pointing this out. We actually think this is an important conversation and take this very seriously. We upload the address book to our servers in order to help the user find and connect to their friends and family on Path quickly and effeciently as well as to notify them when friends and family join Path. Nothing more.
We believe that this type of friend finding & matching is important to the industry and that it is important that users clearly understand it, so we proactively rolled out an opt-in for this on our Android client a few weeks ago and are rolling out the opt-in for this in 2.0.6 of our iOS Client, pending App Store approval.
I'm at a loss as to how this is surprising anyone. How did people think that these apps found other users you know? This is built to support: A) finding existing people on the service and B) so they can (theoretically) send you notifications if a friend joins. If you want those features (and it seems that users do), this is the only way to do it. Admittedly, most apps are more explicit about it with a "find friends from address book," but if you want to lower the friction as much as possible, this is the way to do it.
One-way hashing the phone numbers and emails would at least be a good solution to alleviate the privacy concerns, while still allowing you connect with your friends on Path.
One-way hashing phone numbers cannot really be one way, unless you are using an inherently really slow hash function.
Without it, generating the table of say 10^10 hashes is within range of almost everyone (especially on a GPU). At say 1ms per input, it would take 10M seconds, or about 4 months.
I don't have a problem with this as long as they ask permission up front before doing so. I don't recall having been presented with that question myself though.
Disappointed in Path, especially since their focus was on a more private, tightly knit social network.
This is NOT controversial. You give them permission to do this. If you don't want Path to import your address book, then don't ask Path to import your address book.
Does this mean that the standard HTTPS stack on the iPhone is insecure? Shouldn't certificate verification fail when it attempts to send data via the mitmproxy?
Yeah, I've noticed that too. After my first sync with Yahoo! Address book years ago, I ended up getting Facebook suggestions to people I didn't really know but who were in my Yahoo! address book.
I begin to understand what Richard Stallman has been saying all those years. Although I don't like the guy on the personal level, this incident make him completely right - running closed source software can compromise your rights. (rights to privacy in this case).
I also want to thank the author of this post to discover this! I wanted to try Path some time ago, now I can safely avoid it without regret.
open source software can collect exactly the same information on you.
there was a furor recently where it was revealed that OS X and Windows collect data on what access points you have associated with. what was omitted was that linux does exactly the same thing: the wireless subsystem has a debug print (at a debug info level turned on in all major distributions) that will log the MAC address of the AP you just associated with.
You think people should be upset because a Linux computer knows the MAC address of the AP you are associated with? If that is a problem, then imagine what people will think when they realize that the computer knows what keys you press on the keyboard (!!??)
There is only a problem if the operating system shares information with 3rd parties without authorization.
the furor (at least, that I saw) was that the devices stored this information and would potentially let others look at it later.
it shouldn't be upsetting that your computer knows what keys you're pressing or what network you are affiliating with. recording that information permanently could be bad.
if you have an ubuntu laptop with wireless handy, run the following command:
282 comments
[ 3.0 ms ] story [ 279 ms ] threadEver since I learned this was possible, I've been very careful about which apps I download, and actually have downloaded very few since, as a result. There are a lot of random iPhone developers that I really don't think need to have access to my entire contact list.
https://developer.apple.com/library/ios/#documentation/Addre...
17.1 Apps cannot transmit data about a user without obtaining the user's prior permission and providing the user with access to information about how and where the data will be used
It's likely that this app will be pulled from the App Store within the next few hours.
All these services require either a email or phone number to sign up, so to search for friends who have also signed up for the service, you need to compare two data sets: emails or phone numbers of users you already have, and those in the person's address book.
You obviously wouldn't download your entire database of users contact information to the phone to compare the data sets, so you send the data set up to the server.
Email addresses can be effectively canonicalized by lower casing. Not many mail servers are case sensitive these days. Additionally, for the local part, you can generally strip off anything after a "+", and with gmail, you can drop any period in the local part. (Granted, it's not perfect-- so make sure that's not a security concern.)
These techniques have been working fine so far in my app for my "Find My Friends" feature.
I was operating under the assumption that this is not possible as I am sure many other people were. What sort of imbecile at Apple decided that allowing apps do that was even remotely acceptable to the phone owners?
In theory.
Browser History: There is no way to communicate directly with what Mobile Safari stores.
Other installed apps list: Apps are sandboxed so it is impossible to know what else is installed. If you've developed one of the other apps you can share the same App ID which gives you access to the same storage space so you could create a flag to indicate one of your apps has been installed. Some apps respond to certain protocols so you can ask iOS if a given protocol will be handled and if it returns yes then you know the app is installed. Again because they are sandboxed you really can't do anything harmful and responding to the protocol only allows the other app to receive information, not expose it.
Emails: No, the only way you can do anything with email is prompt the user to compose an email.
Notes: Same as Mobile Safari.
Pics: You can display a popup to the user that asks them to select an image from their camera roll/iPhoto and if they select a photo you then get a reference to an object that represents the photo. You can't just search their camera roll.
EDIT: rbritton points out that with the AssetLibrary framework you can actually search through all pics/videos and for some reason it gives a location access prompt when you do. http://news.ycombinator.com/item?id=3563336
Vids: Same as pics.
Music List: You can get a list of every song in the users library without asking for permission:
Podcast list: Same as music list.
iTunes Username: To my knowledge there is no way to access this but I've never been asked to so I really haven't spent time looking. In theory because you can access the Address Book you could make a best guess at which contact is the user and then assume one of their emails is their iTunes username.
https://developer.apple.com/library/ios/#documentation/Asset...
Thanks for the heads up. I was unaware of the AssetLibrary framework.
Ideally the OS should prompt you if an app wants access to your address book, just like it does for location.
"The Weather Channel" is a default icon suggesting a free download on the Kindle Fire.
It asks for:
I haven't installed it, so I have no idea why it should be able to silently dial out without my permission or send SMS messages.If legit apps are demanding all this, then a Chinese weather app dialing those toll numbers in the Caribbean could do the same.
If you do not open them manually or restart you phone (if they have the permission RECEIVE_BOOT_COMPLETED) They are not executing. You can install them and revoke certain permissions before they are running for the first time.
I also remember seeing that permissions were reset on reboot, but that might have been some other setup, not CM.
For their Facebook Connect permissions, they ask for all the permissions… (that was true beginning of November, not sure they changed it since)
Lots of people do read those permission lists, and they are one of the most commonly referenced complaints in app reviews. A firestorm arose when an Angry Birds update inexplicably added the ability to send SMS'.
Further it focuses a spotlight when an app does request a permission that seems out of place. Ideally when Google evaluates app for their "staff's picks" (the "optional curation") they consider threat surface area.
http://gizmodo.com/5028459/aurora-feint-iphone-app-delisted-...
The problem is surely one of governance - it must be that the app reviewers simply don't (whether through sheer volume of apps they have to review, or lack of ability) see what's being posted, and where.
What's more if Path used https and a CA, would we ever have found out what was being posted short of live debugging?
Sometimes it's tempting to speculate whether the real purpose of the app store review team is just to ensure developers aren't trying to access Private Frameworks (i.e. non-public APIs) or try to upsell the customer while bypassing the 30% Apple tax?
That said, it's humorous how a blatant abuse of trust such as this gets through unscathed but god help you if you try to access the iPod library the wrong way!
There are other actions allowed by the SDK that seem to have little non-nefarious use, such as the ability to hide the fact that an application is transmitting and receiving data (the network "spinner" can be disabled by the application); as others have mentioned it's interesting which API calls require authorization from the user while others do not.
The ivar was in a public header, and was not marked @private, which is the only correct way to designated an ivar as private in Objective-C. Putting a comment above it saying "this is private" (which they did) doesn't count. It's protected, by definition.
NSActionCell.h, I think.
As far as I know Apple was not interested.
Here's the paper if you want to take a look: http://seclab.cs.ucsb.edu/media/uploads/papers/egele-ndss11....
(I'll go back and read the paper in more detail soon)
So the analysis would fail to determine the method and class of a obfuscated string.
- iOS app review is very minimal. For the initial submission, they'll play around with the app for ~5 minutes. I've had updates approved without the app even being launched, and other times it's approved with simply logging in and launching the app on different devices. They are mainly concerned about policies, private APIs, etc. Things get stricter when you submit in-app purchases, but again those are more administrative than functional. So, I don't think they would ever catch something like this.
- Amazon's testing is insanely detailed compared to Apple's(at least, for the first submission - I haven't submitted updates yet). They tested the app on several Android devices, and also were looking at data over the wire using, presumably, a client proxy. They will reject the app if you send up passwords/usernames without using SSL, for instance. They hit all the menu buttons and try most features. And they review all permissions your app needs.
I thought about this with whatsapp. This is scary because while we are used to having multiple emails for different parts of our lives, juggling multiple phone numbers is still a chore despite services like google voice.
Phone numbers cost money, and multiple emails are usually a chore still.
"Contacts are suggested from among persons in a user's electronic address book, as well as people with whom the user is communicating by email."
It's been there for over a year. http://en.wikipedia.org/w/index.php?title=Path_%28social_net...
The moral is to treat customers privacy with utmost respect.
Or was the first response, "hey, that's an invasion of my privacy!" I doubt anyone said that before the 1950's.
I think privacy is an invention of the late 20th century. I am truly curious if any real notion of "invasion of privacy" existed for most of man's history.
I haven't heard an assertion so patently foolish and I'll considered since the Path CEO claimed that uploading every users "little black book" onto the Path servers without permission or notification was an "industry standard best practice."
What a bunch of hogwash.
Here is to RMS and his kind.
At this point, if you want a solution, you need to contact your representative and demand data and electronic privacy laws like that which is written in the constitution of Switzerland.
>Arun, thanks for pointing this out. We actually think this is an important conversation and take this very seriously. We upload the address book to our servers in order to help the user find and connect to their friends and family on Path quickly and effeciently as well as to notify them when friends and family join Path. Nothing more.
>We believe that this type of friend finding & matching is important to the industry and that it is important that users clearly understand it, so we proactively rolled out an opt-in for this on our Android client a few weeks ago and are rolling out the opt-in for this in 2.0.6 of our iOS Client, pending App Store approval.
edit: Morin responds to a response http://mclov.in/2012/02/08/path-uploads-your-entire-address-...
To the suggestion that they just hash the addressbook entries:
> 1. This is a good alternative solution which we'll look into. Thanks for the idea.
Besides, a small search space can only be searched quickly if it takes little time to a hash a phone number. Doing a few billion MD5-sums is not so difficult. If the hashes are computed with an expensive bcrypt then it's just a matter of increasing the number of iterations to make brute force attacks unfeasible.
Edit: I realize that the hashes can't be salted (because different phones must produce the same hashes for the same phone numbers), so a rainbow table can be created for the entire database.
[1] http://www.cbsnews.com/stories/2010/02/15/business/main62097...
That wouldn't really stop anybody from reversing the hashes, but it would make a global rainbow table useless.
The hashes for a given user could still be attacked using their phone number, but a global table wouldn't work.
1. mappiness.org.uk
I would be more comfortable with this than giving them my entire address book, anyway.
EDIT: possibly even better, they could use a Bloom filter, similarly to how Chrome uses them to filter malicious websites without sharing your entire browsing history with Google.
I have yet to open the app again.
Everybody knows "why" Path is doing this and the response should have been more of "why this way".
"Proactively?" How do you get into the Social Networking business and not see this issue coming before the first line of code is written?
[re: hashing] >This is a good alternative solution which we'll look into. Thanks for the idea.
Again, no. That no competent system design talent/time was dedicated to this process is a damning critique of your organization's ability to be trusted to safeguard user data.
was about to say exact the same. the only thing I can add here is that if this wouldnt make headline, noone would have thought of opt outs.
"It is difficult to get a man to understand something, when his salary depends upon his not understanding it." -- Upton Sinclair (http://en.wikiquote.org/wiki/Upton_Sinclair)
He didn't even respond that they were checking your address book against their database for matches and then making those connections and dumping the rest of the data. He actually confirmed that they are storing non-user data in the hope of one-day making a connection. But if that was correct, the new user would make that connection when they signed up. You don't need two independent sources to make the connection through the address book.
Arun, thanks for pointing this out. We actually think this is an important conversation and take this very seriously. We upload the address book to our servers in order to help the user find and connect to their friends and family on Path quickly and effeciently as well as to notify them when friends and family join Path. Nothing more.
We believe that this type of friend finding & matching is important to the industry and that it is important that users clearly understand it, so we proactively rolled out an opt-in for this on our Android client a few weeks ago and are rolling out the opt-in for this in 2.0.6 of our iOS Client, pending App Store approval.
Dave Morin Co-Founder and CEO of Path
Without it, generating the table of say 10^10 hashes is within range of almost everyone (especially on a GPU). At say 1ms per input, it would take 10M seconds, or about 4 months.
Disappointed in Path, especially since their focus was on a more private, tightly knit social network.
I also want to thank the author of this post to discover this! I wanted to try Path some time ago, now I can safely avoid it without regret.
there was a furor recently where it was revealed that OS X and Windows collect data on what access points you have associated with. what was omitted was that linux does exactly the same thing: the wireless subsystem has a debug print (at a debug info level turned on in all major distributions) that will log the MAC address of the AP you just associated with.
it's still there, afaik.
You think people should be upset because a Linux computer knows the MAC address of the AP you are associated with? If that is a problem, then imagine what people will think when they realize that the computer knows what keys you press on the keyboard (!!??)
There is only a problem if the operating system shares information with 3rd parties without authorization.
it shouldn't be upsetting that your computer knows what keys you're pressing or what network you are affiliating with. recording that information permanently could be bad.
if you have an ubuntu laptop with wireless handy, run the following command:
sudo grep AssocResp /var/log/syslog