Re: [w3c/permissions] Define permission lifetimes (#287)

@marcoscaceres commented on this pull request.



> +                and the [=user agent=] when the user gives [=express permission=] to use a
+                [=feature=] - usually via some permission UI or policy.
+              </p>
+              <p>
+                Specifications that identify themselves as a [=powerful feature=] SHOULD suggest a
+                [=permission=] [=permission/lifetime=] that is best suited for the particular
+                feature. Some guidance on determining the lifetime of a permission is noted below,
+                with a strong emphasis on user privacy. If no [=permission/lifetime=] is specified,
+                the user agent provides one.
+              </p>
+              <p>
+                When the permission [=permission/lifetime=] expires for an origin, and if there are
+                [=browsing contexts=] present pertaining to the [=permission=]'s associated origin,
+                the user agent MUST run the [=powerful feature/permission revocation algorithm=].
+                Alternatively, if there is no [=browsing contexts=] present, the user agent MUST
+                revoke a permission for the origin by setting it back to its default [=permission

> "Setting" a permission state isn't really defined in this spec, in order to give UAs lots of freedom of how to infer what the user wants. 

I think that's fine, but conceptually there is still some datastore somewhere that gets updated (that is, a permission is bound to an origin or a realm or whatever). When the update happens, it gets asynchronously propagated. 

> I think it's clear enough what you mean here, but it could help to define "setting a descriptor's permission state to X" as something like "as if the UA had returned X when reading the descriptor's permission state for some group of settings objects".

Upon reflection, I think we should do this as a followup, because it gets into the problem above about conceptualizing how permissions are actually stored (or how we will pretend they are stored for the purpose of the specification). 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/permissions/pull/287#discussion_r751985096