- From: Jeffrey Yasskin <notifications@github.com>
- Date: Thu, 11 Nov 2021 05:23:05 -0800
- To: w3c/permissions <permissions@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/permissions/pull/287/review/803740539@github.com>
@jyasskin commented on this pull request.
Thanks, I think this works for integrating the lifetime into the algorithms.
> @@ -385,6 +390,60 @@ <h3>
If unspecified, this defaults to running [=react to the user revoking permission=].
</p>
</dd>
+ <dt>
+ A permission <dfn class="export" data-dfn-for="permission">lifetime</dfn>:
+ </dt>
+ <dd>
+ <p>
+ Every [=permission=] has a [=permission/lifetime=], which is the duration for which
+ a particular permission remains [=permission/granted=] before it reverts back to
+ its default [=permission state=]. The lifetime is negotiated between the end-user
+ 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
Nit:
```suggestion
Specifications that define one or more [=powerful features=] SHOULD suggest a
```
> + Every [=permission=] has a [=permission/lifetime=], which is the duration for which
+ a particular permission remains [=permission/granted=] before it reverts back to
+ its default [=permission state=]. The lifetime is negotiated between the end-user
+ 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,
Does "pertaining to" have a precise definition?
> + 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
+ state=] (e.g. setting it back to "[=permission/prompt=]").
+ </p>
+ <aside class="note" title="Determining the lifetime of a permission">
+ <p>
+ For particularly privacy-sensitive [=features=], such as [[[GETUSERMEDIA]]],
+ which can provide a web application access to a user's camera and microphone,
+ user agents are known to expire a permission [=permission/grant=] as soon as a
Maybe:
```suggestion
some user agents expire a permission [=permission/grant=] as soon as a
```
> + Every [=permission=] has a [=permission/lifetime=], which is the duration for which
+ a particular permission remains [=permission/granted=] before it reverts back to
+ its default [=permission state=]. The lifetime is negotiated between the end-user
It'd be useful to give a sense of the kinds of lifetimes. e.g.
```suggestion
Every [=permission=] has a [=permission/lifetime=], which is the duration for which
a particular permission remains [=permission/granted=] before it reverts back to
its default [=permission state=].
A [=permission/lifetime=] could be until a particular Realm is destroyed, until a particular [=top-level browsing context=] is destroyed, an amount of time, or infinite.
The lifetime is negotiated between the end-user
```
> + <p>
+ Every [=permission=] has a [=permission/lifetime=], which is the duration for which
+ a particular permission remains [=permission/granted=] before it reverts back to
+ its default [=permission state=]. The lifetime is negotiated between the end-user
+ 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
```suggestion
When the permission [=permission/lifetime=] expires for a permission grant to an origin, and if there are
```
> + its default [=permission state=]. The lifetime is negotiated between the end-user
+ 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
```suggestion
Alternatively, if there is no [=browsing context=] present, the user agent MUST
```
> + a particular permission remains [=permission/granted=] before it reverts back to
+ its default [=permission state=]. The lifetime is negotiated between the end-user
+ 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=].
Run it where? "Queue a task to run the algorithm on each browsing context's event loop"?
> + [=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
+ state=] (e.g. setting it back to "[=permission/prompt=]").
+ </p>
+ <aside class="note" title="Determining the lifetime of a permission">
+ <p>
+ For particularly privacy-sensitive [=features=], such as [[[GETUSERMEDIA]]],
+ which can provide a web application access to a user's camera and microphone,
+ user agents are known to expire a permission [=permission/grant=] as soon as a
+ browser tab is closed or navigated. For other features, like the
+ [[[Geolocation]]], user agents are known to offer a choice of only granting the
+ permission for the session, or for one day. Others, like the [[[Notifications]]]
+ and [[[push-api]]] APIs, remember a user's decision indefinitely or until the
+ user manually denies the permission. Note that permission
Maybe:
```suggestion
user manually revokes the permission. Note that permission
```
"Denies" implies more that it's when the user was first asked.
> + 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 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".
> + thought and experimentation, and often evolves over a long period of time (often
+ years!). Implementers are encouraged to work with their UX security teams to find
Less colloquial maybe:
```suggestion
thought and experimentation, and often evolves over a period of years.
Implementers are encouraged to work with their UX security teams to find
```
--
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#pullrequestreview-803740539
Received on Thursday, 11 November 2021 13:23:20 UTC