Path promises fix for grabbing geolocation data from photos

Security researcher says Apple can also do better at preventing privacy leaks.

Just as Path was trying to put its privacy woes behind it, a security researcher has caught the social network taking new liberties with personal information stored on iPhones and iPads. Path developers have submitted an update that fixes the problem, which they only became aware of today, officials at the company said.

Path's iOS app was found copying geographic locations embedded in photos and pasting them into user posts—even when location services have been disabled. This is according to a blog post published Friday by Jeffrey Paul, a self-described hacker and security researcher living in Berlin. He characterized the behavior as exploiting a loophole, since it allows Path to regularly keep tabs of users' locations, even when they have taken pains to keep that data private.

"This is surely terrible form on Path's part," Paul wrote.

In a comment responding to the post, a Path official thanked Paul for bringing the behavior to the company's attention. At the time, he didn't say how soon an updated app would be available for download.

"One note to clarify: If a Path user had location turned off and an image was taken with the Path camera, Path does not have the location data," Path Product Manager Dylan Casey wrote. "This only affected photos taken with the Apple Camera and imported into Path."

Paul's post came hours after the US Federal Trade Commission said Path would pay $800,000 to settle charges that it violated users' privacy by collecting personal data from mobile device address books without their knowledge or permission. The settlement also requires Path to establish a "comprehensive privacy program" that will be subject to monitoring for the next 20 years.

Paul said his discovery also underscored the need for Apple to build safeguards into iOS that prevent EXIF—or Exchangeable Image File format—data embedded in photos from being detected by individual apps unless users explicitly approve. Apple added similar fine-grained protections last year preventing apps from accessing contacts, photos, and location data. The changes followed revelations that Path's iOS app uploaded users' entire address books to its servers, a controversy that touched off the FTC investigation resulting in Friday's settlement.

31 Reader Comments

When are people going to learn Path is clearly ran and operated by a bunch of criminals.

You don't publish, test, and write an entire application that places geographic location information in posts from an image even after the user disabled the feature. SOMEBODY wrote that code which means this complete and total screw up was on purpose.

These criminals are not going to stop their behavior until Apple bans any and all applications that use their API. If you upload my geographic location without my permission and I happen to be an enlisted solder and I specifically disabled that feature on my phone, its a serious problem, if a post now has my physical location within it.

I don't know or use Path, but I also think that Apple shouldn't let apps have access to exif gps data on photos if those apps aren't allowed to use location services by the user. Apple should close this loophole soon.

I don't know or use Path, but I also think that Apple shouldn't let apps have access to exif gps data on photos if those apps aren't allowed to use location services by the user. Apple should close this loophole soon.

The only way to prevent that would be to remove direct access to photos and only letting them be accessed through a form of "wrapper" that can strip exif data on-the-fly, or prohibit apps from using built-in methods for extracting/parsing exif data.

While Path has definitely had its share of privacy problems, some of the comments here don't seem to be well thought out.

Of course Path has within it code to parse and post location data from photos, some people want this feature and specifically choose to allow Path to access location data. There is no setting within the Path app that allows people to enable/disable the posting of location information from photos. Instead, users choose whether to allow Path access to location data on a system level, just like with any other app on iOS.

My guess is, and this is clearly a guess but makes sense from my point of view, that whenever a photo is loaded into Path it tries to access and post the location data. When Path has been denied access to location data the pictures it takes using the in-app camera don't contain location in the EXIF data so this attempt fails silently and nothing is posted. The Camera app on the iPhone, however, has its own setting for whether or not to allow access to location data. Most users, whether they're aware of it or not, allow the Camera app to access location data and so any pictures taken with that app will have location information in their EXIF data.

So…when a user selects a photo from their photo library to share on Path instead of using the built in Path camera, that photo may have location information contained in its EXIF data. Path then happily parses and posts this as if it was supposed to be there.

