[webappsec] UI Security, allow-from values

This resolves ACTION 118, and will be on the agenda for the 2/26 call after 2 weeks for discussion.

Where X-Frame-Options is currently implemented, and as specified at the IETF, the ALLOW-FROM directive allows only a single value.

As part of moving future, normative work on frame-options in to the UI Security draft, we have preserved this syntax restriction, (with the addition of allowing "self") but want to revisit it.

I hope that Tobias and David Ross will join this conversation to make their take on the issues explicit, but my best understanding of the two perspectives is:

Multiple-values: CON

Allowing multiple values will encourage some or many sites to put a large set of values into this header.  This will have potentially negative impacts on privacy, performance and implementation complexity.   Just as the CORS Access-Control-Allow-Access header allows only a single value, ALLOW-FROM should do the same and require dynamically generated responses.

Unlike other CSP directives that allow multiple values for included content, those are likely to have a small number of values, whereas ALLOW-FROM might routinely have hundreds or even tens of thousands of possible valid values, so this is a different case where we need to encourage (force) a different set of practices.

Multiple-values: PRO

Allowing multiple values is necessary for multiply-nested frame use-cases.
Allowing multiple values is consistent with other policies in CSP.
CSP already allows multiple values for most policies so any implementation complexity is already paid for.
The choice to dynamically generate vs. include multiple values is a privacy and performance cost primarily borne by resource owners, and should therefore be at their discretion.

Side issue: Caching vs. dynamic generation?

Does forcing a single value (and hence dynamic generation of the policy) restrict or impact on the use-cases of CSP, e.g. prevent it from being used where caching is necessary.   I don't think this is the case, especially since we now allow combining multiple policy headers, but Tobias may be able to elaborate more here?


My suggestion would be to allow for multiple values, but put non-normative implementation guidance for policy authors suggesting that, while the EBNF doesn't set any hard limits on the number of origin tokens valid for any policy, in practice user agent implementations will have limits on the number of such tokens they will process, and that dynamic generation should be preferred over including a large number of values.

-Brad Hill