Feature Policy syntax: Structured Header?

[clelland]

If we rename the header, then we have a chance to change the syntax, as existing sites would need to make changes anyway.

A concrete proposal here would be a dictionary, mapping features to lists of origins / keywords:

Something-Policy: feature=(self "https://example.com"),
                  another-feature=(),
                  grant-it-to-everyone=(*)

Similar to ES6 arrow function syntax, we could choose to drop the parentheses if there is exactly one item in the list, for developer convenience. (Essentially allowing a single Item to take the place of an Inner List, in SH terms)

If we do this, what should we do with the existing allow attribute? I'd prefer to keep the existing name, and it's not clear that SH-syntax works well in this case -- the double-quotes around origins could be problematic, and there's no clear backwards-compatibility story. The ability to just use <iframe allow="feature; another-feature; a-third-feature"> is a very useful (and widespread) shorthand, but there's no way to make that SH-compatible.

One option is to keep the existing syntax for the attribute, and define it as an alternate serialization of a policy declaration for use in HTML attributes, while the SH serialization is used for headers. I'm not sure if there's precedent for that.

It could also be that the benefits of having exactly one serialization outweigh all of my concerns, and we should just change everything all at once. I'm open to any and all suggestions here.

[annevk]

I was thinking that we keep the allow attribute as-is as it has shipped in at least two implementations (not sure about Safari). It's unfortunate that it has a unique parser, but at least that parser would be bound to the content process.

[clelland]

I think I'm happiest with that outcome, too. It's the least disruptive to developers.

Safari (WebKit at least, not sure about the shipping status) also supports the current allow syntax, so it's been implemented in three engines.

[arturjanc]

My opinion carries little weight here, but I'd be happy if the new header followed the Structured Header format.

No opinions re: the allow attribute, though it does seem like having a different parser there could be a bit counterintuitive. Would it make sense to consider a different attribute (permissions?) with a syntax that matches SH, or is that even less understandable?

[annevk]

It might be interesting to consider if there's a reasonable path to full migration, but as I understand it the allow attribute is already quite widely deployed. The next time we invent a complicated attribute for HTML we should strongly consider something like that though. I don't think it's acceptable to add another custom syntax at this point without a longer term plan.

cc @domenic

[johannhof]

Yeah, looking at bug reports this seems to be used far too much to significantly change it now and a new attribute sounds even messier. I wouldn't say the syntax of allow is too bad to keep, even if it's a separate parser.

[clelland]

Agreed; I'd prefer to leave allow as-is.

Any thoughts on the header syntax? A straightforward dictionary mapping would be as proposed above:

Permissions-Policy: feature=(self "https://example.com"),
                    another-feature=(),
                    grant-it-to-everyone=(*)

I feel like allowing a single origin/keyword to exist outside of an inner list looks nicer, at the cost of a bit of parsing complexity (probably not a significant amount, given an existing structured header parser):

Permissions-Policy: feature=self,
                    another-feature=(),
                    grant-it-to-everyone=*,

An empty list in that case still needs the (), like an ES6 arrow function.

[annevk]

It wouldn't complicate the parser, right? It would complicate the logic on top of the parser result. Allowing that seems reasonable to me. (I don't think we should go as far as allowing the value to be omitted though as that seems like abuse of the boolean type.)

[clelland]

It wouldn't complicate the parser, right? It would complicate the logic on top of the parser result.

Yes, I meant the logic layered on top of the structured header parser.

(I don't think we should go as far as allowing the value to be omitted though as that seems like abuse of the boolean type.)

Agreed. We wouldn't say feature=?1, so abusing the shorthand for that seems wrong.