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

@miketaylr approved this pull request.

LGTM, just a couple of editorial notes.

> @@ -209,6 +214,44 @@ <h3>
             implicit signals.
           </p>
         </aside>
+        <section>
+          <h4>Lifetimes</h4>
+          <p>
+            Every [=permission=] has a <dfn class="export" data-dfn-for="permission">lifetime</dfn>,
+            which is the duration for which a particular permission remains [=permission/granted=].
+            Depending on the [=powerful feature=], the lifetime of a permission is negotiated between the
+            user and the [=user agent=], usually via some permission UI or policy.
+          </p>
+          <p>
+            Specifications that identify themselves as <a>powerful feature</a> SHOULD suggest

I guess a spec can have more than 1 powerful feature (maybe?), so should we say "define" instead of "identify themselves"?

Also, s/feature/features/

> @@ -209,6 +214,44 @@ <h3>
             implicit signals.
           </p>
         </aside>
+        <section>
+          <h4>Lifetimes</h4>
+          <p>
+            Every [=permission=] has a <dfn class="export" data-dfn-for="permission">lifetime</dfn>,
+            which is the duration for which a particular permission remains [=permission/granted=].
+            Depending on the [=powerful feature=], the lifetime of a permission is negotiated between the
+            user and the [=user agent=], usually via some permission UI or policy.
+          </p>
+          <p>
+            Specifications that identify themselves as <a>powerful feature</a> SHOULD suggest
+            a [=permission=] [=permission/lifetime=] that is best suited for the particular feature
+            - with a strong emphasis on user privacy.

nit: The `-` is sorta awkward here. Can we make it a new sentence? Or just replace `-` with `and`, or perhaps just remove it?

> +            - with a strong emphasis on user privacy.
+          </p>
+          <aside class="Note" title="Determining the lifetime of a permission">
+            <p>
+              For particularly privacy-sensitive [=features=], such as [[[GETUSERMEDIA]]],
+              which can provide 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.
+            </p>
+            <p>
+              Finding the right balance for the lifetime of a permission requires a lot of
+              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 the right balance

(are UX security teams a thing? or does this mean to say "UX and security"? maybe i just don't know the cool teams 😭)

-- 
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-742742415