Hello all,
thank you for your feedback and input.
<hat="individual">
NIH (not invented here) should definitely never be reason for a decision
- in either way.
And I would also be open to assist the WebAppSec WG in writing this tiny
bit into CSP.
I have two main reasons why I think we should keep FO separate to CSP
and would like to hear your thoughts about it before we should make a
decision. (Please note that in the case of this topic I will obviously
not be acting as WG chair.)
1. Model and Semantic Reason:
Until now, I always understood the CSP model to be about "describe the
security policy for a loaded resource and say which parts of that
content you can execute and which references in that content you shall
follow and execute".
While the XFO/FO model is the reverse: describing for a resource,
defining by whom your resource may be framed/loaded from. In my view
that was not a natural part of the CSP model. And in my understanding
that semantic difference was also one of the reasons why it was not done
in CSP1.0 in the first place, but at the time agreed to be done in
websec separately.
Or as someone else from W3C WebAppSec wrote it more clearly to me about
a year ago:
"... removing frame-ancestors from CSP altogether if a better,
standardized Frame-Options is available to sites. In fact, it simplifies
the model in some ways since frame-ancestors is currently the only
directive that restricts content from the embedded site's perspective."
2. Technical Implementation:
The current FO spec allows only one "Allow-From" URI. Which means that
for complex framing relationships, the FO header needs to be
written/sent on the fly on a per request basis.
My question is, what happens to only one "ALLOW-FROM" if we integrate it
into CSP?
Can we generate individual CSPs on the fly as well (including if a CSP
header references a file), or would this then implicitely mean we have
to allow a list of "ALLOW-FROM"?
(please note, that the initial version did allow a list for
"Allow-From", but there were serious concerns for performance in
implementation for large lists and privacy matters. The change to only
one "Allow-From" is not "written in stone", still I would like to
understand if we limit ourselves back to the "Allow-From list"
implicitly by putting it into CSP? I had a couple of private
conversations on this problem in the last months, but they could not
definitively answer to that question...)
Best regards, Tobias
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec