874916 - Provide manual WiFi opt-out process from database

Status: RESOLVED WONTFIX

(Cloud Services :: Server: Location, enhancement)

Description

[Hanno Schlichting]

Once we start collecting wifi data, we need an opt-out process. We are going to support the _nomap postfix approach and won't collect data for wifi's with hidden ssids.

But in addition we should have a manual process for removing wifi data from our dataset.

One challenge here is that there's no way for anybody to proof that they are the owner of any wifi. Any software we write to check wifi's close to a user could easily be tricked by virtual network interfaces or machines.

For the main API we rely on "the masses" to provide correct data and drown out any minority of falsified submissions. But an explicit user opt-out is by its very nature a single user action. So it would be easy to spam us with opt-outs.

So any process likely needs manual intervention and checks to ensure we are actually talking to a real person. Unfortunately the kind of person that doesn't want to be tracked, is also likely a person that doesn't want to provide us with email addresses or any other means of identification.

Suggestions welcome :)

Comment 2

[Elmi]

So the service is started, data are collected and there is still no idea how to respect peoples privacy and how one can remove own WLAN from the database? Isn't this the wrong order of events? Sounds like the same procedure Google was blamed for...

Comment 3

[Hanno Schlichting]

There is an effective and industry standard way of opting out of data collection. All you have to do is to either change your SSID to have a "_nomap" suffix or hide the SSID from being broadcasted. This is what Google did and was judged to be an effective way. See for example http://www.dutchdpa.nl/Pages/en_pb_20120405_google-complies-with-Dutch-DPA-requirements.aspx. Instead of coming up with our own approach, which nobody would know about, we adopted to respect the users choices as they have been expressed towards Google and other industry players.

This bug is about going beyond what is legally required and providing an additional manual opt-out process. The challenges of that are mentioned above.

Comment 4

[Alexis Metaireau (:alexis)]

Ensuring we're talking to a real person can be easily done, by having a bunch of exchanges with her (asking an email address seems acceptable here). That doesn't solve the other part of the problem: it is hard to identify the owner of a wifi network.

One potential solution is to just ignore the ownership checking part, and trust the request owners.

Having a way for any "real" person to opt-out any wifi network, via a semi-automatic process is something that could make sense. Of course, this would be subject to a moderation of the removal requests.

I would feel more comfortable with Mozilla providing a way for users to opt out via our interface rather than having something to change on their network, because it's way less intrusive.

Comment 5

[firefoxiscute]

I have two ideas:

a) Let the users wanting to opt-out submit a postal address close to the AP for deletion. Then send them a letter with an activation code. Google did this with Street View in Germany, in 2010. This doesn't destroy their privacy as their location is already known.

b) for deletion of already taken measurements, you could let the data submitters check for a _del_nomap attribute. When the service recieves SSIDs matching this attribute, it deletes all traces with the matching BSSID in a range around the location the _del_nomap entry has been recorded. To make expoits even harder, the service shouldn't default to opt-out the BSSID in the future, but still require the _nomap attribute. Otherwise an attacker could create blind spots just by sending fake _del_nomap SSID broadcasts for the APs around the attacker. You could weaken this requirement in areas with sufficient AP coverage, or when the number of opt-outs is low, removing _nomap attribute requirement for future there.
The _del_nomap attribute can be used by other services, too.

Comment 6

[Hanno Schlichting]

This is still an interesting idea, but clearly not a blocker.

Comment 7

[John Whitlock [:jwhitlock]]

I'm going to close this as WONTFIX. I've been on the project for a little over a year, and haven't seen any requests to remove a WiFi access point from the database. When there is a request, I believe it could be handled manually, and we can revisit an automated solution if the number of requests increases.

As Hanno said, and is detailed on the optout page, Ichnaea supports two methods for keeping your access point out of the database:

• Use the SSID suffix "_nomap", which will also prevent Google from indexing it and possibly other location providers
• Configure a hidden SSID.

Ichnaea takes further methods to guard your privacy:

• The Ichnaea database does not store the SSID, but instead uses the MAC Address of WiFi access points as identifiers.
• WiFi data is not published in our public downloads
• Ichnaea has a few ways to avoid leaking information about a single WiFi access point. It requires at least two WiFi access points for geolocate requests. If one is provided, or the WiFi stations are too far away from each other, Ichnaea ignores all the provided WiFi access points and falls back to other, less accurate methods.

If you were watching this bug looking for a solution, or found it because you want your WiFi removed, please see https://location.services.mozilla.com/contact for methods for contacting the MLS maintainers. You'll need to know the MAC Address of your WiFi access point, and to implement one of the methods for keeping your access point out of the database in the future.