Section 3: Why only "SHOULD" for protection of privacy?

[magnus-git]

In Section 3 (the introductory part), it is stated that "[the mandatory mechanism that protects the user's privacy] SHOULD ensure that no location information is made available through this API without the user's express permission." This seems weak to me. It means that a conforming implementation of the privacy mechanism does not need to prevent the sharing of location information without user consent. I would suggest a `MUST.```

[reillyeon]

From RFC2119,

SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

Implementations are the ultimate authority over their user experience, and there are circumstances, such as devices managed by organization, where implementations may behave differently. A SHOULD is nearly as strong as a MUST, while acknowledging that there are concerns beyond compatibility which may affect how implementations behave.

[samuelweiler]

This was raised by the security reviewer but since it touches more on privacy, that's how I'm labeling it. I concur with @magnus-git

[marcoscaceres]

The question the arises here is if all implementations "ensure that no location information is made available through this API without the user's express permission.", which I believe is true.

I think it's safe to turn this into a MUST, and irrespective, we can probably all agree that it's "the right thing to do"™️ as far as this recommendation goes.

[reillyeon]

As mentioned above, neither Chrome or Firefox are in compliance with a MUST requirement because of their support for granting permissions through group policy which means the user does not grant express permission.

I would like to see this section of the specification rewritten to reference the permission check/request steps from the Permissions API rather than having its own bespoke requirements. The current structure is very weird because permissions are essentially a note which says "never mind all the steps above, do this first." We should make permission checking part of the algorithms for getCurrentPosition() and watchPosition().

[reillyeon]

Rereading the request permission to use steps I see that it does use "must" but also notes that the details of permission UI and how the UA infers user intent is intentionally vague.

[marcoscaceres]

As mentioned above, neither Chrome or Firefox are in compliance with a MUST requirement because of their support for granting permissions through group policy which means the user does not grant express permission.

Group policy is still something that needs to be opted into (by some "super"-user setting the policy for the group). I don't think that invalidates the requirement, in that "the group" has made an express decision to enable this permission by policy. The requirement is still that the user agent doesn't just allow access to geolocation.

I would like to see this section of the specification rewritten to reference the permission check/request steps from the Permissions API rather than having its own bespoke requirements. The current structure is very weird because permissions are essentially a note which says "never mind all the steps above, do this first." We should make permission checking part of the algorithms for getCurrentPosition() and watchPosition().

Agree - and that's a great suggestion. Will look into updating that.

[marcoscaceres]

For folks watching at home, #68.

[samuelweiler]

While I'm fine with the substantive change of using the Permissions API, the privacy analysis text in Section 4 (n.b. I'm using section numbers from the diff linked above, which seem to differ from the current section numbers) should explain the solution as well as the problem. e.g. "This API makes use to of the Permissions API to ensure that users have given express permission for the sharing of location" and maybe add some words about the granularity of that permission?

(In other words, the privacy considerations was stripped down too far here.)

@magnus-git, do you concur?

[marcoscaceres]

Thanks @samuelweiler. That seems reasonable to add as it does give a good overview of how the overall system works (in an informative sense). Interested readers can then deep dive into section 6 and permissions spec itself for normative details.

[marcoscaceres]

@samuelweiler, @magnus-git, please see #108 as an attempt to address your comments. I added a new section explicitly around "User Consent", but in terms of the Permission specification and outlining various normative enforcement points and describing the different permission lifetimes options usually presented to an end-user.

Would appreciate your feedback, if possible, by the end of November, so we can close this out and move the spec back to CR.