Anybody who has read this blog probably already knows my reaction to the news that Google has mapped wi-fi networks across the country (or several countries) as described here. It’s intended for commercial purposes – I totally dig it! Where I can stop and use my phone to browse the web without running up a bill? Cool! Tell me where the closest T-Mobile hotspot is. Groovy! Find me a strip club with free wi-fi (not kidding). Bitchin’! And it works as promised – I’d recently used a site that knew I was hanging out at <plug>Satellite Coffee</plug> in Albuquerque on their free wi-fi via this feature.
So what’s the big deal? Why are people getting all uppity about this public data collection? Wireless network SSIDs that are broadcast are public – you can’t expect to keep something private that you know is public. It’s like dressing in drag – you can’t exactly insist that people don’t take video of you dancing on the bar. So I’m told.
Well, maybe I’m late to the party, but I’ve just stumbled across something that’s swinging me over to Team Privacy. (please note: this rant is NOT about the snippets of drive-by packet content that have been collected, it’s ONLY about the access point info they’re collecting. That’s material for an0ther rant with an entirely different argument)
Quick background: HTML 5 is introducing a geolocation API specification. The idea is that it’s a client-side request made by the browser after the user blesses the function with a click of an OK button. It’s already implemented by the iPhone and Firefox (among others). In phones, the call is a hook to the gps system. In desktop browsers, it’s done differently by different vendors.
… So there I was, sitting in my corner office on the top floor of the Jovian Enterprises global headquarters, working on a nifty little mobile web application that brings geolocation capabilities to the escort industry, reading up on how to use the geolocation API. Simply call navigator.geolocation and presto, you get a location object returned. Use it to render whatever location-specific content you’ve got up your sleeve via another ajax call. Sweet – distance to the nearest incall coming right up!
But how exactly does the browser know where I am, anyway? Apparently, Firefox uses a geolocation provider to get the longitude and latitude. Guess who? Yep – Google.
Firefox 3.5 includes support for locating you based on your WiFi information using Google Location Services. In the transaction between Firefox 3.5 and Google, data is exchanged including WiFi Access Point data, an access token (similar to a 2 week cookie), and the user’s IP address.
– mozilla.org
“WiFi Access Point data”? WTF do you think that is? I’m a pretty adept googler, and couldn’t find anything, so it’s wireshark time. First capture showed the connection to Google was SSL – how nice of them, protecting what has been proclaimed as PUBLIC DATA (using SSL here seems like an admission of guilt, but that’s a topic for another rant). I don’t have a man-in-the-middle ssl proxy on hand, so I dug through Firefox’s about:config page full o’ magic, and removed the “s” from the geo.wifi.uri setting, leaving http://www.google.com/loc/json. Back to wireshark, and http post data shows up as:
{
"version":"1.1.0",
"request_address":true,
"access_token":"2:L23ADSJfdelxVrIu:6KzjqSfXQIFOzB57",
"wifi_towers":
[
{"mac_address":"00-1e-8d-0l-mn-0p","ssid":"JovianHQ","signal_strength":-68},
{"mac_address":"00-24-00-52-47-fe","ssid":"Bills","signal_strength":-87}
]
}
That’s a JSON formatted data string of an anonymous hash (and yes, it’s been altered and it won’t return anything). Interestingly, both my SSID and my neighbor’s SSID are listed, with signal strength. And MAC addresses. Access_token is described as the equivalent of a two week cookie. “Request_address” is interesting, though. On to the response:
{
"location":
{
"latitude":34.076243,
"longitude":-118.429224,
"address":
{
"country":"United States",
"country_code":"US",
"region":"MY STATE",
"county":"MY COUNTY",
"city":"MY CITY",
"street":"! MY STREET !",
"street_number":"!! THREE HOUSES UP !!",
"postal_code":"MY ZIP"
},
"accuracy":150.0
}
}
Holy crap! That’s a ton of information, and it’s really close to being dead-spankin’ on. It’s literally three houses up from my house, on the same side of the street no less! What application would ever need my street or (incorrect) house number?? So my browser now has all this information – I’m sure it wouldn’t all be shared with the web site, would it…? Yep, it goes right on back to the script as attributes of the location.address object. Well at least we’ve still got the security provided by the forced user interaction with the feature (you know, the same kind of security provided by the browser through incomprehensible SSL warnings and negative questions). Phew! At least we still have that!
Or do we?
The draft says that the browsers must not send location information to the calling websites without explicit user permission. Except:
Some user agents will have prearranged trust relationships that do not require such user interfaces. For example, while a Web browser will present a user interface when a Web site performs a geolocation request, a VOIP telephone may not present any user interface when using location information to perform an E911 function.
Oh, look – there’s NO required security! According to the W3C standard, there’s a “prearranged trust” – also known as a way to avoid security checks and still be standards-compliant. And since there’s none here, there’s likely none at the location provider. So I tested the location provider by sending the same “cookie” and request that I sent from my desktop a few hours ago from a server out in New Jersey and get the same results. Grrrr.
Let’s look just a teensy bit deeper on who’s fault this is.
- Browsers are implementing a feature that allows the browser to read system data when requested by a website script. This isn’t anything that any other user-installable program can’t do, so no big problem there. Tie score.
- This collected data gets sent to a location provider (Google, in this case). Google doesn’t authenticate that the request comes from a licensed partner application (i.e., approved browser). Strike one for Google.
- Then Google dumps LOTS of information back to the browser. Strike two for Google.
- Then, like a well-mannered program, the browser hands ALL that data back to the website scripts without telling the user what exactly it was. Strike one for the browser.
- But the browser has the ability to shut it off completely, but de facto location provider Google does not have an opt out. Strike three for Google.
Final score: Browser -1, Google -3. Yes, I know there are mixed sports metaphors here, just deal with me. One redeeming factor in this data transaction: the website never gets my SSID or my access point’s MAC address – that stuff only goes to google.
Suggested fix:
- Location providers (Google) should authenticate partner applications. Perhaps cryptographically, since there’s already an SSL handshake going on?
- Location providers (Google) should limit the data fields returned depending on the authenticated application.
- Partner applications (Browsers) should alert the user and ask to approve ALL of the returned content per website. Possibly a popup with checkboxes saying “select the information you’d like to share”.
- Location providers (Google) should offer an opt out.
- Bonus (previously undiscussed) suggestion: A user should be able to register their ”home” location with their phone and automatically disable geolocation features within a certain radius.
Am I over reacting? Is it really tinfoil hat time? Let me know your thoughts – I’ll be down in the underground bunker with the blankets pulled up over my head.