Once again, Path steals your data without permission
eeqj.com
eeqj.com
This is unacceptable behavior. At best it's a terrible and potentially physically dangerous bug. At worst it's complete disregard for user privacy.
I'm not complaining on theoretical grounds. I am on a temporary remote assignment, the location of which I wish to keep private due to business considerations. Before I left, I disabled location services for Path.
Today I posted a picture that I'd taken yesterday (after cropping out location-identifying features). Underneath, Path posted the name of the city that I'm in, publishing my location to all of my contacts.
Again: This is unacceptable behavior.
Well this is clearly part of the real problem. Anyone who saw the photo could have seen where they were taken from the EXIF data because you didn't clear it. Most users don't know that the data is there and don't know that they need to, it's a weird thing privacy wise and a lot of people get put in weird situations because of it. (McAfee comes to mind.)
You're still telling the Internet where you were even if Path doesn't go ahead and tag it and make it visible to you. If anything, what they've done is actually saved you some embarrassment and made you realize that data was there so you could take action about it (like taking down the photos and posted ones with cleared EXIF data) if you want.
But 90% of the time for 90% of users, this EXIF data is pretty useful. It's kind of a pickle and really to solve it properly what you're asking iOS to do is give files with completely different metadata out based on the user's privacy preferences, which aren't always spelled out entirely clearly, especially the way iOS works with kind of an all or nothing location privacy selection. You can't really tell the OS "Hey, for the next five days, let's not be explicit about where I am." or "Hey, keep my privacy for me when I'm in a certain geofence".
This is stuff they could add, but doing it right isn't trivial.
I'll never understand this mindset.
When I tell my smartphone "Don't give this app location data" then that is pretty damn unambiguous. It's not like there are countless ways for an app to obtain such data. It can request it via API, or it can read it from images. At the least, if the images were taken on this phone (which a computer can very well determine), then I would expect the data to be stripped. If the phone stores location data in other file-types then I'd expect those to be stripped in the same way.
The technocrat stance "but we meant only one kind of location data" doesn't fly when the user intent is about as clear as it can get. It's exactly the kind of "smart" that I expect from a "smart" phone.
Sure, that case is somewhat more simple, but that's rarely what most people actually want. What most people actually want is to sometimes hide their location from most things when it's sensitive and leave the phone and most apps free to know when it's not.
I think they need to actually support the types of location privacy preferences users are going to want if they want to do location privacy correctly.
What I describe is a simple bug; a defective on/off-switch.
When I ask you to not give anyone my address, yet you give everyone access to a drawer full of documents that you annotated with my address, then you can hardly claim to have taken my request seriously.
The on/off switch was originally designed for whether or not you wanted to give the app access to GPS information. Some people say no simply to save power. EXIF data and other types of data which can be used to identify your location are different.
If you want controls over location privacy you should build real controls over location privacy, not pretend that a control that's displayed only once the first time you use an app and only for apps that access GPS-like information is a location privacy control.
It's not.
You can identify a location from a bunch of different types of data. If you want to fix the bug you need an actual fix and that requires a better location privacy control.
(Also if you answered no to all of those questions at the beginning of my post, I'd bet you'd change your tune in an instant if someone at Path simply reprogrammed their stuff to geotag based on a geoip lookup from your submission. Then you and others would probably say that this control is supposed to prevent that type of location data too.)
No. I have stated explicitly what I want and only one of your points (strip location data from files that the phone created) was part of it.
Btw GeoIP is not equivalent to a GPS tag and rather useless on mobile IPs. Try looking up your own if you don't believe.
It's not hard to get this right. They just chose not to, either through neglect or malice.
If you want the system to manage that metadata properly you need to give the users better controls than the existing coarse grained per app location preferences. I think they should, but the suggestions most people are making to fix this on HN are very narrow.
Path, of course, knows where I am due to the geolocation of the IP from which I post.
My intent was communicated to the app through the disabling of location services. Posting my location uncovered through parsing EXIF is the opposite of my configured intent.
When I post pictures to Twitter, Twitter receives the EXIF-tagged photos, too. They, however, don't serve them with the geotags, as I have disabled geotagging for my account. I haven't tested if they just strip all photo EXIF, or only for accounts that disabled geotagged tweets.
On iOS in particular it's possible to receive location updates only when changing cell towers, wifi, etc, basically it doesn't use any extra battery.
A few days ago I turned this behaviour off on an app and replaced it with a behaviour where instead it polls for location for a few seconds on start and then shuts off all location services because users disable location services because they believe it is negatively impacting their battery life.
The complaints weren't your tracking my location, the complaints were you're killing my battery life.
The point is^ that users don't (and couldn't be expected to) understand that location service permissions aren't transitive. They have gone to the options menu and said "No path, you may not use my location". The result is that path has still used their location. The steps from A to B and the technical steps taken are-- from a user's perspective-- irrelevant.
^I'm not an iOS user, so maybe the UI makes this all blindingly obvious, in which case I apologise and you can ignore my entire response.
That's what I was thinking.
I recall testing Google+ to see if it would pull location data out a picture I'd take previously at the time of posting even though I'd set the app not provide location with the post - for fear of exactly this.
In the G+ case, it won't go and tag the photo, but it doesn't strip the location data out either.
Not sure what you mean here. If my app loaded a user's picture, and they said they don't want location data to be used in my app, a simple if check will decide whether or not EXIF data should be read. This is hardly "every imaginable length".
Of course, this may just be a bug, so I don't think we can jump to any conclusions about Path's intentions.
I think it's ludicrous. iOS is quite clear in its explanation of Location Services, and their explanation is not at all "technical" or intimidating to non-technical users. Also, the permission to access your photos is completely separate from the Location Services permission. Maybe you the author would have a point if iOS automatically gave apps access to your camera roll, but that's not the case.
I don't doubt that some users will be surprised by the photo's geotag, but I suspect it would be an extremely low number of users (the fact that this if just now being blogged about seems to corroborate this, unless Path have just recently added this behavior).
As you said, Location Services and Photo access are different permissions. Users are therefore likely to assume that location data is not being retrieved if they deny permission to it. If I deny location data to an app, it's because I don't want that app to have my location data. It seems somewhat underhanded, to me at least, to assume that the user wouldn't mind me accessing location data from their photos, knowing full well that the majority of users will not know what EXIF data is. I'd go so far as to say that I would explicitly ask the user if EXIF data should be read alongside the standard location services.
But, to me, if I was told that my app can't access location information, I would assume that it's because the user doesn't want my app to access location information and have my app run with that mindset.
You want your iPhone's camera to access location for one app, but not for another. What would you do? What you're saying is that the user has no choice and it's all or nothing. Give location data to all apps requiring photos or disable it completely.
Is Path supposed to censor those image?
You choose to tag your photo. You chose to share the photo. How is that different than posting a text that says where you location is?
That's not the point at all. Your example is of someone explicitly announcing their location. The issue at hand, which may or may not be a bug, is that the metadata is being used to publish the user's location even after they've said that they don't want the app accessing the Location Services.
Technically, there's nothing wrong in that because the app isn't accessing the Location Services. However, I'm pretty sure most users would assume the app won't use any location data by turning that setting off. If you denied an app location data, would you be happy that they still managed to get location data via a means that's not necessarily obvious?
The issue on the Path end is that they are circumventing the user's clear intent to not provide locational data to their application. Whether or not that is malicious or just ignorant is unknown.
Either way, they are publishing user data that users have taken steps to explicitly avoid publishing.
If I disable location data for an app, Apple shouldn't allow any form of my location to be passed to that app.
> Otherwise you'd need to have every app do this check
Do what check? When you ask for location data, all you have to do is say "you won't give me that? Okay." This app seems to have asked for location data, but instead said "you won't give me that? I'll go out of my way to get it anyway." There is no need for an explicit check. It is less work to do the right thing.
At this point, I think Apple needs to pull the app and revoke their developers license.
I seriously doubt they'll do that. It's more likely some new law will be passed because of this than Apple will take such a big step.
And I don't think a new law is likely at all.
I just don't want every sketch-ass third-party app that I want to post some scenery into to know exactly where I am.
Too much to ask?
Clearly Apple, like Path, never saw this issue (until now).
They are relying on reputable companies to be good stewards of their data, and infer their intent from their actions. I would expect Twitter, Facebook, Apple, and even Path to know that unless the user has enabled geotagging, they don't want their location leaked via EXIF.
That some of these companies do not do that is not surprising, but it is disappointing.
Perhaps, but without a proper study of their users (and potential future users), how can they infer their intent, and why should they assume that all or even most users will have the same intent? It's certainly conceivable that a user might deny Path access to Location Services (for example, to prevent the automatic location updates due to annoyance rather than personal privacy concerns, or even to save battery life), while still having no problem with including location information from explicitly posted photos.
Honestly, I think any attempts at preempting all supposed outrage like this are futile. You're always going to have someone who will complain about something in your app that works differently than they expected or intended. If Path did ignore geotagged photos, they might have someone just as outraged as this author, but for the opposite reason.
The argument that Apple should be more clear is more valid, since for them there is little downside to being as explicit as possible. This is the same position I took in the Great Address Book Debate. I don't think app developers have a responsibility to second guess the options provided by their platform (especially when their platform is as huge as iOS). In fact, I don't even think it's wise in general.
The outrage of a user who disabled location services, but wanted their location uploaded is NOTHING compared to the implications of sharing someone's location without permission. We are talking about life-and-death, in some rare cases (e.g. http://www.petapixel.com/2012/12/03/exif-data-may-have-revea...).
In this case, they don't need to infer my intent. My intent is clear: I have not gone into the app settings and configured it differently. I disabled location services at the OS level for the entire application.
My intent could not be more clear.
A much better option would simply be to provide a simple interface to allow users to exclude this information each time they post a photo and/or in the application settings.
You're right, it's not clear. So, it should explicitly ask when you do so.
(I don't use Path so I don't know if it in fact asks this or at least makes clear that it will be sharing your photo locations before doing so. The article implies it does not.)
There is nothing that suggests that granting applications access to the content of your photos also grants them access to your current location.
Facebook and Twitter also makes available the location of your photos. Is there a particular reason you are singling out Path? I hope it's not a stretch to assume this is a page view grabbing technique.
Twitter respects the geolocation setting, and strips the exif location data from photos when serving them. Whether or not they do this before upload is unknown, but pictures posted to Twitter from the iOS app do not include location data when geotagging of tweets is disabled.
The reason I'm not picking on them is because neither of them (Twitter due to Doing The Right Thing, Facebook due to lack of opportunity) have published my private data in express violation of my wishes. Path did so today.
Regardless, despite missing this warning, I'm a technical user and know about EXIF data. The real issue is Path ignoring my explicit demand that it not track my location.
That's a pretty bad analogy.
(That's not to say we shouldn't have a discussion about data ownership and privacy. Just that we should wait to be outraged at things that actually deserve our outrage.)
Malicious implies they're trying to do harm, which I don't think is the case. But geotagging posts when the user clearly didn't authorize you to access that information is dubious and underhanded at a minimum.
After last year's incident, they've lost all benefit of doubt.
Coming from the people caused Apple to issue an OS update to prevent them from stealing contacts... it deserves outrage. But 90% of that should be pointed at Path.
I don't agree with the article's stance that Path found a way to be jerks again, so clearly Apple screwed up. Phonebook access should have been restricted, but for this one the user has to select the photo, Path can't just read every photo and steal that information, so it's not nearly as serious as last year.
On the one hand, you've indicated to Path that you're not interested in them making your location public. Maybe from an API standpoint maybe that just means location data off your phone, but from the user's standpoint, in a "use case" sense, it means your location, in any form.
And then Path adheres to that-- because they have too in an API sense-- but then goes right ahead and works out your location differently and uses that.
It reminds me of Airlines who advertise unreasonably cheap tickets and then have a bunch of extra fees and forced insurance which makes the total you have to pay right back up with everyone else. They aren't lying, in a vacuum their tickets are cheaper, but in the real world they aren't.
Path aren't lying either: they are not using your phone's location data off your phone, just like you asked. In the real world though, they're still doing it.
Even if path didn't process and show in html these data, since you uploaded an image file which contains them, they would be available to anyone with access to this -now public- image through other means, like a simple browser plugin.
Let's go over this again: you set path to not access your phone's location api, you didn't set path to strip your exif data from your photos. If this feature is missing, you can ask for it.
Since you are a security researcher I would expect you to understand the real issue and warn your readers. Instead you act as you discovered a security flaw. What security issue you'll discover next? That credit cards have interest?
I have another question (and I really don't mean it as snarkly as it'll sound) - if you are trying to keep yourself hidden - why are you posting to a social network (Path) and an aggregation site (hn)?
That doesn't really make sense now, does it?
Seems to me there are two different questions here.
1) Access. 2) Sharing.
I expect most people would be fine with an app accessing location data in order to present sharing options (Tag?) or respect previously expressed intent (Always tag! / Never tag!).
The problem comes from the app automatically sharing what it has accessed without prompt, seemingly against the expressed intent of the user.
I think the question here is pretty important, even if this particular case seems trivial.
The former is outrageously slimy and the latter is clearly absolutely reasonable.
iOS 6 introduced the 'Access to Photos' privacy settings/prompting that separated photos from location.
This 'location' embedded in photos is different than user location, and I guess should really be considered a third case. I think 'photo metadata' might be an acceptable third option with an explanation of all that contains. Some photographers don't want their non-location EXIF data known too.