When a third party app issues a 'pick' activity, one of the apps that can respond to that request is the Camera app. The camera app takes a picture and then gives the calling application back a Blob containing a JPEG image of the picture just taken. This image also contains EXIF data, including GPS information. The GPS info is there even if the calling application has no permission to use the GPS. I don't think that is the right thing to do. This was a huge deal in a previous iOS release. Apple's response was to strip *all* metadata from photos picked from the gallery. (Using the UIImagePickerController) I am not sure if we should follow that, but I think we should have a discussion about the attached GPS data. Steps to reproduce: Take a picture, inspect the returned image/jpeg blob that is returned. I wrote a little app that starts a pick activity and then uses a HTTP POST to my server to upload the image that was given back to the app. I inspected that image with the exif tool and saw the following data attached: $ exif /tmp/photo.jpg EXIF tags in '/tmp/photo.jpg' ('Motorola' byte order): --------------------+---------------------------------------------------------- Tag |Value --------------------+---------------------------------------------------------- Manufacturer |QCOM-AA Model |QCAM-AA X-Resolution |72 Y-Resolution |72 Resolution Unit |Inch YCbCr Positioning |Centred Compression |JPEG compression X-Resolution |72 Y-Resolution |72 Resolution Unit |Inch ISO Speed Ratings |0 Exif Version |Exif Version 2.2 Date and Time (Origi|1969:12:31 19:00:00 Date and Time (Digit|2002:12:08 12:00:00 Components Configura|Y Cb Cr - Focal Length |4.3 mm FlashPixVersion |FlashPix Version 1.0 Colour Space |sRGB Pixel X Dimension |1200 Pixel Y Dimension |1600 North or South Latit|N Latitude |XX, XX, 8.895 East or West Longitu|W Longitude |XX, XX, 11.872 Altitude Reference |Sea level Altitude |47.400 GPS Time (Atomic Clo|12:56:08.00 GPS Date |1941:10:09 Interoperability Ind|R98 Interoperability Ver|0100 --------------------+---------------------------------------------------------- EXIF data contains a thumbnail (8781 bytes). (Redacted to not put my home location in bugzilla)

For reference, the app that I used to test this: https://github.com/st3fan/fxos-pocs/tree/master/bug-840208-camera-leaks-gps-info

I assume this should block, its a simple low risk fix

(In reply to Dale Harvey (:daleharvey) from comment #2) > I assume this should block, its a simple low risk fix What is the fix?

Just not attach the GPS details when taking a photo from an activity I dont think there is any other sensible way around this.

(In reply to Dale Harvey (:daleharvey) from comment #4) > > Just not attach the GPS details when taking a photo from an activity What about when the activity attaches an existing JPEG whose EXIF header already includes GPS data?

Sid - we don't want to block unless this is a critical privacy concern. Can you help make that decision?

See also bug 840271 which is similar but for the Gallery app. Relevant recent incident in the iOS world https://eeqj.com/20130201/path-privacy/ I think this is the gist of it: "Should Apple’s iOS allow applications for which Location Services are explicitly disabled to access location information embedded (by the iOS Camera app) in photos stored in the Camera Roll (when access to photos is granted)?"

> What about when the activity attaches an existing JPEG whose EXIF header already > includes GPS data? Do you mean when applications access photos from the gallery? Thats another issue yup

Comment on attachment 712893 [details] Pointer to GH PR A simple but perfect solution. r+ if you add a comment explaining that you are intentionally protecting privacy.

The flip side of this issue is that if we strip geolocation from images obtained from web activities, but not for regular images taken with the camera, we create a surprising and unexpected situation for the user (ie some photos are geotagged , and some not) I can see that it mitigates some privacy threats, but we will obviously be stomping on any apps use cases which actually need the geotagging. Note the user already has a way of disabling geolocation - by removing the geolocation permission from the camera in the app permissions. Its not a particularly discoverable or intuitive setting, but it exists. Or they can turn GPS off altogether, which I believe is the only source of geolocation data in v1 (so there by disabling navigator.geolocation calls - someone correct me if we are using wifi or carrier geolocation data, but I dont believe we are)

I think we need to block based on the privacy and possibly legal concern. (confirmed with Jishnu) An app that has not been given permission for location data should not have a method to access it by way of a pick activity. Is it possible to only include the GPS data when obtaining a photo from an activity (already captured, or new photo) IF the originating app for that activity has the proper permissions? (or is this a much larger/riskier change at this point)

It wont be possible / feasible to include gps data depending on the permissions of the caller, the camera app doesnt have any trusted information of who it is being called by. Addressed review comments and merged in: https://github.com/mozilla-b2g/gaia/commit/4c760023217ec7ae1a55e20993e28efe2cff6f01 This does not solve the situation where an application asks for an existing photo from the gallery that has gps, I am not sure if that is a privacy leak in the first place, but if it is will need to be a new bug

(In reply to Dale Harvey (:daleharvey) from comment #12) > This does not solve the situation where an application asks for an existing > photo from the gallery that has gps, I am not sure if that is a privacy leak > in the first place, but if it is will need to be a new bug See https://bugzilla.mozilla.org/show_bug.cgi?id=840271

v1-train@c659f78de02efff59c017f33dab0b98fb31ca03f v1.0.1@da43eff504f6aa586470863c045293ab18a083b0

John / Dale - Could you describe how the fix works here in this bug?

We do not include GPS information when the camera is asked by another application to take a photo (irregardless of what application it was)

This fix is fine for v1. We'll open a separate bug to explore the ability to offer the 3rd party app the option to ask for location data in the future (assuming that's feasible).

(In reply to Alina Hua from comment #15) > John / Dale - Could you describe how the fix works here in this bug? per comment 17, this fix is OK for v1 and is landed on the branches. Setting status flags back to previous state.

Cannot verify, need steps to blackbox test this issue.