Security/Reviews/GeolocationWebAPI

Item Reviewed

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

• currently designed or mobile usage
• can convert geo data to things like addresses
• on iOS and Android this is built in
• this keeps a 3rd party geo-coder from being neccessary
• the feature can take a set of coordinates and turn that into useful data
  • this does not have to be the users current location
• sec-review requested as they want to avoid a persistent user prompt

What solutions/approaches were considered other than the proposed solution?

• these are new features

Why was this solution chosen?

• parity with other phone/mobile platforms
• want to allow this for web content

Any security threats already considered in the design and why?

`

Threat Brainstorming

• If this feature has a prompt, users could be confused between this and geolocation.
  • This feature probably won't have a prompt; it's not about collecting new data from the user.
• Web site takes advantage of Mozilla's relationship with Google to get reverse geocoding info that has nothing to do with the user or the user's current location, and then Google gets mad. (A distributed attack against the service provider, using Firefox users as a proxy.)
  • There will be a rate limit of some sort.
  • There are plenty of such services on the web.

Privacy concerns

• We should ensure the data is encrypted on the way to the reverse-geocode server, because it is often sensitive data (the user's current location).
  • This is up to the OS :/
    • How secure is Android's implementation? Nokia's? Does the OS API have a "please be secure" flag?
• Likewise, we should ensure the service provider has a really good privacy policy, because users (and web sites using the API) won't be thinking about the fact that they're giving their current location to an additional service provider.
  • How is this different from the "map a wifi-ID to a location" service that we're also using?
• Cache probing could be a privacy issue. If the cache is fast, that probably means the user has been there.
• Cache could also be a fingerprinting (hidden-cookie) issue.

Action Items

Time Permitting: https://bugzilla.mozilla.org/show_bug.cgi?id=738131 > Light Sensor

• detects amount of light and can dim screen in comparison to ambient light
• example: netflix/hulu dims part of the screen
• scares jesse: there might be sensitive data on part of the screen. especially bad if the site can magnify or partially-obscure the data.
  • e.g. link visitedness, or the filename in a file upload control
  • probably not a big deal for text-message notification, since the site can't magnify it
  • could we instead give sites a CSS selector, :dark and :bright, just like :visited and :link, that allows the site to change colors but not see them. this would work great for netflix/hulu, but we might not anticipate future use cases.
• will need the ability to disable the feature
  • about:config? more user-facing?

https://bugzilla.mozilla.org/show_bug.cgi?id=738465 > Proximity Sensor

• notices if a "face" is near the phone to disable the screen (not NFC)
• will need the ability to disable the feature