Hook into Permissions API to get permission - #68
Conversation
| location information is made available through this API without the | ||
| user's express permission. | ||
| thereby potentially compromising the user's privacy. User agents MUST | ||
| NOT send location information to Web sites without the express |
There was a problem hiding this comment.
I think this is mostly redundant with the "Ask the user’s permission for the calling algorithm" step in https://www.w3.org/TR/permissions/#request-permission-to-use and the "reflects the user’s intent" bit of https://www.w3.org/TR/permissions/#permission-state.
To the extent that you're trying to tighten the UA's ability to infer the user's intent, that seems like something that needs more discussion in #54: I don't agree that "the express permission of the user" includes permission by the device owner, who might not be the user or have even disclosed their permission grant to the user. It probably does make sense to say that a UA mustn't infer a user's intent to give away geolocation information based on other users' behavior, but a UA should still be able to infer that a user might want to not give away that information based on other users revoking permission, as is allowed by https://www.w3.org/TR/permissions/#new-information-about-the-users-intent.
There was a problem hiding this comment.
To the extent that you're trying to tighten the UA's ability to infer the user's intent, that seems like something that needs more discussion in #54: I don't agree that "the express permission of the user" includes permission by the device owner, who might not be the user or have even disclosed their permission grant to the user.
That's a whole other level of discussion. Basically, if a user willingly takes a device that they don't administer, there is zero privacy assurances. I really don't want to go down that rabbit hole.
| beyond the time when the <a>browsing context</a> is navigated to | ||
| another URL) MUST be revocable and user agents MUST respect revoked | ||
| permissions. | ||
| User agents MUST acquire permission through a user interface, unless |
There was a problem hiding this comment.
This seems to be covered by https://www.w3.org/TR/permissions/#request-permission-to-use. At least, I'm not sure how to "Ask the user’s permission" without a user interface.
The "unless they have prearranged trust relationships" bit then softens it to almost exactly the model in the permissions spec, where browsers are expected to infer the user's intent based on all the information they have.
There was a problem hiding this comment.
agree... this whole section can go.
| permissions. | ||
| User agents MUST acquire permission through a user interface, unless | ||
| they have prearranged trust relationships with users, as described | ||
| below. The user interface MUST include the {{URL/host}} component of |
There was a problem hiding this comment.
Is there anything special about geolocation that requires the host to be visible, or should that move to the permissions spec? Must it be the whole host, or could a UA emphasize a suffix in the case of a very long host?
There was a problem hiding this comment.
I think it should move to the permissions spec, tbh. There is nothing special about Geo. I think Geolocation was the first permission prompt to show the origin (2010) and why this is here... it's legacy stuff.
| the document's URL. Those permissions that are acquired through the | ||
| user interface and that are preserved beyond the current browsing | ||
| session (i.e. beyond the time when the <a>browsing context</a> is | ||
| navigated to another URL) MUST be revocable and user agents MUST |
There was a problem hiding this comment.
The idea that users MUST be able to revoke permissions they've granted belongs in the generic Permissions spec, and I think we're missing some wording about it from there. However, we have to be a bit more subtle than this to accommodate device policy, where users might not be able to revoke all permissions. This might be part of the question to answer in https://github.com/w3c/permissions/issues/231.
| <li data-tests= | ||
| "getCurrentPosition_permission_allow.https.html, getCurrentPosition_permission_deny.https.html"> | ||
| If the <a>current settings object</a>'s [=environment settings | ||
| object / responsible document=] is not [=allowed to use=] the |
There was a problem hiding this comment.
This is covered when https://www.w3.org/TR/permissions/#request-permission-to-use looks at the permission state.
| {{GeolocationPositionError/PERMISSION_DENIED}} and terminate this | ||
| algorithm. | ||
| </li> | ||
| <li>[=Request permission to use=] "geolocation" (see |
There was a problem hiding this comment.
You need to capture the result of this call, which will be "granted" or "denied", and fail if it returns "denied".
There was a problem hiding this comment.
Yeah, I was trying to be clever and just let "allowed to use" deal with it. I'll do as you suggest.
| <li>[=Request permission to use=] "geolocation" (see | ||
| [[[#privacy_for_uas]]] for permissions UI requirements). | ||
| </li> | ||
| <li data-tests="watchPosition_permission_deny.https.html">If the | ||
| <a>current settings object</a>'s [=environment settings object / | ||
| responsible document=] is not [=allowed to use=] the "geolocation" |
There was a problem hiding this comment.
Similarly here, "request permission to use" will return "denied" if the current settings object isn't allowed to use geolocation.
There was a problem hiding this comment.
There were a couple TODOs left to patch up on the Permissions side. Can I leave those to you @marcoscaceres?
Sure, can pick those up in the other repo. See you there! |
|
Thank you for cleaning this up! |
Closes #54
The following tasks have been completed:
Implementation commitment:
Preview | Diff