The point being, while this may be a bit of sloppy coding (e.g., not checking to see whether the app has access to location data before posting any it finds in a picture), it's probably not intentional. The app probably simply tries to always extract and post location information from EXIF data which happens to be present when the picture was taken with the Camera app, even when Path has been denied access to location information. Seems like more of an oversight than someone intentionally writing code to overrule user preferences.

The point being, while this may be a bit of sloppy coding (e.g., not checking to see whether the app has access to location data before posting any it finds in a picture), it's probably not intentional. The app probably simply tries to always extract and post location information from EXIF data which happens to be present when the picture was taken with the Camera app, even when Path has been denied access to location information. Seems like more of an oversight than someone intentionally writing code to overrule user preferences.

Sloppy coding yes, but actually the issue is within Apple's APIs. If your intent is not to share location data with an app, then Apple's API should be stripping location data from any data it passes to that app, including photos.

This boils down to both Apple and Path not seeing the big picture (outside of the odds Path did this intentionally).

While Path has definitely had its share of privacy problems, some of the comments here don't seem to be well thought out.

Of course Path has within it code to parse and post location data from photos, some people want this feature and specifically choose to allow Path to access location data. There is no setting within the Path app that allows people to enable/disable the posting of location information from photos. Instead, users choose whether to allow Path access to location data on a system level, just like with any other app on iOS.

My guess is, and this is clearly a guess but makes sense from my point of view, that whenever a photo is loaded into Path it tries to access and post the location data. When Path has been denied access to location data the pictures it takes using the in-app camera don't contain location in the EXIF data so this attempt fails silently and nothing is posted. The Camera app on the iPhone, however, has its own setting for whether or not to allow access to location data. Most users, whether they're aware of it or not, allow the Camera app to access location data and so any pictures taken with that app will have location information in their EXIF data.

So…when a user selects a photo from their photo library to share on Path instead of using the built in Path camera, that photo may have location information contained in its EXIF data. Path then happily parses and posts this as if it was supposed to be there.

The point being, while this may be a bit of sloppy coding (e.g., not checking to see whether the app has access to location data before posting any it finds in a picture), it's probably not intentional. The app probably simply tries to always extract and post location information from EXIF data which happens to be present when the picture was taken with the Camera app, even when Path has been denied access to location information. Seems like more of an oversight than someone intentionally writing code to overrule user preferences.

You can call it many things but sloppy coding its not, it's on purpose coding.

The point being, while this may be a bit of sloppy coding (e.g., not checking to see whether the app has access to location data before posting any it finds in a picture), it's probably not intentional. The app probably simply tries to always extract and post location information from EXIF data which happens to be present when the picture was taken with the Camera app, even when Path has been denied access to location information. Seems like more of an oversight than someone intentionally writing code to overrule user preferences.

Sloppy coding yes, but actually the issue is within Apple's APIs. If your intent is not to share location data with an app, then Apple's API should be stripping location data from any data it passes to that app, including photos.

This boils down to both Apple and Path not seeing the big picture (outside of the odds Path did this intentionally).

Apple can do one thing easy get rid of Path from the Appstore, i'm sure somewhere in the dev agreement there is a clause about not being a criminal (hacker).

The people who think this isn't just sloppy coding clearly have never programmed themselves. It's obvious the location tagging is done server-side, but the 'Location' flag is done in the smartphone program. Clearly an oversight, and one that's very easily fixed (Path strips out EXIF data when the Location is set to off in the program).

This isn't something they coded *extra*, it's very much a sin of omission.

Easy with the pitchforks, folks. Path just lets you share photos of your choosing. If the Camera app you used embeds location data in the picture that you choose to share, that's because it's the default behavior and you haven't turned it off.

If you don't want the Camera app to do that, go into your location settings, click on "Camera", and turn it off. And stop looking for a scapegoat. For some of you, it wouldn't hurt to take some responsibility for yourselves, for a change.

I don't know or use Path, but I also think that Apple shouldn't let apps have access to exif gps data on photos if those apps aren't allowed to use location services by the user. Apple should close this loophole soon.

