Re: [w3c/permissions] Define an algorithm to update the permission storage. (#91)

> +    <h3 id="storage-manipulation">Storage Manipulation Algorithms</h3>
> +
> +    <p>
> +      Other specifications can use the algorithms defined in this section to
> +      manipulate the <a>permission store</a> from their algorithms.
> +    </p>
> +
> +    <div class="example" id="example-storage-manipulation">
> +      <p>
> +        The [[notifications]] API can check for the user having granted
> +        permission using:
> +      </p>
> +      <blockquote>
> +        If the {{"notifications"}} <a>permission's state</a> is not
> +        {{"granted"}}, reject <var>promise</var> with a {{TypeError}} exception
> +        and terminate these substeps.

Just to add a bit more, some of the permissions are stored as a combination of `request origin + top-level origin` when they are requested from a frame.

I believe the motivations for wildcards was that you could go into settings and enable a permission for `*.example.com` and never have to worry about individual permissions for subdomains (either for developers of power users).
In addition, if the permission only takes into account the requesting origin (and not the top-level origin if the request comes from a frame), then a permission granted to an origin in one place can be automatically granted in other frames for that origin.
As a concrete example, this would be desirable if you consider fullscreen a permission and want to permit all YouTube video frames to be able to go fullscreen after granting fullscreen once on `youtube.com`.
However, what Chrome does should not be considered a good model. It was constructed ad-hoc, depends on the permission in question, and is in the process of being converted to simply origin-scoped.

---
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/91/files/315ae14c94bbc7cc55126faa1dfb4d3a7a26e89a#r61349454