Time-limited permissions

At present, permissions on the web are binary. A user either grants you permission to their sensitive data (e.g., location, clipboard) or they don’t. When a user does grant a site permission to access that information, that permission persists until the user revokes it. This creates an imbalance of power. Users forget who they’ve granted permission to and seldom audit site permissions.

If we were to allow users to control the duration of a permission grant at the same time as they are granting it, we put them back in control and reduce/remove the need for them to audit permissions.

Using a set time for permission doesn’t seem very useful. It would be much more convenient to have the ability to only grant permission while in use/the foreground, similar to location permissions in Android 10.

Why don’t you think it’s very useful? Today, depending on the browser, I might be able to grant permissions for a single-use, or “always” but nothing in between. Other options that seem useful (to me) might be: “for today”, “this week”, or “use algorithm that determines how long to approve this permission based on my usage patterns”.

Honestly, that might be a permission level separately. Normal permission would be to allow access in the foreground, but allowing it to run in the background feels like something that should be called out separately. For instance, I don’t want an e-commerce site having access to my location in the background just because I searched for local availability of a TV six months ago. A navigation app I am running in the background while switching the podcast I’m listening to, certainly.

The one thing to note about this proposal is that it is positioned more as a user protection than a feature directed at developers. So if you (as a user) happened to grant access to location for a specific one-time task, that permission goes away after a specific amount of time that you control when granting it.

More soon…

I’ve also wanted to let users grant a permission “while I’m here”, for example, to let a museum’s website use Bluetooth LE Scanning while I’m at the museum, but have it automatically expire when I leave. In practice, that could be when I move more than X distance from my original grant point, with X chosen using a map UI. We might want to let the website suggest an initial X.

Note that only the last bit about letting the website offer hints needs a change to any web specification. The rest can be done individually in each browser’s UI.

Interesting use case. Do you think a specific timeframe or the duration of a session might solve for that as well?

A timeframe does work for the museum, and now I’m forgetting what other use case made me think a geofence was important. Maybe you want a webpage to be able to do something while you’re at home, while you’re at school, or while you’re at a conference venue, but not elsewhere? In that case you’d want the permission to come back into effect when you re-enter the geofence.

Don’t let my scope-creep slow down your timefencing effort, of course. That’s super-valuable on its own.

Geofenced permissions is definitely an interesting use case. I could also see it being useful for limiting access to certain confidential information so it can only be viewed on premises. Niche use case (at least at present), but interesting nonetheless.

I think timeboxed permissions is something we need. Not just for geolocation but background* and periodic sync come to mind as well. I could imagine that a lot of permissions ought to be removed by default after X months if the user hasn’t returned to the site.

I wouldn’t want to see permission usage gated on say PWA install, but I do wonder if it could be a signal for permission persistence.

It certainly speaks to engagement (assuming continued use of said PWA).

I like the idea of permissions as some sort of certificate token with expiryDate/keepAlive field which may need to be periodically refreshed. This makes sense from user privacy Point of View. From security perspective, users usually update their corp/banking passwords every 45 days, and some non essential passwords almost never. Depending on the feature the permission is gatekeeping, UA can enforce default policies of “expiresIn” values. Just as an example, Geolocation permission might be asked to be updated more periodically than say AmbientLightSensor, because of say higher entropy of fingerprint.

Smarter permissions, intentional permissions, seems like a growing need alright, I’ve stopped clicking Approve when I see unbounded location, address book etc. requests just so I can login to an app/site easily.

Maybe pitch it here? https://webwewant.fyi/

You just made my day. That’s my project

I initially considered enabling developers to get information about expiration when using permission.query, but in talking with some other folks, I struggled to find a real use case for it. Can you think of a couple? (I’ve got the approach we settled on outlined in the forthcoming explainer.)

I think this is a great idea. I do think @DanielHerr is right that a permissions scheme should try to be somewhat similar to other permissions schemes that exist today - like Android, iOS, and maybe Windows 10? Many users are going to be using a browser on one of those systems, and will already be used to how they work. Getting used to the idea that sometimes you grant permissions in the browser and they work in a totally different way than when you grant OS permissions is hard.

So, in my mind, foreground / background permissions would be good, along with prompts when a page has been using background location (or other permissions) a lot.

I think the “use an algorithm” is too opaque to the user to be considered a permission, and better belongs in a “clean up your privacy” mode (like Firefox’s “Refresh Firefox”).

Agreed.

I think the foreground/background aspect is interesting. Let me noodle on that a bit.

To what extent is this something that requires new/revised specifications, and to what extent is it something that implementations are already free to experiment with? It feels to me like it should be something that implementations are free to experiment with, and if there are parts of specifications that are in the way of that, we ought to try to fix those specifications.

dbaron beat me to it. The only thing we might consider is whether any of these permissions models would need to be reflected in the permissions API. But those improvements should be taken to the repo for permissions.

I am hoping to get the explainer out by EOD tomorrow, but my preference would be to piggyback on the Permissions API (specifically permissions.request()). My reasoning is that I’d rather not have to revise a bunch of APIs when we could just add it to one.

So I think we’re thinking along different lines – I’m thinking that this is something that browsers could just do – and I think you’re thinking that this is something sites would request.

Browsers already differ a good bit – for example Chrome remembers WebRTC microphone/camera permissions (but has constraints on when sites are allowed to prompt for them, requiring user interaction first) whereas Firefox asks for microphone/camera permission every time on the theory that just because a user did a videoconference once doesn’t mean they’re comfortable showing their current state to others (but is more lenient about allowing them to prompt).

It’s not clear to me what would give sites an incentive to ask for a time limited permission.

But I can see why a browser maker (or browser extension author) might think it’s the right thing for their users to interpret a user’s grant of permission as “for a day” rather than “just for this session” or “for all time”. (And browsers already do both of “for this session” and “for all time”, and sometimes already differ between browsers.) So I think this is something that browsers can just experiment with today – it’s not clear to me what APIs it’s not compatible with. But there might be some, and fixing them would be reasonable.