The only way to prevent that would be to remove direct access to photos and only letting them be accessed through a form of "wrapper" that can strip exif data on-the-fly, or prohibit apps from using built-in methods for extracting/parsing exif data.

Don't see how either one would be realistic in the long run.

I don't see why this is unrealistic at all; it's very easy to strip EXIF tags from JPEG image data. iOS should provide APIs to access images with or without the extra location data.

Currently, the two always come together. That's why apps that access the camera roll trigger a popup warning about your *location*, which is actually pretty unintuitive (and scary, if you don't know the reason).

If you don't want the Camera app to do that, go into your location settings, click on "Camera", and turn it off. And stop looking for a scapegoat. For some of you, it wouldn't hurt to take some responsibility for yourselves, for a change.

There's a difference between wanting your images geotagged, and wanting to share that information with Path (or any other app). I agree that this one is likely to be an accident, but it's certainly not the user's fault.

I don't know or use Path, but I also think that Apple shouldn't let apps have access to exif gps data on photos if those apps aren't allowed to use location services by the user. Apple should close this loophole soon.

The only way to prevent that would be to remove direct access to photos and only letting them be accessed through a form of "wrapper" that can strip exif data on-the-fly, or prohibit apps from using built-in methods for extracting/parsing exif data.

Don't see how either one would be realistic in the long run.

I don't see why this is unrealistic at all; it's very easy to strip EXIF tags from JPEG image data. iOS should provide APIs to access images with or without the extra location data.

Currently, the two always come together. That's why apps that access the camera roll trigger a popup warning about your *location*, which is actually pretty unintuitive (and scary, if you don't know the reason).

Right, so they install a "filter" on the file access level for exif geotags, then others wants it expanded for other tags and to other file formats and soon we'll have hundred or so of these individual security pop-ups for different "extra" file info/tags. And the more pop-ups there is the more people (in general) will be conditioned to just press allow without reading what actions they allow, especially with the possibility that apps say that they won't function at all unless they get access to something that actually isn't needed for it's functionality (ehm, twitter "confession").

One thing I would immediately change would be in the policy and that would be that apps with their own setting for this must honor the system wide setting if set to disabled unless specifically set by the user (and no, accepting defaults at the first startup would not suffice).

I don't know or use Path, but I also think that Apple shouldn't let apps have access to exif gps data on photos if those apps aren't allowed to use location services by the user. Apple should close this loophole soon.

The only way to prevent that would be to remove direct access to photos and only letting them be accessed through a form of "wrapper" that can strip exif data on-the-fly, or prohibit apps from using built-in methods for extracting/parsing exif data.

Don't see how either one would be realistic in the long run.

I don't see why this is unrealistic at all; it's very easy to strip EXIF tags from JPEG image data. iOS should provide APIs to access images with or without the extra location data.

This sounds like extremely bad engineering, bordering on the absurd.

Once you take a photograph which has geotagging in the EXIF, that information is *a property of the photograph*. It is then your responsibility to share that photograph wisely.

Should Apple also automatically detect if a photo includes your street name somewhere in it, and offer to strip that information? Should they implement face detection and automatically blur faces if you have privacy mode turned on? Maybe they should do automatic nudity detection, since if you share your intimate photos of you and your partner it's obviously the operating system's fault for not preventing you via some privacy option.

If you take photos with geolocation data attached, it's because you wanted to share geolocation with those photos. Do so wisely. If you do not wish to do this, don't take photos with geolocation attached.

And if you want to do both, invest in a tool to strip the EXIF data - maybe Apple should provide a means to do this, that seems vaguely sensible. That way you can stop the bad guys knowing what aperture you were shooting with as well, before someone demands an API to prevent sharing that information too.

Trying to implement it at API level seems messy and ill thought through at best. How many ways are there to get data into an iOS programme? Since an image file is just 'bytes', I presume you don't have to use image APIs to access them. When, say, 'Dropbox' downloads an image from my cloud storage, is iOS now meant to step in between, determine if the data looks like it might be an image, and then do processing on it before the App gets a chance to look at it?

