Suggest permission lifetimes?

[pes10k]

Permission lifetime for geolocaiton should be aggressively life-timed, given how sensitive the data is, and how easy it is for users to not remove a permission once its been granted (particularly since current browser UX makes it much easier to grant permission than to revoke it).

For example, when iOS made it easier for users to restrict the lifetime of location permissions in apps, users reduced how much location information they sent by 68%. This suggests that the current "forever" permission lifetime for location is harming user privacy, and that the spec should similarly restrict the availably and lifetime of this data.

[marcoscaceres]

Do you know if anyone does this today? I guess Safari does if it clears storage after some time now. It might be nice to do it recommend doing it passively, so that user agents can forget the permission grant after a day or so without site usage.

[pes10k]

Brave is prototyping things in this direction, but haven't shipped anything yet. We hope to before long, but can't commit to a time line yet. I believe I've heard other vendors are considering the same, but I can't say 100% (others would know better of course).

I don't know of anyone who does this today for web permissions, but iOS does for apps, and announced at WWDC that they'd do something similar for extensions.

[reillyeon]

Firefox seems to support a limited version of this today with a "Remember this decision" checkbox in the permission prompt. I don't know precisely what time bound is applied if it is not checked. I assume it is the lifetime of the document. This is an interesting area in which user agents can and are experimenting with the user experience of permissions.

What changes to the specification are being proposed here? This seems like something for a non-normative note at most unless you are proposing changes to the API in order to support time-limited permissions. If so then this seems like something with a greater scope than just the Geolocation API and should be brought up in the WebAppSec WG as an extension to the Permissions API.

[marcoscaceres]

I agree with @reillyeon... this seems like a generally useful permissions thing.

[pes10k]

I'm happy to make a specific suggestion if it would be useful to start conversation, but I made the broader suggestion bc it seemed like something the WG would have better domain knowledge to work through.

I disagree though that this would be adequately addressed by a non-normative note. If the spec describes powerful functionality that we know is misused, and have reason to think is very often misused (e.g. the link above about the dramatic decrease in API access in iOS), then it seems just as necessary for the spec to describe how to the powerful feature will not be used, and in a way that can be standardized.

[marcoscaceres]

I think it would be fine to put this somewhere as a normative "It is RECOMMENDED that user agents....", if browsers are doing this already.

[anssiko]

If so then this seems like something with a greater scope than just the Geolocation API and should be brought up in the WebAppSec WG as an extension to the Permissions API.

I second this proposal. Rather than trying to retrofit the new API surface in an ad-hoc manner into every spec separately I see the benefit of this feature being an extension to the Permissions API to ensure all the specs that take a dependency on that API get the benefit. We need platform-level consistency for this.

For the Geolocation API spec, the right place to explain the UX for permission lifetime would be either the normative Privacy considerations for implementers of the Geolocation API or non-normative Additional implementation considerations depending on whether we find consensus on normative language that works for implementers who want to innovate in terms of UX.

This group is chartered to coordinate closely with Web Application Security Working Group exactly because the Permissions API matter to several specifications in this group, so please go ahead @pes10k and open an issue in the Permissions API repo for consideration.

[pes10k]

While I appreciate the points expressed above, and i think it'd be good to have a general solution to permission lifetimes, there are aspects of geolocation that make it especially important to have those restrictions in place for geolocation, and that w/o which the spec poses uniquely critical privacy issues.

Specifically:

1. the data exposed by the API is among the, if not the absolute most, sensitive data in the platform can expose, in a rec-track spec
2. the spec specifically requires implementors to allow websites to request ongoing updates to location. This makes permission lifetime uniquely important here

Put diff, if the spec is going to allow people to be located with high precision, and requires implementors to provide that capability to sites in a way that allows for easily forgettable background updates, it seems pretty important to have the spec cover how to that permission must be responsibly constrained too.

I don't have a pref about whether that conversation takes place here, or WebAppSec, or PrivacyCG, or elsewhere, but i dont see how this spec could advance w/o that work being done first.

[anssiko]

@pes10k I think it is important to put forward a concrete proposal as to allow the community review it. Are you in a position to do so or do you need help from others? Let us know.

[pes10k]

@anssiko sure, I am happy to put forth a concrete suggestion to spur discussion! I didn't earlier because generally in HR we try to identify issues and have the WG come up with the solutions (we've been told in the past WG prefer that pattern than having the HR group suggest specific concrete examples).

But, if its helpful, a concrete semi-straw proposal here is to add the following to the requirements section:

