- From: Reilly Grant via GitHub <sysbot+gh@w3.org>
- Date: Mon, 10 Aug 2020 21:25:17 +0000
- To: public-device-apis-log@w3.org
> * 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](https://w3c.github.io/webappsec-secure-contexts/#secure-contexts). 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. -- GitHub Notification of comment by reillyeon Please view or discuss this issue at https://github.com/w3c/geolocation-api/issues/57#issuecomment-671597851 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 10 August 2020 21:25:20 UTC