Skip to content

Commit

Permalink
Review feedback + rewrite
Browse files Browse the repository at this point in the history
  • Loading branch information
@marcoscaceres
marcoscaceres committed Nov 11, 2021
1 parent 17f8e82 commit fea3971
Showing 1 changed file with 57 additions and 41 deletions.
98 changes: 57 additions & 41 deletions index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -198,9 +198,9 @@ <h3>
</dd>
</dl>
<p>
A user agent SHOULD provide a means for the user to view, update, and
reset the [=permission=] [=permission/state=] of [=powerful features=]
associated with a realm or origin.
A user agent SHOULD provide a means for the user to review, update, and reset the
[=permission=] [=permission/state=] of [=powerful features=] associated with a realm or
origin.
</p>
<p>
To ascertain <dfn class="export">new information about the user's intent</dfn>, a user
Expand All @@ -217,44 +217,6 @@ <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.
</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
between ease of access to a [=powerful feature=] (i.e., reducing the number of permission prompts),
respecting a user's privacy, and making users aware when a web application is making use
of a particular powerful feature (e.g., via some visual or auditory UI indicator).
</p>
<p>
If you are unsure about what [=permission/lifetime=] to suggest for a [=powerful feature=],
please contact the <a href="https://www.w3.org/Privacy/IG/">Privacy Interest Group</a>
for guidance.
</p>
</aside>
</section>
</section>
<section>
<h2>
Expand Down Expand Up @@ -428,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
[=permission=] [=permission/lifetime=] that is best suited for the particular
feature - with a strong emphasis on user privacy. Some guidance on determining the
lifetime of a permission is noted below. 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
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
[=permission/lifetimes=] can vary significantly between user agents.
</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 between ease of access to a [=powerful feature=] (i.e.,
reducing the number of permission prompts), respecting a user's privacy, and
making users aware when a web application is making use of a particular powerful
feature (e.g., via some visual or auditory UI indicator).
</p>
<p>
If you are unsure about what [=permission/lifetime=] to suggest for a [=powerful
feature=], please contact the <a href="https://www.w3.org/Privacy/IG/">Privacy
Interest Group</a> for guidance.
</p>
</aside>
</dd>
</dl>
<p>
A <dfn class="export">default powerful feature</dfn> is a <a>powerful feature</a> with
Expand Down

0 comments on commit fea3971

Please sign in to comment.