9. The Geolocation API MUST allow users to specify whether the
requesting site has access to geolocation data for
(i) the length of the frame,
(ii) for the length of the session, or
(iii) any number of longer periods of time, which can be decided by implementors.

[yoavweiss]

I didn't earlier because generally in HR we try to identify issues and have the WG come up with the solutions (we've been told in the past WG prefer that pattern than having the HR group suggest specific concrete examples).

Hey @pes10k! :)

I believe you're (at least partially) referring to feedback I provided in the past, so I'd like to clarify it. In this particular case the underlying issue you're surfacing is "Users' geolocation permissions seem to last longer than users are aware of, which is a serious privacy concern". What you're proposing here (regardless of the straw proposal text above) is one possible solution to that problem.

Time-boxing permissions may be something UAs choose to do, but they may solve this UX problem in other ways. E.g., as a user, I would like my browser to always keep geolocation permissions to my favorite mapping webapp, give one-time permissions to random-physical-store.com (when I want to find the nearest store to my physical location), and never give permissions (nor ever-ever ask me again) to random-publisher.com. In the case of the mapping webapp, my browser could periodically remind me that the permission is still granted, and allow me to easily revoke it.

That kind of a UX solution (and many possible others - I'm far from being a UX person) is something your proposed solution will not enable, regardless of the exact phrasing. This is why we don't mandate browser UI in specifications - it's something that is likely (and should) evolve over time to address the user's needs, and iteration is the best way to achieve that.

Therefore, I think it makes more sense to capture the intention in spec, rather than a specific possible method to execute it. Maybe something like "User agents SHOULD protect users from inadvertently granting permissions to geolocation data, and from inadvertently keeping those permissions alive for longer than users intend to". It needs to be a SHOULD rather than MUST, because UI is fuzzy and not something we can easily test to ensure compliance.

[marcoscaceres]

Agree, why I also suggested that we use RECOMMENDED, which is equivalent to a SHOULD... and only if a number of UAs are doing this.

[pes10k]

My straw proposal does not specify any UI. The ability to limit the permission lifetime could be done in any number of ways (in the "permission prompt, a global setting for the profile, etc etc")

But capturing the intent is not a substitute here. The spec requires / MUSTs that implementors provide sites with powerful useful-but-privacy-threatening capabilities. The spec should then also require that implementors make sure those capabilities aren't misused or harm people through readily foreseeable situations.

Recording the intent sounds like a great thing to do too, and I'm happy to concede that my straw proposal may not be the best way to solve the problem. But only capturing the intent does not solve the problem or address the issue either.

[yoavweiss]

I'm happy to concede that my straw proposal may not be the best way to solve the problem

That is missing the point. The point is that there is no "best way" to solve complex UX issues. There is no "one size fits all" solution that would work best for all users of all browsers. Different browsers serve different populations and may have different solutions to the same problem - how to keep users informed about the information they expose to websites, and make sure they don't do so by mistake. This spec needs to make sure that implementers address this issue. But since it's a UX flow issue, it has no business specifying what that solution should look like.

[pes10k]

This spec needs to make sure that implementers address this issue

Agreed. Only recording intent / RECOMMENDS does not achieve the above.

since it's a UX flow issue

I don't agree that it's a UX flow issue; it seems very easy to address the issue in a way that does not involve UX. Spec could easily say "location permissions MUST NOT last longer than 24 hours", or any number of other things.

The WG might not like the above idea either, thats just fine too of course. There are likely better solutions. But we know that the spec is being misused in a way that harms people, and the spec requires the functionality thats harming people to be in place. And so, the "spec needs to make sure that implementers address this issue" too.

[yoavweiss]

I don't agree that it's a UX flow issue; it seems very easy to address the issue in a way that does not involve UX. Spec could easily say "location permissions MUST NOT last longer than 24 hours", or any number of other things.

Note that I said "UX" and not "UI". Revoking permissions after X hours is most definitely a User Experience flow issue.

Only recording intent / RECOMMENDS does not achieve the above.

Nor would an un-testable MUST. (Or a testable MUST, to that effect) Specifications are descriptive, not prescriptive. They don't have magical powers that will force people to do what's written in them. Their role is to outline what's implemented and what needs to be implemented in order to achieve an interoperable web. Landing a testable MUST restriction that's not implemented by any browser and that no browser is interested in implementing will only result in that MUST restriction ending up being "at risk" and then removed from the spec. If that MUST restriction is not testable, it may slip through the cracks and stick, but that doesn't mean any implementation would actually follow it, unless they think it makes sense.

[cwilso]

I would alter Yoav's "the spec needs to make sure implementers address this issue." I think the spec needs to define the concerns, make it clear where there are concerns, and where possible make suggestions for mitigations. Where those mitigations might require changes to the API shape, it's even more important to consider them up front and make allowances for those mitigations. I don't think we can MUST most of those mitigations, though.

The challenge is that in practice, mitigating those concerns don't usually have an obvious answer. To use one of your suggested mitigations as an example, I'd be pissed if my Google Maps tab that I've had open for several days now stopped being able to tell where I was. There is a balance between potential privacy concern (the Google maps tab knows where I am, and if my wife walked up and used my computer it could track her too), and usability of the user experience.

Is this an easy answer of "don't worry about it"? No - I think we should be identifying concerns like this, brainstorm potential mitigations and suggest them in the spec, add API allowance where needed to support them, and let the users speak with their feet.

[pes10k]

I appreciate the comments above, and recognize that MUST in a standard is not legally binding or self enforcing. Thats equally true for privacy protections as for any other aspect of a standard.

I also don't see the UX/non-UX distinction being drawn here is. There is not a clear line separating (say) "there MUST be a way for permissions to be lifetime limited" as a UX feature that should not have mandatory language in the spec, while "the implementation MUST never invoke the successCallback without having first obtained permission from the user to share location" (5.2) as not being UX related, and so fine to receive mandatory treatment.

We write MUST in standards all the time because we think whatever feature MUST is describing is important enough that the standard should not be implemented w/o it. This issue is arguing that the web platform should not define powerful capabilities (i.e. giving realtime updates of location data), without also defining capabilities to prevent easily-foreseeable misused or harm.

We might disagree about how harmful accidental ongoing location disclosure is, or if its solvable at all, or if something about this particular issue that makes individual browsers better fit to solve the problem; cool, lets discuss, etc. But I disagree with the idea that this issue is categorically out of bounds for mandatory standards language. And doubly so since there are folks in these threads with less standards-body experience then even myself (low bar that it is), and will be deterred from discussion by such comments.

[IreneKnapp]

I'm weighing in here as the volunteer who's handling this review for PING, per the rotation. As I am new to the w3c, I take no position on the best way to move forward procedurally, but I want to go on the record as saying that this does seem like an important protection.

[reillyeon]

As the only implementation I am aware of that implements time-limited permissions, @marcoscaceres, can you provide any insight into how this feature has worked for Firefox users? Do they take advantage of the option? Is it appreciated or does it cause confusion?

[marcoscaceres]

I honestly don't know... I'll try to find out.

[marcoscaceres]

Reflecting on this, this is really a general permissions lifetimes issue, so really we should be having this discussion in the Permission spec. We've discussed permission lifetimes in the that spec previously (session based, persistent, etc).

[maryammjd]

Just a side note: although risks of Geolocation data are much more visible to everyone, but there are already commercial solutions using motion sensors to precisely locate users indoors. Please see: https://www.navenio.com

[marcoscaceres]

@maryammjd things like Navenio don't interface with browsers, right? If it doesn't, it might be outside the scope of this for now (until geo can deal with indoor location).

[maryammjd]

@maryammjd things like Navenio don't interface with browsers, right? If it doesn't, it might be outside the scope of this for now (until geo can deal with indoor location).

As far as I am aware Naveio can be integrated with mobile apps. I am not sure if their product has a web-based version or not. The important point is that such algorithms do exist and can impose real risks to the users in the near future.

[marcoscaceres]

The important point is that such algorithms do exist and can impose real risks to the users in the near future.

You raise a good point and I think we are all concerned about that kind of physical tracking. However, I think we will need to deal with things like Naveio more specifically when we get around to doing geofencing.

[marcoscaceres]

Closing ass outside the scope of "V1".

[pes10k]

Reopening since I do not consider this issue resolved. Further, Brave has an implementation too we're about to roll out in Brave, and I believe Chromium is working on a similar approach (I believe this is true bc Brave is upstreaming our more general "lifetime all permissions" work in Chromium).

There are also many voices in this thread agreeing that this seems important and fundamental.

[reillyeon]

As mentioned in another recent thread on the permissions language in this specification I believe that it should defer to the algorithms defined in [PERMISSIONS] and avoid adding custom normative requirements as concepts like granting session- or time-scoped permissions are not specific to geolocation.

That specification should include normative recommendations that implementations take steps to remind users of the permissions that have been granted and avoid persisting permissions for a long time on first grant. Agreeing with @cwilso's comments above this is an active area of experimentation around browser UX and the role of the specification is to ensure compatibility by making sure that the space of possible developer-visible behaviors is well-specified.

[marcoscaceres]

@pes10k wrote:

Reopening since I do not consider this issue resolved. Further, Brave has an implementation too we're about to roll out in Brave, and I believe Chromium is working on a similar approach (I believe this is true bc Brave is upstreaming our more general "lifetime all permissions" work in Chromium).

If this is generally applicable to "lifetime all permissions", then shouldn't the Permissions spec be updated instead of Geolocation? I'm confused.

[marcoscaceres]

As mentioned in another recent thread on the permissions language in this specification I believe that it should defer to the algorithms defined in [PERMISSIONS]

Agree.

and avoid adding custom normative requirements as concepts like granting session- or time-scoped permissions are not specific to geolocation.

Agree, agree.

That specification should include normative recommendations that implementations take steps to remind users of the permissions that have been granted and avoid persisting permissions for a long time on first grant. Agreeing with @cwilso's comments above this is an active area of experimentation around browser UX and the role of the specification is to ensure compatibility by making sure that the space of possible developer-visible behaviors is well-specified.

So yeah, transferring this issue to the Permissions spec.

[johannhof]

Because there was some confusion around how permissions in Firefox work: As a (probably undocumented) policy, by default we grant permission for the smallest atomic unit of access. i.e. for Geolocation.getCurrentPosition this means a one-off permission, with further requests triggering another prompt. For WebRTC this means that permission is granted only for the duration of the stream (though we have been adding a few hacks there to adjust to sites that unfortunately are built for the liberally granting Chromium model). Notifications, on the other hand, have a permanent permission lifetime because they need to work when the tab is closed.

The user can always choose to grant permanent lifetime by checking the checkbox in our dialogs, for example when they frequently use the site.

[martinthomson]

As this has a new home, I got new messages, so it might be a good opportunity to discuss the principles here.

Recommendations on time-limiting grants are probably wise, but - at least in the past - there has been an explicit agreement between browser vendors that decisions about how permissions are granted to sites is at the sole discretion of the browser. That is, that aspect of browser implementation is not subject to standardization.

That was a few years ago and we're all now much more sensitive to the privacy risks involved, so it is reasonable to suggest we discuss the question again. It is critical that we understand where the dividing line is between things that browsers are able to innovate and compete on without constraint and things that need to be agreed in a standards body.

For me, I would be open to this specification being more opinionated about the limits on permission grants. Differences between browser behaviour is a real source of compatibility problems for us. I would only do that on the understanding that other browsers were similarly willing to engage.

The first matter to discuss would be where that line is. I wouldn't want to discuss this specific issue, except to the extent that the example helps inform debate.

[pes10k]

If this is generally applicable to "lifetime all permissions", then shouldn't the Permissions spec be updated instead of Geolocation? I'm confused.

Two issues are being tangled up here.

The issue I filed in geolocation is saying "this functionality is too privacy-risky to only be set-and-forget. For it to be non-privacy-harming, there should be a way for users to grant temporary access."

It might also be the case that this is true for all permissioned APIs, and so it might also make sense to add lifetime options to all permissions. But that is independent from my issue on the geolocation spec, which is that I don't think the geolocation spec should go to rec w/o a way to grant access for a restricted amount of time.

I filed this issue specific to geolocation, and the risks specific to giving sites persistent access to geolocation data. The issue text, link and concerns here are not general to all permissions. Please kindly transfer this issue back to its original location @marcoscaceres.

[marcoscaceres]

@pes10k wrote:

But that is independent from my issue on the geolocation spec, which is that I don't think the geolocation spec should go to rec w/o a way to grant access for a restricted amount of time.

I think you are confused. The Geospec has gone to REC multiple times:

• W3C Recommendation 8 November 2016
• W3C Recommendation 24 October 2013

This amended Recommendation, for which comment was sought, is being updated to match what is shipping in multiple engines (and to align where they don't). If you'd like to see something specific added to the amended Geolocation specification that matches multiple implementations, then I kindly ask you send a pull request with those changes (or at least be more clear about exactly what you'd like to see changed so as Editor I can put together a pull request on your behalf, and we can talk about possible tests, implementation timeline, etc.). We would still need to get backing from multiple implementers on adding whatever you are suggesting, but that shouldn't block republishing the very much out of date spec because it doesn't have a particular thing that you'd like to see.

Please kindly transfer this issue back to its original location @marcoscaceres.

This issue is widely applicable to all permissions, so the general consensus is that this issue belongs here - see above about sending a pull request with changes instead.

[jyasskin]

I think it would make sense to file a new, more-focused issue in this repository, so that we can pull in the right stakeholders to address @martinthomson's excellent comment without confusing them about the geolocation-specific discussion.

I would be surprised if geolocation is actually unique in wanting stricter privacy rules than the average permission. There are probably other similarly-sensitive permissions, including many of the controversial hardware-access ones. If we decide to standardize those stricter rules at all, it probably makes sense to add a flag to the permission, similar to https://w3c.github.io/permissions/#allowed-in-non-secure-contexts, to add the extra constraints. (Even that flag might need some revisiting, but that's independent of this issue.)

[pes10k]

I appreciate the points made above, and agree with @jyasskin and @martinthomson. It'd be useful to discuss whether (and if) how long a capability is given out is a reasonable thing to consider during privacy reviews (as part of HR or otherwise).

However, I don't think this issue is the right place for that discussion. This issue, the links given in the discussion, and the 👍 and comments in support of the issue, are all specific to geolocation. Further, an outcome of this issue could be that geolocation requires greater, lesser or just otherwise different protections than other permission'ed capabilities. Its also possible that limits on how long sites held permission to geolocation functionality could/should be defined in a way thats outside of the permissions API.

Finally, I am not aware of a requirement that privacy (or any other) issues need a PR to stick / stay. I have though made a specific suggestion in https://github.com/w3c/permissions/issues/231#issuecomment-652041324 and if turning that into a PR would help discussion, thats fine with me too.

@marcoscaceres please kindly move this issue back to its previous location, and re-add the labels that it had previously (if that last part is not possible, i can do so). I'd then be happy to follow @jyasskin suggestion and open a new issue in this repo, to discuss whether permissions in generally should include lifetime limitations.

[marcoscaceres]

@pes10k, there is nothing specific in https://github.com/w3c/permissions/issues/231#issuecomment-652041324 that doesn't apply generally to any API requesting permissions. It wouldn't be something that would be added to the Geolocation spec - thus we would just end up back here again. As @martinthomson suggested, it would be better to be generally opinionated in the Permissions spec (which Geolocations now hooks into to get its permission), then have some one off text in Geo.

[samuelweiler]

For purposes of the general discussion, I just ran across a spec that makes recommendations about a permission timing out: the Clipboard API and events.

[marcoscaceres]

Moving this back to Geolocation repo after a chat with @plehegar - to allow PING to finish their wide review. However, the plan is to close this issue as "won't fix" in Geo, and just reopen it here (in Permissions repo) to continue discussion.

[marcoscaceres]

Closing as the spec relies on Permission spec. Filed https://github.com/w3c/permissions/issues/233

[anssiko]

The DAS WG made the following related resolution at its 06 April 2021 virtual meeting:

RESOLUTION: Expand Privacy and Security considerations with discussion of privacy harms from long-lived permissions and Gather developer feedback on restricted lifetime and scope of geolocation capabilities.

@pes10k please confirm whether you are satisfied with the resolution so we can proceed accordingly.

[marcoscaceres]

As I wasn't able to join that call, I wasn't able to be make my voice heard when the resolution was proposed. The above resolution applies generally to all permissions, so the appropriate place for them is in the Permission spec.

[pes10k]

Hi @anssiko, thank you for the follow up, but no, that resolution is not satisfactory to me. The request / resolution for this issue is for normative changes to the spec to address the discussed privacy harms related to sites having access to geolocation capability for longer than users realize

[marcoscaceres]

I've now sent along a PR that defines lifetimes for permissions: https://github.com/w3c/permissions/pull/287

And I've made a recommendation that specifications that define themselves as "powerful features", such as Geolocation, SHOULD include some RECOMMENDATION about the lifetime of a permission.

Once the PR above lands, then for Geolocation, we could recommend that geolocation's permission lifetime default to life of the browsing context, with the option of it being extended for a day. We might recommend against the lifetime being indefinite.

[yoavweiss]

As a user, I'd be super annoyed if my regular mapping web app re-asked me for permissions every day. I strongly suggest that any recommendation would also consider frequency of use.

[tomayac]

+1, any recommendation should definitely be tied to usage.

[marcoscaceres]

Yeah, agree. It need to be carefully worded. These are just recommendations (i.e., browser can still do what is best for their users!!!!).

We can probably update the text in w3c/permissions#287 also, so that browser heuristics are taken into consideration.

[marcoscaceres]

Just for reference, Firefox (session VS indefinite):

Chrome:

Safari is session or 1 day:

As I stated in w3c/permissions#287, I don't want to lock us into anything (this is for security UX teams that know better than standards weenies). Any lock-in would be "un-good".

[marcoscaceres]

And for completeness, Brave, which provides a cute little drop down with a bunch of time options: