From e4107d2007786f7b90a8ea05a344cc20062db257 Mon Sep 17 00:00:00 2001 From: Johann Hofmann Date: Fri, 9 Dec 2022 09:14:00 +0000 Subject: [PATCH] Define a permission store (closes #384) (#390) SHA: f3b927353b8290630944120afaab194dea0b61af Reason: push, by johannhof Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> --- index.html | 583 ++++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 462 insertions(+), 121 deletions(-) diff --git a/index.html b/index.html index f0171d0..6ffde36 100644 --- a/index.html +++ b/index.html @@ -325,10 +325,10 @@

Permissions

desktop
-
- Android Chrome logo107 -
- Android Firefox logo106 +
+ Android Chrome logo108 +
+ Android Firefox logo107
Android UC logo13.4
@@ -412,11 +412,13 @@

Permissions

  1. 3.1 Permissions -
  2. 3.2 +
  3. 3.2 + Permission Store +
  4. 3.3 Powerful features -
    1. 3.2.1 +
      1. 3.3.1 Aspects -
    2. 3.3 +
  5. 3.4 Permissions task source
  • 4. Specifying a powerful feature @@ -658,9 +660,77 @@

    Permissions

    lifetime has expired.

    -

    3.2 +

    3.2 + Permission Store +

    + +

    + The user agent maintains a single permission store which is a list of permission store entries. Each particular entry denoted by its descriptor and key can only appear at most once in this list. +

    +

    + The user agent MAY remove entries from the permission store when their respective permission's lifetime has expired. +

    +

    + A permission store entry is a tuple of PermissionDescriptor descriptor, permission key key, and state state. +

    +

    + To get a permission store entry given a PermissionDescriptor descriptor and permission key key: +

      +
    1. + + If the user agent's permission store contains an entry whose descriptor is descriptor, and whose key is equal to key given descriptor, return that entry. +
      2. +
    2. + Return null. +
      3. +
    +

    +

    + To set a permission store entry given a PermissionDescriptor descriptor, a permission key key, and a state state, run these steps: +

      +
    1. + Let newEntry be a new permission store entry whose descriptor is descriptor, and whose key is key, and whose state is state. +
      2. +
    2. + If the user agent's permission store contains an entry whose descriptor is descriptor, and whose key is equal to key given descriptor, replace that entry with newEntry and abort these steps. +
      3. +
    3. + Append newEntry to the user agent's permission store. +
      4. +
    +

    +

    + To remove a permission store entry given a PermissionDescriptor descriptor and permission key key, run these steps: +

      +
    1. + Remove the entry whose descriptor is descriptor, and whose key is equal to key given descriptor, from the user agent's permission store. +
      2. +
    +

    +

    + A permission key has its type defined by a feature's permission key type. +

    Note
    +

    +

    + To determine whether a permission key key1 is equal to a permission key key2, given a PermissionDescriptor descriptor, run the following steps: +

      +
    1. + If key1 is not of descriptor's permission key type or key2 is not of descriptor's permission key type, return false. +
      2. +
    2. + Return the result of running the permission key comparison algorithm for the feature named by descriptor's name, passing key1 and key2. +
      3. +
    +

    +
    +

    3.3 Powerful features -

    +

    A powerful feature is a web platform @@ -697,16 +767,16 @@

    Permissions

    powerful feature is identified by its name, which is a string literal (e.g., "geolocation").

    - The user agent tracks which powerful features the user has permission to use + The user agent tracks which powerful features the user has permission to use via the environment settings object.

    -

    3.2.1 +

    3.3.1 Aspects -

    +

    Each powerful feature can define zero or more additional aspects. An aspect is defined as WebIDL dictionary that - inherits from PermissionDescriptor and serves as a WebIDL + inherits from PermissionDescriptor and serves as a WebIDL interface's permission descriptor type.

    -

    3.3 +

    3.4 Permissions task source -

    +

    The permissions task source is a task source used to perform @@ -759,7 +829,7 @@

    Permissions

    MUST give the powerful feature a name in the form of a ascii lowercase string.

  • MAY define a permission descriptor type that inherits from - PermissionDescriptor. + PermissionDescriptor.
  • MAY define zero or more aspects.
    • @@ -780,8 +850,8 @@

    Permissions

    - PermissionDescriptor or one of its subtypes. If unspecified, this defaults to - PermissionDescriptor. + PermissionDescriptor or one of its subtypes. If unspecified, this defaults to + PermissionDescriptor.

    The feature can define a partial order on descriptor @@ -818,7 +888,7 @@

    Permissions

    powerful features have more information associated with them than just a PermissionState. Each of these features defines an extra permission data type.

    -
    Note

    +

    Note

    For example, getUserMedia() needs to determine which cameras the user has granted permission to access.

    @@ -873,7 +943,7 @@

    Permissions

    The default permission query algorithm, given a - PermissionDescriptor permissionDesc and a PermissionStatus status, + PermissionDescriptor permissionDesc and a PermissionStatus status, runs the following steps:

      @@ -882,6 +952,58 @@

      Permissions

    +
    + A permission key type: +
    +
    +

    + The type of permission key used by the feature. Defaults to origin. + A feature that specifies a custom permission key type MUST also specify a + permission key generation algorithm. +

    +
    +
    + A permission key generation algorithm: +
    +
    +

    + Takes an environment settings object, and returns a new permission key. + If unspecified, this defaults to the default permission key generation algorithm. + A feature that specifies a custom permission key generation algorithm MUST also specify a + permission key comparison algorithm. +

    +

    + The default permission key generation algorithm, + given an environment settings object settings, runs the following steps: +

    +
      +
    1. + Return settings's top-level origin. +
      2. +
    +
    Note: Permission Delegation
    +
    +
    + A permission key comparison algorithm: +
    +
    +

    + Takes two permission keys and returns a boolean that shows whether the two keys are equal. + If unspecified, this defaults to the default permission key comparison algorithm. +

    +

    + The default permission key comparison algorithm, + given permission keys key1 and key2, runs the following steps: +

    +
      +
    1. + Return key1 is same origin with key2. +
      2. +
    +
    A permission revocation algorithm: @@ -889,25 +1011,25 @@

    Permissions

    Takes no arguments. Updates any other parts of the implementation that need to be kept - in sync with changes in the results of permission states or extra permission data, and then react to the user revoking permission. + in sync with changes in the results of permission states or extra permission data.

    - If unspecified, this defaults to running react to the user revoking permission. + If unspecified, this defaults to running react to the user revoking permission.

    - A permission lifetime: + A permission lifetime:

    Specifications that define one or more powerful features SHOULD suggest a - permission lifetime that is best suited for the particular feature. + 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 lifetime is specified, the user agent + emphasis on user privacy. If no lifetime is specified, the user agent provides one.

    - When the permission lifetime expires for an origin: + When the permission lifetime expires for an origin:

    1. Set the permission back to its default permission state (e.g., by setting it @@ -916,7 +1038,7 @@

      Permissions

      For each browsing context associated with the origin (if any), queue a global task on the permissions task source with the browsing context's global object to run the permission revocation algorithm.

    -
    Note: Determining the lifetime of a permission