Camera leaks GPS location info when used from pick activity

RESOLVED FIXED

Status

Firefox OS
Gaia::Camera
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: st3fan, Assigned: daleharvey)

Tracking

({verifyme})

unspecified
x86
Mac OS X
verifyme
Bug Flags:
in-moztrap -

Firefox Tracking Flags

(blocking-b2g:tef+, b2g18 fixed, b2g18-v1.0.1 fixed)

Details

(Whiteboard: QARegressExclude)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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)
(Reporter)

Comment 1

5 years ago
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
blocking-b2g: --- → tef?
(Reporter)

Comment 3

5 years ago
(In reply to Dale Harvey (:daleharvey) from comment #2)
> I assume this should block, its a simple low risk fix

What is the fix?
Created attachment 712893 [details]
Pointer to GH PR

Just not attach the GPS details when taking a photo from an activity

I dont think there is any other sensible way around this.
Attachment #712893 - Flags: review?(dflanagan)
(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?

Comment 6

5 years ago
Sid - we don't want to block unless this is a critical privacy concern. Can you help make that decision?
Flags: needinfo?(sstamm)
(Reporter)

Comment 7

5 years ago
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.
Attachment #712893 - Flags: review?(dflanagan) → review+
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)

Updated

5 years ago
blocking-b2g: tef? → tef+
Flags: needinfo?(sstamm)
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
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Reporter)

Comment 13

5 years ago
(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
status-b2g18: --- → fixed
status-b2g18-v1.0.1: --- → fixed

Comment 15

5 years ago
John / Dale - Could you describe how the fix works here in this bug?
status-b2g18: fixed → ---
status-b2g18-v1.0.1: fixed → ---
We do not include GPS information when the camera is asked by another application to take a photo (irregardless of what application it was)

Comment 17

5 years ago
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.
status-b2g18: --- → fixed
status-b2g18-v1.0.1: --- → fixed

Updated

5 years ago
Flags: in-moztrap-

Updated

5 years ago
Whiteboard: QARegressExclude

Comment 19

5 years ago
Cannot verify, need steps to blackbox test this issue.

Updated

5 years ago
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.