Are we to outlaw any programs that are capable of reading and writing image files, because The One True Way is going to be via an API that enforces a privacy setting that is specific to that filetype? This means of course outlawing programs that can read and write any file type, unless they use a separate type-specific API, because if you let programs read-and-write arbitrary data, they can just decode the EXIF themselves in files that look like photos.

So basically we've killed Dropbox and any programs similar to that. We've killed any Office type programs, unless their filetype is supported by a specific system API (so Pages probably OK, Microsoft bummed.) We've killed any art or graphics type programmes that may want to use a file format other than the ones offered by the system API (to support layers and the like.)

In fact we've killed a whole raft of software, just so one shitty programme cannot be permitted to access data directly, but has to go through filetype specific APIs, just in case users have been stupid enough to feed it an image with EXIF data that they chose to include when they took the photo.

A good way to think 'is this security kneejerk reaction a good idea or not' is not to think 'does it solve the problem I'm kneejerking to,' it's to think 'how does this affect the operation of perfectly legitimate programs.' This idea fails it on so many levels.

While Path has definitely had its share of privacy problems, some of the comments here don't seem to be well thought out.

Of course Path has within it code to parse and post location data from photos, some people want this feature and specifically choose to allow Path to access location data. There is no setting within the Path app that allows people to enable/disable the posting of location information from photos. Instead, users choose whether to allow Path access to location data on a system level, just like with any other app on iOS.

My guess is, and this is clearly a guess but makes sense from my point of view, that whenever a photo is loaded into Path it tries to access and post the location data. When Path has been denied access to location data the pictures it takes using the in-app camera don't contain location in the EXIF data so this attempt fails silently and nothing is posted. The Camera app on the iPhone, however, has its own setting for whether or not to allow access to location data. Most users, whether they're aware of it or not, allow the Camera app to access location data and so any pictures taken with that app will have location information in their EXIF data.

So…when a user selects a photo from their photo library to share on Path instead of using the built in Path camera, that photo may have location information contained in its EXIF data. Path then happily parses and posts this as if it was supposed to be there.

The point being, while this may be a bit of sloppy coding (e.g., not checking to see whether the app has access to location data before posting any it finds in a picture), it's probably not intentional. The app probably simply tries to always extract and post location information from EXIF data which happens to be present when the picture was taken with the Camera app, even when Path has been denied access to location information. Seems like more of an oversight than someone intentionally writing code to overrule user preferences.

Never attribute to malice what can be adequately explained by stupidity.

Its true that Path does not strip EXIF information from the pictures you post. In addition it allows people to download a copy of your picture. Any picture you post from work or home exposes your exact address.

As you can see from the screenshot, even with Location Services disabled it is picking up the fact that I'm in Philadelphia. This can only be accomplished by actively coding the app to extract that information from the picture and use it to insert location information in the original post.

This can also be seen in the "RePath" feature. When you repost someone else's picture, Path automatically switches your location to that of the picture you just reposted.

In other words, it is a deliberate circumvention of a person's privacy settings, and not just sloppy coding or an oversight.

I don't use Path anymore. I don't like the way the company operates at all — but I understand why they do it. Apple makes it worse by actively encouraging companies like Path to ignore Apple's user privacy rules, one of which specifically states that an app will get banned for collecting data from the address book without telling the owner. Guess what, last year Path was caught uploading your entire address book to their servers and Apple never followed through on their own rules for banning software from the app store. In fact, Apple never addressed the issue at all. Apple's silence and lack of disciplinary action against Path for such an offence sends out a clear message to all developers: "Our rules are toothless, go ahead and break the rules, we won't follow through on threats to remove your app".

And guess what? Here we are a year later and Path is still breaking their privacy rules and Apple remains silent and won't remove Path from the app store. It's quite unnerving.

The only stand Apple takes is against porn, and even then they only target high profile apps every so often as a placebo on the public psyche.

