Open Bug 874916 Opened 7 years ago Updated 8 months ago
Provide manual Wi
Fi opt-out process from database
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 :)
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...
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.
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.
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.
Summary: Provide manual wifi opt-out process → Provide manual WiFi opt-out process from database
This is still an interesting idea, but clearly not a blocker.
No longer blocks: 862827
You need to log in before you can comment on or make changes to this bug.