Consider removing "lifetime"

[annevk]

It doesn't seem like it's actually referenced by other specifications according to https://dontcallmedom.github.io/webdex/l.html#lifetime%40%40permission%40dfn and it's not clear to me that it adds much over saying that entries can be removed at an implementation-defined time or when instructed by the end user.

[annevk]

Thinking about it more, this should be replaced by allowing an implementation-defined field on permission store keys. That would allow for all these scenarios and more and can be done in a paragraph without a bunch of explicit infrastructure nobody is using.

[marcoscaceres]

The lifetimes are used in Geolocation, but for some reason they didn't get linked (I'll send a PR):
https://www.w3.org/TR/geolocation/#user-consent

I still think lifetimes are useful as part of the model, even if it's up to the UA to determine, suggest, and enforce them.

[annevk]

An implementation-defined field on permission store keys would allow for that flexibility without the infrastructure that's essentially unused. Geolocation also doesn't really make use of it and could make the same recommendation with that solution.

[marcoscaceres]

Agree. Looking forward to what you and @johannhof are cooking up.

[tungnh28]

That's one of my curiosity when you are bringing up [permission store] (as current permission store + lifetime implementation in Chrome is quite a bit tricky and way far from the lifetime infrastructure in the spec).
Although I agree the flexibility implementation of permission store keys could resolve many complexed and unused specs, I think it would be still quite beneficial if we keep default lifetime, for example limited to a single browsing session, or something we can support one-time permission

[annevk]

It's not clear to me what the value add is.

If a permission wanted to limit its lifetime or scope in some way it can define its own key. #390 adds infrastructure for this and "storage-access" will make use of it.

If a permission wants to make a recommendation (but not require) that a user agent limits its lifetime in some way it can recommend they use an implementation-defined key as will be allowed if we do the above.

If a lot of permissions end up doing that in a similar fashion it might make sense to add some kind of abstraction, but 1) lifetime isn't that and 2) this doesn't appear to be the case.

[johannhof]

I'm a bit on the fence about this.

To (hopefully) help with your concern about implementation in Chromium, @tungnh28, what the spec is describing is an API surface that the browser should support for new and existing features building on top of permissions. How lifetimes are implemented in Chromium doesn't really matter as long as a feature could have e.g. a custom "lifetime" key which would then result in the same web-observable behavior across browsers.

However, I also feel like lifetime/expiry might be a common mechanism that we want features to think about, and that we want to promote usage of. Requiring feature specs to do the extra work of adding a custom key for lifetimes seems to go against that goal.

[annevk]

Requiring feature specs to do the extra work of adding a custom key for lifetimes seems to go against that goal.

That would only be true if lifetime was a useful hook, but it's not.

[tungnh28]

However, I also feel like lifetime/expiry might be a common mechanism that we want features to think about, and that we want to promote usage of. Requiring feature specs to do the extra work of adding a custom key for lifetimes seems to go against that goal.

The lifetime/expiry might be various on different UAs but the default (one-shot) lifetime is likely to be common. But it's not a strong objection from my side (I am not seeing the custom key lifetime now and looking forward how it would work).

[johannhof]

Is one-off the default lifetime for permissions in all implementations? Chrome for example remembers permissions for longer.

That aside, I think it's fair to note that a user agent may opt not to store entries in the permission store. Otherwise it's certainly not that convenient to express one-off with a key structure (unless you add some kind of nonce or something)? That also raises the question how we would express the ability for UAs to remove permissions from the store once they are no longer applicable through e.g. their lifetime key being expired.

All in all I agree with @tungnh28 that the lifetime concept is probably a lot closer to the reality in implementations today.