But I think the issue of stealing personal data goes beyond Path. Facebook and Google are the worst offenders and they get away with it by constantly updating their terms to invalidate the previous terms through new wording. In the end there isn't much that either of those 2 companies knows about us. It's no wonder companies like Path are following their playbook — they're getting away with it and becoming mega-billion dollar companies in the process so why shouldn't they?

I removed Facebook from my iPhone and I don't use Google app on it either. When v2 of Path was released I saw it as a way to stay connected to my friends without giving up my identity and location. When I discovered Path was no different than Facebook and Google I quickly removed the app and requested that my account and data be removed from their servers (something I doubt they ever did).

As a result of this I simply don't use social apps on my iPhone to the best of my ability. But the writing is on the wall, our identities are commodities and our location, friends and family data are open game. No company in this day and age can ever hope to become as large as Facebook or Google without stealing the data on your phone and forcibly growing their network as fast as possible. And Path is growing very well on stolen data, and getting away with it using the age old practice of playing dumb.

it is a deliberate circumvention of a person's privacy settings, and not just sloppy coding or an oversight.

I'm sure John McAfee gave the Vice reporters a pass when they disclosed his location through EXIF data, too: blame it on the software, not the users -- right?

Path does nothing to /determine/ your location, and the fact that their client software clearly indicates existing meta data in shared images (rather than ignore it despite its presence and ease of access to anyone who wants it) has long been considered a feature. While they are in a position to help educate and further protect users from themselves (and are releasing an update to do just that), it isn't an indictment against them that they haven't already done so.

Software evolves -- that's the nature of it. It does not come out fully formed, with every bit of usefulness predetermined. Users shape it. Despite that reality, the sense of entitlement exhibited by some people using free software boggles the mind.

