w3c / permissions-registry

Registry of known powerful features in the web platform.
https://w3c.github.io/permissions-registry/
1 stars 4 forks source link

Should the registry include policy-controlled features? #7

Closed marcoscaceres closed 2 years ago

marcoscaceres commented 2 years ago

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 commented 2 years ago

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

marcoscaceres commented 2 years ago

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

marcoscaceres commented 2 years ago

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 commented 2 years ago

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

marcoscaceres commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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