On September 1, CNET’s Declan McCullagh covered a claim made by security researcher Samy Kamkar involving location leakage on Windows Phone. More specifically, Kamkar claimed Microsoft was intentionally collecting Windows Phone location data without user consent, spawning a class action lawsuit. Moments later, the press machine worked its magic and it was in the headlines everywhere. But where’s the data?
I read all the incomplete news stories on the matter and not one provided Kamkar’s actual report. I was forced to register with the Western District of Washington's Public Access to Court Electronic Records (PACER) system to get the case files and exhibits, perhaps explaining why the other reporters omitted it from their stories. But you can download the complaint, summons, exhibit A and exhibit B below.
After opening Kamkar’s report (exhibit B), I immediate noticed how skimpy it was. It’s 9 pages total, breaking down to 1 title page, 3 pictures of photos, and less than 5 pages of useful text. Not a good sign.
It starts off with:
When using the prepackaged “Camera” application on a mobile phone running Windows Phone 7, upon initially accessing the Camera application, the phones asks whether you wish to share your location. When hitting “cancel” to prevent your location information from being shared, the phone continues to intermittently transmit information from wifi [sic] networks and cellular towers to a host owned by Microsoft Corporation, leading to the user’s location.
Kamkar is referring to the “Allow the camera to use your location” dialog, which only appears once per reset.
Claim 1: The phone continues to transmit location data after a user taps Cancel.
“Allow the camera to use your location?” dialog on Windows Phone OS
In addition, the phone begins sending location information while the location sharing dialog is open before the user has a chance to allow or disallow the sharing of this location information.
Claim 2: The phone begins transmitting location data while this dialog is open.
Kamkar continues, noting his test environment. He used an AT&T-tethered Samsung Omnia 7 with both NoDo+SSL and RTM as the target OSes. But there are a few problems with this:
- The Samsung Omnia 7 is not a US phone and is not sold by AT&T. (He notes the physical location of the device as Hollywood, CA.)
- AT&T has not pushed the SSL update to most devices, certainly not to this unsupported device.
I understand there are a number of scenarios that could apply here, like having a carrier-unlocked phone, manually installed updates, etc. but the point is this: These devices aren’t representative of retail devices or of actual retail configurations.
Kamkar repeats his summary, talking to user expectations regarding the Allow/Cancel button:
If the user hits “allow”, the phone continues to the camera application and continues to send location info, as expected. However, if the user hits "cancel", the phone continues to the camera application, however will intermittently send location information to a domain owned by Microsoft Corporation.
Don’t get me wrong, his claims could be valid. I have yet to test them. But here’s my initial reaction to this – The dialog is asking the user if they want the camera to use your location. This isn’t a platform configuration dialog. Microsoft isn’t asking if I want the phone to transmit data on a whole. It’s asking if I want the camera to associate my location – gathered via whatever other means – with images (geographic metadata). Tapping the Cancel button here, to me, reads “don’t add tags to my images”.
Kamkar continues with packet dumps of communication between the phone and Microsoft’s Location Inference (codenamed Orion) service. They look legit, but what strikes me as odd is the service being accessed:
POST /InferenceService/v21/pox/GetTileUsingPosition – HTTP/1.1
It appears Kamkar is confusing packets sent around the same time as packets sent from the Camera application. I don’t see a clear link between these packets and the application, but again have yet to test it out for myself. Point is – why isn’t this link clarified/explained in the report?
Following the packet dumps is a listing of the elements found in the packets (the protocol is xml-based) and his guesses about what the data within represents. Nothing particular interesting or surprising, although from my prior research in the development of ChevronWP7 Labs I can tell you that Microsoft goes out of its way to mask hardware IDs. For example, GetDeviceUniqueID protects the privacy of a device by providing applications with a hashed version of the real deal. (This is something Apple is just now getting around to.)
That’s it. That’s the entire report. It makes me wonder how this story is grabbing headlines.
When I get some down time – the timing of this couldn’t be more awful with BUILD – I’ll try to test and prove/disprove Kamkar’s claims. Stay tuned. Possible spoiler: I briefly tested this on my Samsung Focus and couldn’t validate Kamkar’s claims. This appears to be in line with Microsoft’s thinking thus far:
Microsoft recently learned of a claim that when a user uses the camera on a Windows Phone, the phone sends data about nearby cell towers and Wi-Fi access points to Microsoft’s location positioning database, when the user has declined to geo-tag photos upon first use of the phone’s camera. Microsoft is investigating this claim. We take consumer privacy very seriously. Our objective was—and remains—to provide consumers with control over whether and how data used to determine the location of their devices are used, and we designed the Windows Phone operating system with this in mind.
As further described in the following FAQs, Windows Phone doesn’t store or use any unique device identifiers or other data that personally identifies you or that would allow tracking or creation of a location history of your device in connection with Windows Phone’s location services. Because of this, any receipt of location data from the Windows Phone camera would not enable Microsoft to identify an individual or “track” his or her movements.