Security/Reviews/GeolocationWebAPI

From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.

Item Reviewed

Geolocation WebAPI
Target Full Query
ID Summary Priority Status
735863 Implement navigator.geolocation.getAddress() -- RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

The given value "

http://arreth.wordpress.com/2012/03/14/ch-ch-ch-ch-changes-to-geolocation-api-specifcations-2-2/ http://arreth.wordpress.com/2012/03/13/proposed-changes-to-geolocation-api-specification/

Full Query
ID Summary Priority Status
735863 Implement navigator.geolocation.getAddress() -- RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

" contains strip markers and therefore it cannot be parsed sufficiently.

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.
  • Property "SecReview feature goal" (as page type) with input value "* 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" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
    • Property "SecReview solution chosen" (as page type) with input value "* parity with other phone/mobile platforms
    • want to allow this for web content" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
    • Property "SecReview threat brainstorming" (as page type) with input value "* 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." contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.

Action Items

Action Item Status In Progress
Release Target `
Action Items
Who bug Action By When Completed date

[NEW] new [DONE] Done [MISSED] Miss

dougt bug 742510 http://www.mozilla.org/en-US/firefox/geolocation/ "When you visit a page that requests your information, you’ll be asked before any information is shared with the requesting website and our third-party service provider." This might need to be changed to "..before your information is shared..." before release [NEW] new
curtisk Priv Review before beta [ON TRACK] ok
Full Query
ID Summary Priority Status
742510 [Security Review][Action Item]GeolocationAPI - Possible change to geo policy -- RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

The given value "

Who bug Action By When Completed date [NEW] new [DONE] Done [MISSED] Miss


dougt bug 742510 http://www.mozilla.org/en-US/firefox/geolocation/ "When you visit a page that requests your information, you’ll be asked before any information is shared with the requesting website and our third-party service provider." This might need to be changed to "..before your information is shared..." before release [NEW] new


curtisk

Priv Review before beta [ON TRACK] ok


Full Query
ID Summary Priority Status
742510 [Security Review][Action Item]GeolocationAPI - Possible change to geo policy -- RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

" contains strip markers and therefore it cannot be parsed sufficiently.

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