|
|
| (4 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| ==Privacy==
| | [https://location.services.mozilla.com/privacy Mozilla Location Service Privacy Policy] |
| | |
| Location information is a sensitive topic and there are many privacy concerns in this area.
| |
| | |
| At the heart of a geo-location service lies it ability to report back the physical location of a user, based on public signal sources around the user. This is an exchange of very private and sensitive data, so we must do our utmost to protect this exchange and minimize the risk of tracking users across multiple service requests or uniquely identifying users in any way.
| |
| | |
| In addition to the service user, we need to protect the operators of public wifi networks, respect their privacy choices and enable them to opt-out of our service.
| |
| | |
| Privacy concerns for specific technologies: | |
| | |
| ===Cell towers===
| |
| | |
| Cell towers are understood to be public radio signal sources, and there are no privacy concerns known to us. We'll only use metadata information about the available cell towers and networks and never any actual network traffic.
| |
| | |
| ===Wifi===
| |
| | |
| While Wifi networks send radio signals into the public space, different countries have very different views on the privacy aspects of them.
| |
| | |
| For the purposes of the geo-location service we are only interested in the public metadata about wifi networks, specifically the technology standard in-use, the frequency it's operated on, the signal strength, the technical network name (bssid) and clear text network name (ssid). We'll never listen in or record actual network traffic.
| |
| | |
| For the wifi operator to opt-out, we follow the industry standard of filtering out any wifi networks with a clear text name (ssid) ending in '_nomap' and ignore any ad-hoc wifi networks. Both of these filter actions happen on the client side, so our service never sees them.
| |
| | |
| For all other wifi networks, our client software creates a cryptographic hash out of the bssid and ssid and sends it to the service.
| |
| | |
| Using a hash which includes the SSID, allows anyone to change the SSID and thereby invalidating all our records relating to any specific wifi network, while still being able to contribute to the service in the future under the new hash key.
| |
| | |
| We'll take additional measures to avoid the possibility of looking up any single hash. This avoids the scenario where someone can record the wifi hash for a users phone and use this to lookup that persons physical location over time. Measures include only answering service requests for which at least two co-located wifi hashes are provided.
| |
| | |
| ===IP addresses===
| |
| | |
| In the future we might want to use Geo-IP based lookups to enhance or provide coarse-grained fallback for the service. Before we do this, we'll do a thorough analysis of the involved risk, as the combination of IP address and time of service usage can uniquely identify users.
| |