Integrate with the Permissions spec. #36

jyasskin · 2016-07-21T19:26:16Z

Preview at https://api.csswg.org/bikeshed/?url=https://github.com/jyasskin/storage/raw/permission-integration/storage.bs#persistence

annevk · 2016-07-22T07:53:35Z

storage.html

-    If that returns no answer, then do not alter <var>permission</var>. </p>
-       <p class="note" role="note">User agents are encouraged to not let the user answer this question twice for
-    the same <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/browsers.html#origin">origin</a> around the same time and this algorithm is not equipped to handle such a
-    scenario. </p>


We should keep this note I think.

annevk · 2016-07-22T07:56:44Z

Also, thanks for doing this!

annevk · 2016-07-22T17:28:37Z

storage.bs

-<p class="XXX">We will eventually integrate with the Permissions API, with the identifier
-"<dfn export for=PermissionName type=enum-value><code>persistent-storage</code></dfn>", but since
-that specification is not in great shape at the moment that has not happened yet.
+The <dfn for="PermissionName" enum-value>"persistent-storage"</dfn> <a>powerful feature</a>'s


Powerful feature? Didn't we do away with that term?

I reintroduced it in w3c/permissions#97, but with a more tautological definition: "A feature of a UA that some code might not be allowed to access, for example because its environment settings object doesn’t satisfy some criteria, or because the user hasn’t given permission."

@mikewest was happy with it, and because it doesn't include the "should only be accessible from HTTPS" bits, I don't expect other folks to have a problem. If they do, we could back off to just "feature". And we might do that anyway if we unify the PermissionName enum with the list in Feature Policy.

I think we should just call them (privileged/powerful) APIs. But I guess I'm okay with this for now. (API is the term we use elsewhere, e.g., in Fetch.)

annevk · 2016-07-22T17:41:59Z

I would prefer "Let permission be the result of requesting permission to use ..." indeed. Either with an lt here or in Permissions.

The main problem with the descriptor I think is that you're sort of hand-waving the parsing and turning it into a dictionary part. I don't think we currently have anything that implicit.

annevk · 2016-07-22T17:44:14Z

It seems powerful feature is how Permissions describes gated APIs. I thought we had gotten rid of the term after the rename to secure contexts. Any particular reason we say feature and not just API?

annevk · 2016-07-22T17:48:27Z

