search

w3c / geolocation

W3C Geolocation API
https://www.w3.org/TR/geolocation/
81 stars 56 forks source link

Security review: General observations #57

Closed magnus-git closed 3 years ago

magnus-git commented 4 years ago
  1. There is no option for a recipient to ask for a "fuzzy" location. A "fuzzy" location could be a location randomized within some, perhaps provided by the recipient, limits from the hosting device's actual location. Such "fuzzing" could help privacy in some scenarios. Just a suggestion.
  2. There's also no option for a recipient to ask for an encrypted version of a location. This could potentially be useful to reduce the risk of some unauthorized party accessing the response (the key could be a key negotiated by a remote recipient or similar). Also just a suggestion / idea.
  3. For E911-type scenarios, if the hosting device's location accuracy is below some threshold, it may be better not to send location information than to send erroneous locations?
  4. It is unclear how the API implementation determines if a recipient is authorized or not, but perhaps this is covered elsewhere
  5. One could imagine recipients being given tokens once they have been authenticated and authorized for a certain level of accuracy in their responses. These tokens could have a lifetime of a session or longer, and could simplify or eliminate the need for repeated authorizations of recipients.
reillyeon commented 4 years ago
  • There is no option for a recipient to ask for a "fuzzy" location. A "fuzzy" location could be a location randomized within some, perhaps provided by the recipient, limits from the hosting device's actual location. Such "fuzzing" could help privacy in some scenarios. Just a suggestion.

This is a good suggestion. The interface currently only provides an "enableHighAccuracy" option but if you look at location APIs on other platforms there are typically options based on a target accuracy, such as city-level or street-level.

  • There's also no option for a recipient to ask for an encrypted version of a location. This could potentially be useful to reduce the risk of some unauthorized party accessing the response (the key could be a key negotiated by a remote recipient or similar). Also just a suggestion / idea.

The idea of blinding script on the page from accessing the location directly is interesting but doesn't seem enforceable because it relies on the script itself opting into the blinding.

The current standard in web APIs for protecting privacy-sensitive information is to require script to be executing in a secure context. This ensures that the script was loaded over HTTPS and so (by the same-origin and mixed content policies) can only communicate the location back to HTTPS endpoints.

  • For E911-type scenarios, if the hosting device's location accuracy is below some threshold, it may be better not to send location information than to send erroneous locations?

Location accuracy is already an attribute provided by the endpoint. Applications which require high accuracy can ignore results with accuracy lower than any threshold they choose.

  • It is unclear how the API implementation determines if a recipient is authorized or not, but perhaps this is covered elsewhere

The specification uses terms such as "user consent" and leaves the details of how an implementation acquires and manages that consent, such as the exact words in permissions prompts and permissions settings interfaces, up to the implementation.

  • One could imagine recipients being given tokens once they have been authenticated and authorized for a certain level of accuracy in their responses. These tokens could have a lifetime of a session or longer, and could simplify or eliminate the need for repeated authorizations of recipients.
samuelweiler commented 4 years ago

Item 1 seems related to https://github.com/w3c/geolocation-api/issues/49, which I've labeled for resolution.

I'm fine leaving this issue open for comment by others or closing it; https://github.com/w3c/geolocation-api/issues/49 is the only piece I'm labeling for resolution.

marcoscaceres commented 3 years ago

As I'm not seeing anything actionable here, I'm going to go ahead and close this. Please let me know if I've missed anything that could be actionable (keeping in mind we are just doing maintenance on this spec to match implementations, not adding new significant features).