- From: Marcos Cáceres <notifications@github.com>
- Date: Wed, 17 Nov 2021 23:59:38 -0800
- To: w3c/permissions <permissions@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/permissions/pull/287/review/809572907@github.com>
@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
Received on Thursday, 18 November 2021 07:59:50 UTC