Re: Opt-out for wifi network of the Google Location Server

* Thomas Roessler wrote:
>On 2011-11-27, at 12:51 +0100, Bjoern Hoehrmann wrote:
>
>> The malicious opt-in problem exists whether or not you filter networks
>> on the client, and that would be taken care of in the same way that you
>> prevent poisoning the database with other false information, like not
>> having information that comes too infrequently or from too few sources.
>> Note that the "reliable channel" does not seem to be required to opt in,
>> they could require that to protect against this, if that actually helps.
>
>So, I'm honestly having a hard time seeing the "malice" here.

Well, maybe some code helps. With the Google Gears protocol, when you
want to know your current location, your browser would send something
like the following to a Google server:

  {"version":"1.1.0",
   "wifi_towers":[
     {"mac_address":"11-22-33-44-55-66",
      "ssid":"Thomas",
      "signal_strength":-60,
      "age":2.0},
     {"mac_address":"aa-bb-cc-dd-ee-ff",
      "ssid":"Bjoern_nomap",
      ...

The "Thomas" network will end up in the Google database and the other
network will not because it uses "_nomap". Nicholas Doty suggested you
might hack your browser so it removes the "_nomap" string before it
sends this data to Google, likely meaning the network will end up in
the Google database even though the network operator clearly indicated
they do not want that, and if you do that a lot then you might be re-
moving the network operator's ability to opt-out. That's malicious if
there is some consensus that they should have this option.

>I can see several nearby things a provider like Google could do that
>would rightly make people freak out: Collecting arbitrary MAC addresses
>(and thereby being able to do movement profiles of mobile devices that
>they aren't able to track otherwise)

We are talking about exactly that. My smartphone for instance came with
a built-in option where I can tell it to be an access point and broad-
cast its SSID and MAC address so I can connect my Netbook over the air
and over the mobile phone to the Internet, for instance. There isn't an
option to somehow hide the network while still allowing me to do this.

So if I do this, and someone nearby happens asks their browser to find
out where they are, based on nearby networks, they would end up telling
some geolocation service provider where my mobile phone is at that mo-
ment. The service provider would store this information and when this
happens a lot, the service provider would have a movement profile.

With Google's "_nomap" proposal this would be the same, except that in
case of Google, the information would only be stored due to a bug or a
policy change. With my proposal, the nearby browsers would not use any
"_nomap" networks to determine their location, so no service provider
would learn of them or their location, assuming universal adoption.

>But assuming we're only talking about access points that publicly
>broadcast their SSID: Why are you actually worried about that?

You can't really run an IEEE 802.11 network without exposing SSIDs and
"access point" is just a mode a network interface might be running in,
my smartphone can be an access point, my netbook can, I have a 10 EUR
USB stick that can do it. There are other modes, like the ad-hoc mode,
but browser currently do not filter those out and you would not want to
run most networks in this mode for security reasons among other things.

There is the option to operate a non-broadcast "hidden" network, which
has largely been discredited as a security measure. It's likely that a
"hidden" network would not be reported to service providers, but using
that is rather inconvenient and degrades network performance; and my
smartphone for instance doesn't support it. So, access points that pub-
lically broadcast their SSIDs is "all wireless networks" pretty much.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Sunday, 27 November 2011 15:04:06 UTC