W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2013

Re: 'frame-options' and 'deny'.

From: Daniel Veditz <dveditz@mozilla.com>
Date: Wed, 27 Nov 2013 13:21:29 -0800
Message-ID: <52966259.6050802@mozilla.com>
To: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
CC: Brad Hill <bhill@paypal-inc.com>, Garrett Robinson <grobinson@mozilla.com>
On 11/27/2013 3:02 AM, Mike West wrote:
> 1. Change the name to match Mozilla's 'frame-ancestors'

X-Frame-Options is far, far more widely used on the web than CSP, and of
the sites using CSP frame-ancestors doesn't seem that common. Calling
the directive 'frame-options' might have some educational benefit. Then
again it leads to your deny/none dilemma...

I don't feel strongly about which name is used; Firefox will likely
continue supporting frame-ancestors as a deprecated synonym for a while
if we go with frame-options.

> 2.  Replace the 'deny' keyword with 'none'.

Please! We already use 'self' instead of SAMEORIGIN, right? I was
thinking of objecting to 'deny' as well.

> 1. Folks already using 'frame-ancestors' would be subject to the more
> strict ancestor-checking in the current spec. I can't really judge how
> much of a concern this is. Mozilla folks: do you have an idea how
> widely-used the current behavior is?

What difference are you seeing? frame-ancestors should apply to all
ancestors no matter how deep the frames are nested. This was in
Mozilla's original spec before MS had even announced XFO.

> 2. We close the door on other "options" in the future. Are there other
> things planned that would make the (not terribly painful) pain of
> implementing another directive parser worthwhile?

We could still add "modifiers" in the future if you drop the -options
name (the way 'unsafe-inline' modifies script-src behavior) but not full
independent frame behaviors. Can't think of ones we'd want to add other
than sandboxing and we've already got that as a separate directive.

Unless we plan additional features the name frame-options is vague and
unclear, except to the extent people are familiar with the XFO header.
The header is slightly clearer in use, though, because it's not "XFO:
<origin>" but "XFO: allow-from <origin>".

If people object to the length of frame-ancestors we could also consider
'framers' which is half as long and still clearer about what it does
than frame-options.

-Dan Veditz



Received on Wednesday, 27 November 2013 21:21:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:03 UTC