(Feel free to get annoyed with me for second guessing some Permissions stuff. I realize that's not ideal to do here.)

jyasskin · 2016-07-22T17:55:55Z

The main problem with the descriptor I think is that you're sort of hand-waving the parsing and turning it into a dictionary part. I don't think we currently have anything that implicit.

Interesting. I think it's unambiguous what WebIDL object would be created by this sort of spec syntax, but I'm happy to say something else.

(Feel free to get annoyed with me for second guessing some Permissions stuff. I realize that's not ideal to do here.)

Not a problem. We need to come to consensus about this, and going around in a couple circles is the only way to do that.

annevk · 2016-07-23T17:07:43Z

I think it's unambiguous what WebIDL object would be created by this sort of spec syntax, but I'm happy to say something else.

The main problem is that it doesn't follow from first principles. It kinda works because everyone recognizes it, but it isn't really grounded formally.

This change defines both "Verb noun" and "verbing noun" so other specs can use "Let foo be the result of verbing noun." instead of the current "Verb noun, and let foo be the result." Motivated by whatwg/storage#36.

annevk · 2016-07-27T12:17:43Z

storage.bs

-"<dfn export for=PermissionName type=enum-value><code>persistent-storage</code></dfn>", but since
-that specification is not in great shape at the moment that has not happened yet.
+The <dfn for="PermissionName" enum-value>"<code>persistent-storage</code>"</dfn> <a>powerful feature</a>'s
+permission-related flags, algorithms, and types are defaulted except for:


comma before "except for"

annevk · 2016-07-27T12:21:10Z

You should also add your name to the acknowledgments.

raymeskhoury · 2016-07-28T07:05:32Z

storage.bs

+<dl>
+ <dt><a>permission state</a></dt>
+ <dd><code>{name: {{"persistent-storage"}}}</code>'s <a>permission state</a> must have the same
+ value for all <a>environment settings objects</a> with a given <a>origin</a>.</dd>


nit (sorry I'm going through a backlog of activity :) I wonder if we can word this in a way that makes it clear the permission state is being "returned"?

That's a good point.

What we really want is to require a certain scope for permissions. And the scope for "persistent-storage" is an origin, but we'd then also need to define where that origin originates.

w3c/permissions#114 adds an explicit settings object argument to "permission state", which is where the origin would come from.

I'm skeptical that we need to talk about "returning" a permission state. When we talk about a settings object's origin, we don't bother saying that it's the origin returned by some algorithm.

But we do define creation of a settings object. At that point the origin is set, too. The statement we have here around "permission state" is somewhat declarative and doesn't directly fall out from something else. Does that make sense?

Leaving the value up to the UA is definitely an uncomfortable point in the permissions spec, but saying "returned" here wouldn't help with it.

w3c/permissions#117 changes the "permission state" algorithm to explicitly delegate to this section. Does that help?

You can see in the ordering of the PRs that I mostly agree with you. I had to be pulled into the looser description by the people implementing Chrome's and Firefox's permission storage systems. That said, I think the variety of existing stores is a good reason not to try to write up a single model that covers all of them.

It'd be fine with me if we revisit this. (Except argh more work. 😉) If you want to change it, could you start a thread on webappsec so everyone who cares can be involved?

I think the variety of existing stores is a good reason not to try to write up a single model that covers all of them.

Isn't that what Permissions is? If Permissions is not that, what exactly is this integration supposed to be?

I'm happy to start a thread, but I'm not really sure where to start. It seems like we want a generalized model since some want to expose generalized "get" and "request" operations. It's not clear how those would work if there wasn't a generalized model.

And if there's no generalized store that means each permission either has to adopt a default store or implement its own. We could go down that route too, but I'm not sure that's more useful than just allowing the nature of the key to be changed on a per-permission-type basis.

Assuming that we can't build a generalized model, I think the Permissions spec serves to explain that fact and prevent individual specs from trying to specify a store that not all browsers will be willing to implement. It says, maybe not clearly enough, that each UA has to provide the "get" and "request" operations in whatever way makes sense for that UA, and then specs can call those operations, instead of independently asserting that they exist.

The useful webappsec thread, I think, would consist of revisiting whether that first assumption is true, or whether there is a more detailed model we could put into the Permissions spec.

https://lists.w3.org/Archives/Public/public-webappsec/2016Aug/0002.html

annevk · 2016-10-10T13:16:37Z

Can you click the checkbox in the sidebar that allows me to push to your branch? This looks okay now. Needs a date bump and maybe some minor tweaks, depending on the console output of bikeshed.

…iptor. This works since w3c/permissions#115.

jyasskin · 2016-10-10T16:40:52Z

I've updated the date, and bikeshed shows no errors or warnings. And I've checked the box.

annevk · 2016-10-11T08:33:53Z

Thanks!

* Don't use an IDL block for PermissionName, so that it can link outside the local spec. * Remove the local persistent-storage definition now that it's defined in the Storage spec. (whatwg/storage#36)

jyasskin mentioned this pull request Jul 21, 2016

Guidance on where to put permission related stuff in other specs w3c/permissions#110

Closed

annevk reviewed Jul 22, 2016
View reviewed changes

jyasskin force-pushed the permission-integration branch 2 times, most recently from e35f939 to cb12ff0 Compare July 22, 2016 16:02

annevk reviewed Jul 22, 2016
View reviewed changes

annevk reviewed Jul 27, 2016
View reviewed changes

raymeskhoury reviewed Jul 28, 2016
View reviewed changes

This was referenced Aug 4, 2016

Provide a concise syntax to create IDL dictionaries from prose whatwg/webidl#142

Closed

Resolve TODOs on media type permissions w3c/permissions#120

Merged

jyasskin added 4 commits October 5, 2016 13:20

Integrate with the Permissions spec.

8cee49d

Try a different enum-value dfn formatting.

7803cc1

Put "Let |permission| be" at the beginning of its sentence.

2ff9018

Formatting and wording tweaks from @annevk.

0c5c532

jyasskin force-pushed the permission-integration branch from 7639c39 to 5cd6ae7 Compare October 5, 2016 20:21

jyasskin force-pushed the permission-integration branch from 5cd6ae7 to 0800e6d Compare October 10, 2016 16:40

Use "persistent-storage" directly instead of wrapping it into a descr…

0800e6d

…iptor. This works since w3c/permissions#115.

minor nits / date bump

a9d477a

annevk merged commit 6112060 into whatwg:master Oct 11, 2016

jyasskin deleted the permission-integration branch October 11, 2016 16:46

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Integrate with the Permissions spec. #36

Integrate with the Permissions spec. #36

jyasskin commented Jul 21, 2016

annevk Jul 22, 2016

jyasskin Jul 22, 2016

annevk commented Jul 22, 2016

annevk Jul 22, 2016

jyasskin Jul 22, 2016

annevk Jul 22, 2016

annevk commented Jul 22, 2016

annevk commented Jul 22, 2016

annevk commented Jul 22, 2016

jyasskin commented Jul 22, 2016

annevk commented Jul 23, 2016

annevk Jul 27, 2016

jyasskin Jul 27, 2016

annevk commented Jul 27, 2016

raymeskhoury Jul 28, 2016

annevk Jul 28, 2016

jyasskin Jul 29, 2016

annevk Jul 29, 2016

jyasskin Aug 2, 2016 •

edited

Loading

jyasskin Aug 5, 2016

annevk Aug 8, 2016

annevk Aug 8, 2016

jyasskin Aug 8, 2016

annevk Aug 9, 2016

annevk commented Oct 10, 2016 •

edited

Loading

jyasskin commented Oct 10, 2016

annevk commented Oct 11, 2016

Integrate with the Permissions spec. #36

Integrate with the Permissions spec. #36

Conversation

jyasskin commented Jul 21, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk commented Jul 22, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk commented Jul 22, 2016

annevk commented Jul 22, 2016

annevk commented Jul 22, 2016

jyasskin commented Jul 22, 2016

annevk commented Jul 23, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk commented Jul 27, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jyasskin Aug 2, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk commented Oct 10, 2016 • edited Loading

jyasskin commented Oct 10, 2016

annevk commented Oct 11, 2016

jyasskin Aug 2, 2016 •

edited

Loading

annevk commented Oct 10, 2016 •

edited

Loading