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.

[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:
w3c/permissions#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:

[marcoscaceres]

@yoavweiss, @tomayac, about:

any recommendation should definitely be tied to usage.

I just don't know if all browsers have that level of heuristic baked in (i.e., site usage frequency/frecency, which sounds like a fancy Chrome thing to have... although I think Safari has some internal heuristics for permissions... not necessarily for geo... I don't know if Firefox has any built in fanciness) - so we can't assume that. We should capture that there might be heuristics, also cater for time based too.

[johannhof]

Firefox doesn't use heuristics for this. I agree that we should be a bit hand-wavy (or avoid a recommendation) on the part that specifies how browsers should derive the lifetime, to cater to differences between browsers and to encourage innovation.

[anssiko]

This looks like a good TPAC discussion topic so I added to w3c/devicesensors-wg#47

[marcoscaceres]

Hoping we can have it resolved before TPAC - but maybe good as a general thing to talk about, as there are quite a few DAS specs to which something like this might apply.

[anssiko]

I'm a happy chair if the issues I put on the agenda resolve themselves before the meeting.

We discussed this at our 2021 Q2 virtual meeting too, so good to have a checkpoint and also discuss whether this generalizes to other APIs, what we have learned.

[samuelweiler]

I've now sent along a PR that defines lifetimes for permissions:
w3c/permissions#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.

It seems like the Geolocation API could make a recommendation now, even before the PR lands in the permissions spec. @pes10k, any thoughts on this more recent discussion?

[pes10k]

I think the text in w3c/permissions#287 looks appealing, and I dig the suggestion of hooking Geolocation into it once it lands. However, I agree with @samuelweiler that until (if?) both of those changes land in permissions and geolocation, it seems appropriate to include that text in geolocation

[marcoscaceres]

Ok, put up some draft text at #108

Please make suggestions/improvements inline in the pull request.