Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Define permission lifetimes #287

Merged
merged 8 commits into from
Nov 23, 2021
Merged

Define permission lifetimes #287

Changes from 7 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
f52e01b
Define permission lifetimes
marcoscaceres Aug 31, 2021
e7c2a9e
Fix push reference
marcoscaceres Aug 31, 2021
926e28f
Update index.html
marcoscaceres Sep 1, 2021
17f8e82
Update index.html
marcoscaceres Sep 1, 2021
fea3971
Review feedback + rewrite
marcoscaceres Nov 11, 2021
fe06c6d
Fixup wording
marcoscaceres Nov 11, 2021
e698eb7
Apply suggestions from code review
marcoscaceres Nov 12, 2021
69a5c32
Queue the change
marcoscaceres Nov 18, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 61 additions & 0 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -197,6 +197,11 @@ <h3>
the feature.
</dd>
</dl>
<p>
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
agent MAY collect information about a user's intentions. This information can come from
Expand Down Expand Up @@ -385,6 +390,62 @@ <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=].
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
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 define one or more [=powerful features=] 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 a permission grant to an origin, and if there are
[=browsing contexts=] present pertaining to the [=permission=]'s associated origin,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does "pertaining to" have a precise definition?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No... I was hesitant to use that word. I'm open to suggestions as to how to make that association (I'll give that some further thought too).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we're trying to say, if you're the top-level browsing context for a given origin and have any ancestor browsing contexts, revoke permission for all browsing contexts? I guess https://html.spec.whatwg.org/#nested-browsing-contexts gives you most of what you need.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be possible to treat it like a map, in that we can just grab all any/all browsing contexts associated with an origin (not really worrying if they are nested or not.)

the user agent MUST run the [=powerful feature/permission revocation algorithm=].
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Run it where? "Queue a task to run the algorithm on each browsing context's event loop"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, something like that could work... will add it.

BTW: I think we need to relook at the "permission revocation algorithm"... it seems to call it self recursively.

Alternatively, if there is no [=browsing context=] present, the user agent MUST
revoke a permission for the origin by setting it back to its default [=permission
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"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".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestion.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"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).

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,
some user agents 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 revokes 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 period of 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