[whatwg] iframe sandbox attribute

[Ian Melven]

Hi,

While working on implementing HTML5's iframe sandbox, I realized that in script, one can't
tell the difference between these two cases : <iframe> and <iframe sandbox = ''>.

In both cases, iframe.sandbox will be '' (the empty string). This is
true in Webkit and IE10's implementations, as far as my testing can tell (and
in my work-in-progress implementation for Firefox also).

There's also no way to clear sandboxing from an <iframe> without using something along
the lines of .removeAttribute.

Due to this and some sentiment expressed by others at Mozilla against PutForwards
(the HTML5 spec specifies [PutForwards=value] on <iframe>'s sandbox attribute, which is
defined as a DOMSettableTokenList), I would like to propose a possible modification
to the spec : changing <iframe> sandbox to be |string? sandbox| instead of a DOMSettableTokenList.

It is my understanding that this matches what Webkit has implemented. Additionally,
sandbox = null would mean there is no sandbox attribute (i.e. <iframe>) and sandbox = '' would
mean the iframe is fully sandboxed with no permissions granted (ie. <iframe sandbox=''>).

This allows script to tell if an iframe is actually sandboxed or not (well, if it's intended to be
sandboxed or not, to be exact, since changing flags doesn't take affect immediately, per the
HTML5 spec), allows adding and removing sandboxing via the attribute itself, and avoids the need for
a PutForwards.

Comments and feedback are very welcome !

thank you,
ian

[Boris Zbarsky]

On 3/26/12 3:13 PM, Mounir Lamouri wrote:
> I do not like [PutForwards=value] but I still believe
> DOMSettableTokenList is useful.

I think the issue in this case is that the DOMSettableTokenList
representation of the sandbox attribute, as specced, cannot distinguish
between "not sandboxed at all" and "sandboxed, with no loosening of any
restrictions".

That makes it very difficult to use, in my opinion. Very easy to shoot
yourself in the foot.

-Boris

[Ian Hickson]

Changing it to a string doesn't affect that, though, does it?

We can certainly add an attribute to DOMSettableTokenList (or rather, a
descendant, for use specifically with iframe.sandbox) that does the same
as .hasAttribute(), e.g.:

iframe.sandbox.present

...or something, if that would help.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

[Boris Zbarsky]

On 3/26/12 3:19 PM, Ian Hickson wrote:
> Changing it to a string doesn't affect that, though, does it?

Well, changing to a nullable string does affect it because doing
something like this:

myFrame.sandbox = myFrame.sandbox;

is a no-op, as by all sane rights it should be.... More importantly,

myOtherFrame.sandbox = myFrame.sandbox;

doesn't have weird surprising behavior if the attribute is something
whose value sanely distinguishes between the various possible sandbox
values.

> We can certainly add an attribute to DOMSettableTokenList (or rather, a
> descendant, for use specifically with iframe.sandbox) that does the same
> as .hasAttribute(), e.g.:
>
> iframe.sandbox.present
>
> ...or something, if that would help.

Would we also make the attribute readonly, then, and require that it be
set via the token list? Otherwise, it seems like the snippets above
would still have pretty unexpected behavior. But even then they might,
since sets of readonly props are just silently ignored. :(

-Boris

[Adam Barth]

I guess I don't see much value in using DOMSettableTokenList for the
sandbox property. I don't expect folks to mutate the property much.
They're just likely to set it to a constant and be done with it. The
situation is very different for a property like className, where
there's a strong use case for mutating.

Adam

[Adam Barth]

On Fri, Mar 30, 2012 at 12:22 PM, Ian Melven <ime...@mozilla.com> wrote:
> I agree that it's pretty likely folks won't be mutating
> this property very often - the HTML5 spec actually
> recommends against messing with the sandbox attribute dynamically at all :
>
> "Generally speaking, dynamically removing or changing the sandbox attribute is ill-advised,
> because it can make it quite hard to reason about what will be allowed and what will not."
> (which I also agree with. )
>
> that said, what do you think about the case Boris points out where
> myFrame.sandbox = myFrame.sandbox; can change the sandboxing
> of a frame ?
>
> In my opinion, both this and the case involving myOtherFrame.sandbox = myFrame.sandbox;
> are pretty non-intuitive - unless as Boris suggests, .sandbox is null for an iframe which
> hasn't had a sandbox attribute declared. A script author could use .present
> or .hasAttribute to work around this, but my concern is the potentially
> surprising behavior.

IMHO, it's better if the sandbox property behaves like other
properties rather than being magically different. In these cases, the
result is more sandboxing than you might expect rather than less,
which is probably fine.

Adam

[Anne van Kesteren]

On Fri, 30 Mar 2012 23:27:38 +0200, Jonas Sicking <jo...@sicking.cc> wrote:
> I think there's a lot of logic to that. One thing that I think we
> should do as part of that is to drop the DOMSettableTokenList. By far
> more "mapped attributes" are normal DOMStrings.

Such as? I thought the whole point was to do away with that so that
authors do not have to implement the parsing logic anymore.

--
Anne van Kesteren
http://annevankesteren.nl/