Frankly, the headline of this article reads much more like something from The Register than Ars (which isn't a knock on either so much as an observation about how they have always had different objectives). That is disappointing.

I don't see why this is unrealistic at all; it's very easy to strip EXIF tags from JPEG image data. iOS should provide APIs to access images with or without the extra location data.

This sounds like extremely bad engineering, bordering on the absurd.

Once you take a photograph which has geotagging in the EXIF, that information is *a property of the photograph*. It is then your responsibility to share that photograph wisely.

Should Apple also automatically detect if a photo includes your street name somewhere in it, and offer to strip that information? Should they implement face detection and automatically blur faces if you have privacy mode turned on? Maybe they should do automatic nudity detection, since if you share your intimate photos of you and your partner it's obviously the operating system's fault for not preventing you via some privacy option.

If you take photos with geolocation data attached, it's because you wanted to share geolocation with those photos. Do so wisely. If you do not wish to do this, don't take photos with geolocation attached.

The key difference is that geolocation metadata is invisible. I agree that it's not the OS's job to analyze your photos for "private" content or anything -- that is absurd, for sure. But I don't agree that taking photos with geotags means that you want to share the image with the location included, especially if you don't know that it's happening. (Say, if you disabled location services for Path ...)

Similarly, it's not the OS's job to police all access to data everywhere in the system. I'm merely suggesting that apps should have a way to request access to photo library images without location data if they don't need it, that's all.

I don't see why this is unrealistic at all; it's very easy to strip EXIF tags from JPEG image data. iOS should provide APIs to access images with or without the extra location data.

This sounds like extremely bad engineering, bordering on the absurd.

Once you take a photograph which has geotagging in the EXIF, that information is *a property of the photograph*. It is then your responsibility to share that photograph wisely.

Should Apple also automatically detect if a photo includes your street name somewhere in it, and offer to strip that information? Should they implement face detection and automatically blur faces if you have privacy mode turned on? Maybe they should do automatic nudity detection, since if you share your intimate photos of you and your partner it's obviously the operating system's fault for not preventing you via some privacy option.

If you take photos with geolocation data attached, it's because you wanted to share geolocation with those photos. Do so wisely. If you do not wish to do this, don't take photos with geolocation attached.

The key difference is that geolocation metadata is invisible. I agree that it's not the OS's job to analyze your photos for "private" content or anything -- that is absurd, for sure. But I don't agree that taking photos with geotags means that you want to share the image with the location included, especially if you don't know that it's happening. (Say, if you disabled location services for Path ...)

Similarly, it's not the OS's job to police all access to data everywhere in the system. I'm merely suggesting that apps should have a way to request access to photo library images without location data if they don't need it, that's all.

What's the big difference between an app requesting photos through this "location stripper API" and the app just ignoring location data once extracted from the photo (I assume they extract all EXIF data in one go), considering that both of them would be voluntary? It's not like they are magically forced to use it (post it in this case) if they know it.Now if there already exists some form of "streaming API" (a.k.a it does more than just serve the files location) for accessing photos then you could just adapt it a bit to take the OS level "no location" setting into regard when serving data.

If one have set "no location data" in the app itself then it should just ignore said data regardless of where and how it gets it. Preferably it should also check the OS level setting for this and use that as the default upon first run after installation (possibly upgrades as well).

The point being, while this may be a bit of sloppy coding (e.g., not checking to see whether the app has access to location data before posting any it finds in a picture), it's probably not intentional. The app probably simply tries to always extract and post location information from EXIF data which happens to be present when the picture was taken with the Camera app, even when Path has been denied access to location information. Seems like more of an oversight than someone intentionally writing code to overrule user preferences.

Sloppy coding yes, but actually the issue is within Apple's APIs. If your intent is not to share location data with an app, then Apple's API should be stripping location data from any data it passes to that app, including photos.

This boils down to both Apple and Path not seeing the big picture (outside of the odds Path did this intentionally).

Hold on. If I load a photo from my private Dropbox which had the Exif data in it, how can Apple stop that? This doesn't just affect the internal camera app, it involves photos that could come from anywhere (clipboard, other apps).

Apple cannot stop a developer from reading a file from a location available to the app. The raw file reading APIs allow you to access byte-by-byte data, meaning that Apple has no control over how the data is read, thus wouldn't know whether it was an image and that it had Exif data attached.

It was the developers responsibility to check both the users privacy settings AND the Exif data before posting.

I'm sorry. But Shit like this really should prompt a push back against Apple for a public disclosure of their approval and checks and balances process for allowing or rejecting Applications submitted to and approved for the App Store.

The time for their hidden process is over.

This has happened twice on the same App for 2 differnt things. No way to tell if this got thru to the public store because someone's personal opinion felt that this App was "cool". Where is Apple's approval process running checks on this crap ?

How does the rest of the traditional Software Industry hadnle a "vetting" process before a title can sit on the shelves at a brick and mortar Store ?

You don't usually walk into a Best Buy and purchase some random title that can install viruses on your friend's computers. Somehow those types of things gets stopped before Best Buy gets to sell them.

Their history of misappropriating user data aside, this does seem like it could reasonably just be a bug. To me it's plausible (and likely) they simply assumed there would be no EXIF data if the user didn't have location services turned on for the app so didn't bother checking during that bit of code. They weren't considering the edge case of someone importing photos into their app that had the data.

This being said, who feeds geotagged photos into an app they don't trust to geotag photos taken through the app itself? It's like posting to text to Facebook and then acting outraged that Facebook now has access to that text. Super easy fix - don't do that.

Their history of misappropriating user data aside, this does seem like it could reasonably just be a bug. To me it's plausible (and likely) they simply assumed there would be no EXIF data if the user didn't have location services turned on for the app so didn't bother checking during that bit of code. They weren't considering the edge case of someone importing photos into their app that had the data.

I would rather say a design flaw since this looks to be more of a result of a design decision, that is not having a "just in case" check before posting location based data.

Quote:

This being said, who feeds geotagged photos into an app they don't trust to geotag photos taken through the app itself? It's like posting to text to Facebook and then acting outraged that Facebook now has access to that text. Super easy fix - don't do that.

Maybe they thought they didn't have geotags? It's not like they are clearly marked as having geotags (or any other form of EXIF data) in them.