Should the registry include policy-controlled features?

[marcoscaceres]

A question that came up during the meeting with WebAppSec is if we should include both "powerful features" and "policy-controlled features.

Both @miketaylr and I are supportive of the idea, because every powerful feature is as policy-controlled feature (but not the other way around).

We could do this in one of two ways:

1. have two tables, one for powerful features and another that lists the policy-controlled features
2. A single table with three columns, has the token, "is powerful feature" (yes/no), and the spec.

We could then rename the registry to "Registry of Policy-Controlled Features" or something.

CC'ing @clelland + @mozfreddyb for input.

[annevk]

Isn't this largely #6? At least to me it's not clear there is a difference (or ought to be).

[marcoscaceres]

I took #6 to be "the example is no good"; rather than, "should we list every policy-controlled feature in the registry?"

[marcoscaceres]

To rephrase, do we want to include basically all of this: https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md

In this registry?

[annevk]

I see, that registry does not accurately reflect what has been standardized. Generally though, I'd expect the answer to be yes.

[marcoscaceres]

I think it might be a great opportunity for us together define the "criteria for inclusion" (per #8)... I'll clean out the current registry before we publish, and resend each string token as a PR. We can then evaluate against the criteria for each.

I like where this is going 😄

[clelland]

Yes, I think we should, so that the registry can be shared. Policy-controlled-features were intended to be a superset of powerful features (although I don't know if that's true, either in specs or in practice) -- I'd lean towards option 2 in that case, with a boolean to denote whether it is also a powerful feature.

[marcoscaceres]

although I don't know if that's true, either in specs or in practice

Interesting! Our experience with the narrow set we've focused on is that it has been true, so I'm interested in hearing about cases where it hasn't been?

I'd lean towards option 2 in that case, with a boolean to denote whether it is also a powerful feature.

Me too.

Question: should we have also have multiple tables to cover "Proposed Features" and "Experimental Features"?

I'd be in favor or having only two table "Provisional Features" and "Standardized Features", where the latter has at least two interoperable implementations.

We could then discuss the criteria for "Provisional Features" in #8.

[marcoscaceres]

Ok, I'm going to send a PR to generalize everything to "Permissions Registry" which will close this issue.

Let's pick up the discussion in #8.

[clelland]

Interesting! Our experience with the narrow set we've focused on is that it has been true, so I'm interested in hearing about cases where it hasn't been?

I haven't been following the Permissions spec very closely, so it's possible that there are features represented there which are not (yet) covered by Permissions Policy. At a quick glance, I don't think that background-sync or background-fetch are policy-controlled. I'd prefer to see that change, but we might want the registry to reflect reality instead :)

[marcoscaceres]

So, the registry would act as the check/enforcement point that would prevent background-sync or background-fetch from not being policy-controlled features (i.e., we would catch those in the process of adding them to the registry itself).

[annevk]

There are some features which cannot be delegated, such as Notifications and persistent storage. The plan there is to forbid cross-origin usage. I'm not sure if that's common enough to be abstracted out, but it's worth keeping in mind.

[marcoscaceres]

Thanks @annevk. I tried to capture the above in: https://github.com/w3c/permissions/pull/367

Tl;dr: I made it clear that most - but not all - powerful features are policy controlled features.

I'll also add another column to the registry table: "is policy controlled feature?"