search

w3c / webappsec-permissions-policy

A mechanism to selectively enable and disable browser features and APIs
https://w3c.github.io/webappsec-permissions-policy/
Other
395 stars 154 forks source link

Maintain a registry #244

Open annevk opened 5 years ago

annevk commented 5 years ago

Coming from the land of WHATWG, I don't see a problem with a centralized list as we can update standards easily. Having it will help a lot in review, maybe help with consistency, etc.

Opening this as #241 got closed without such a registry.

ojanvafai commented 5 years ago

What concretely are you picturing here? Would a markdown file in this repo mapping names to specs be sufficient?

sideshowbarker commented 5 years ago

Would a markdown file in this repo mapping names to specs be sufficient?

I think that should be sufficient.

More specifically: speaking as someone who’s had need to process data from previous registries we’ve created, I think a file in version-controlled in git that people would need to file PRs to update would be better than the other wiki-based mechanisms we tried in the past (none of which worked out well).

Further, given that it’s data, I think we should make it JSON rather than markdown.

ojanvafai commented 5 years ago

What's the goal of having a registry? I'm not pushing back, just trying to understand. For example, if we're going for human readable markdown makes sense. If it needs to be computer readable, JSON could make more sense.

sideshowbarker commented 5 years ago

What's the goal of having a registry?

For me, one concrete goal is to add support to the HTML checker for checking the value of the allow attribute for the iframe element, and for checking the value of Feature-Policy header.

Specifically, the HTML checker could help a user catch some inadvertent mistakes they may have made in the allow value or Feature-Policy header — particularly any misspelled feature identifiers; e.g., geo-location or something instead of geolocation.

The HTML checker already does similar checking of the content value of the meta http-equiv="content-security-policy" element and the Content-Security-Policy header (though in that case it’s done without the use of any registry).

But I can imagine other purposes for a Feature-Policy registry that wouldn’t need the data as JSON. And for the purposes of the HTML checker, I could of course parse the necessary data out of a markdown file. Having it as JSON would just make it easier.

ojanvafai commented 5 years ago

I don't have strong opinions FWIW. Either way seems reasonable to me.

sideshowbarker commented 5 years ago

I notice now there’s already an existing markdown document at https://github.com/WICG/feature-policy/blob/master/features.md which it seems like could serve as the basis for a registry.

annevk commented 5 years ago

What's the goal of having a registry?

Basically having some place to lookup everything that's in use to get a sense what defining a Feature Policy requires and ensure some kind of consistency is enforced. Ideally the specification would maintain a table of sorts.

frivoal commented 5 years ago

However, to work properly, each feature needs to define in detail what having it enabled or disabled does. That seems best defined in the various specs they affect, as in many cases something like "if $feature is enabled, to $foo, else do $bar" will need to be in a normative algo. And if we do that, it seems that the registry shouldn't be normative, as it would then risk normatively contradict the various specs where this is defined.

That's not to say that having an index of all features wouldn't be useful, but it seems to me that it should be informative, and be generated by bikeshed (or something similar) based on parsing the various specs and aggregating information about all know features.

clelland commented 5 years ago

Perhaps a normative registry of names would be useful, to avoid collisions between specs. The actual definitions and interpretations of the names would be up to the relevant spec to define. (Something like the format of https://www.iana.org/assignments/message-headers/message-headers.xhtml for HTTP headers, which links to RFCs)

triblondon commented 5 years ago

I couldn't find a single list of all the policies that have been implemented, so I made one, FWIW:

https://featurepolicy.info.

clelland commented 5 years ago

That's awesome, @triblondon! I'm going to play with that and see what it can do.

I've also updated features.md to be a more authoritative reference to where the features are defined and what their current standardization state is. (I'll make sure that I have everything from featurepolicy.info included there)

That's probably not quite enough to count as a normative registry; I'm not sure what the next step for that should be though. Reference it from index.bs? Merge it into the spec in a new section? Something else?

Malvoz commented 5 years ago

Merge it into the spec in a new section?

Do W3C specifications occasionally mention web features that are experimental, apart from in editors drafts? There may potentially be many proposed/experimental features (I realize these perhaps would stay in the draft version of the spec) but also possibly vendor-specific features - would that be atypical for specs to include?

Something else?

W3C uses more of a standalone approach for e.g. CSS properties: https://www.w3.org/Style/CSS/all-properties.en.html, maybe?