Re: [whatwg] iframe sandbox attribute
On Tue, 10 Jul 2012 02:39:45 +0200, Ian Hickson i...@hixie.ch wrote: On Mon, 26 Mar 2012, Boris Zbarsky wrote: 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 Surely that's going to set the attribute regardless of whether the attribute is nullable or whatnot. I mean, this always sets the attribute even if the attribute wasn't previously set: myElement.title = myElement.title https://www.w3.org/Bugs/Public/show_bug.cgi?id=17283 -- Simon Pieters Opera Software
Re: [whatwg] iframe sandbox attribute
On Mon, 9 Jul 2012, Boris Zbarsky wrote: On 7/9/12 8:39 PM, Ian Hickson wrote: Surely that's going to set the attribute regardless of whether the attribute is nullable or whatnot. Well, that depends on how reflecting DOMString? attributes are defined. Making setting null call removeAttribute would work much like boolean attributes work. That's an interesting idea, but it seems to me to be a bit late to be making such a fundamental change to the HTML DOM API. I mean, so far no attributes work that way (except in WebKit, apparently?); boolean attributes are the only ones where there's any way to remove the attribute by setting a value, more or less. It's not the first attribute where the empty string means something different than the attribute being omitted. 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. I'm not sure I follow. The point is that 'not set' and 'empty string' don't mean the same thing for @sandbox, and ideally the DOM reflection would preserve the distinction. Since it doesn't for any other attributes that take a string but where empty string and absence are different, why is it suddenly an issue specifically with this attribute? I think remaining consistent with other non-boolean attributes, and thus having the setter always set the attribute, is fine. And I think it's a footgun. No more so, I'd wager, than being inconsistent with the other attributes. I think the situation would be different if you were asking about changing the behaviour of all content attributes rather than one specific one. That's what Simon is arguing for here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17283 I'm not sure that makes sense either, but it's more plausible, IMHO, especially given that at least one UA apparently already does it. If Gecko also changed in this manner it would make the decision a lot easier. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] iframe sandbox attribute
On 7/10/12 12:27 PM, Ian Hickson wrote: Since it doesn't for any other attributes that take a string but where empty string and absence are different, why is it suddenly an issue specifically with this attribute? Because this is a new attribute we're defining and I happened to notice? ;) I think the situation would be different if you were asking about changing the behaviour of all content attributes rather than one specific one. That's what Simon is arguing for here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17283 I'm not sure that makes sense either, but it's more plausible, IMHO, especially given that at least one UA apparently already does it. If Gecko also changed in this manner it would make the decision a lot easier. :-) Hmm. That might be doable, in fact. I'll shop it around. -Boris
Re: [whatwg] iframe sandbox attribute
On Mon, 26 Mar 2012, Boris Zbarsky wrote: 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 Surely that's going to set the attribute regardless of whether the attribute is nullable or whatnot. I mean, this always sets the attribute even if the attribute wasn't previously set: myElement.title = myElement.title 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. I'm not sure I follow. 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. :( I think remaining consistent with other non-boolean attributes, and thus having the setter always set the attribute, is fine. On Thu, 29 Mar 2012, Adam Barth wrote: 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. On Fri, 30 Mar 2012, Ian Melven 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. On Fri, 30 Mar 2012, Adam Barth wrote: 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. On Fri, 30 Mar 2012, Jonas Sicking 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. On Sat, 31 Mar 2012, Anne van Kesteren wrote: 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. Upon reflection, I haven't changed anything here. I don't see much value in making an exception to 'sandbox' here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] iframe sandbox attribute
On 7/9/12 8:39 PM, Ian Hickson wrote: Surely that's going to set the attribute regardless of whether the attribute is nullable or whatnot. Well, that depends on how reflecting DOMString? attributes are defined. Making setting null call removeAttribute would work much like boolean attributes work. I mean, this always sets the attribute even if the attribute wasn't previously set: myElement.title = myElement.title Yes, but myElement.checked = myElement.checked does not. 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. I'm not sure I follow. The point is that 'not set' and 'empty string' don't mean the same thing for @sandbox, and ideally the DOM reflection would preserve the distinction. I think remaining consistent with other non-boolean attributes, and thus having the setter always set the attribute, is fine. And I think it's a footgun. -Boris
Re: [whatwg] iframe sandbox attribute
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/
Re: [whatwg] iframe sandbox attribute
On Fri, Mar 30, 2012 at 12:22 PM, Ian Melven imel...@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 - Original Message - From: Adam Barth w...@adambarth.com To: Boris Zbarsky bzbar...@mit.edu Cc: whatwg@lists.whatwg.org Sent: Thursday, March 29, 2012 2:17:42 PM Subject: Re: [whatwg] iframe sandbox attribute 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 On Mon, Mar 26, 2012 at 4:06 PM, Boris Zbarsky bzbar...@mit.edu wrote: 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
Re: [whatwg] iframe sandbox attribute
On Fri, Mar 30, 2012 at 1:14 PM, Adam Barth w...@adambarth.com wrote: On Fri, Mar 30, 2012 at 12:22 PM, Ian Melven imel...@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. 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. / Jonas
Re: [whatwg] iframe sandbox attribute
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 On Mon, Mar 26, 2012 at 4:06 PM, Boris Zbarsky bzbar...@mit.edu wrote: 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
[whatwg] iframe sandbox attribute
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
Re: [whatwg] iframe sandbox attribute
On 03/26/2012 02:37 PM, Ian Melven wrote:
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).
element.hasAttribute('sandbox') should return false for the former case
and true for the later.
There's also no way to clear sandboxing from an iframe without using
something along
the lines of .removeAttribute.
If you want to remove the sandbox attribute, isn't removeAttribute the
best way to do that?
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.
I do not like [PutForwards=value] but I still believe
DOMSettableTokenList is useful.
Cheers,
--
Mounir
Re: [whatwg] iframe sandbox attribute
On Mon, 26 Mar 2012, Ian Melven wrote:
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).
Just use iframe.hasAttribute('sandbox').
The same applies to a lot of attributes in HTML, the situation is not
unique to the sandbox= attribute. I don't think we need to change it to
address this issue, since there is already an API for it.
HTH,
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] iframe sandbox attribute
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
Re: [whatwg] iframe sandbox attribute
On Mon, 26 Mar 2012, Boris Zbarsky wrote: 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. 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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] iframe sandbox attribute
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
Re: [whatwg] Iframe Sandbox Attribute - allow-plugins?
On 2011-07-14 17:01, Jonas Sicking wrote: ... True. I would be fine with removing the plugin requirement. Or changing it such that it states that plugins can only be loaded if it's done in a manner that ensures that all other requirements are still fulfilled. Or just dealing with this once there actually are plugins and plugin APIs which could be loaded while still fulfilling the other requirements. ... Well, the spec is in W3C LC. So if we think this requirement needs to be rephrased then it should be brought up as a problem. Best regards, Julian
Re: [whatwg] Iframe Sandbox Attribute - allow-plugins?
On Wed, Jul 13, 2011 at 9:49 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 13 Jul 2011 23:13:05 +0200, Julian Reschke julian.resc...@gmx.de wrote: Yes, but we can *define* the flag in HTML and write down what it means with respect to plugin APIs. It seems much better to wait until it can actually be implemented. Especially since it's not at all clear to me that a specific opt-in mechanism is at all needed once we have the appropriate plugin APIs implemented. And those APIs are needed anyway if we want to allow plugins in any form in the sandbox. / Jonas
Re: [whatwg] Iframe Sandbox Attribute - allow-plugins?
On 2011-07-14 08:22, Jonas Sicking wrote: On Wed, Jul 13, 2011 at 9:49 PM, Anne van Kesterenann...@opera.com wrote: On Wed, 13 Jul 2011 23:13:05 +0200, Julian Reschkejulian.resc...@gmx.de wrote: Yes, but we can *define* the flag in HTML and write down what it means with respect to plugin APIs. It seems much better to wait until it can actually be implemented. Especially since it's not at all clear to me that a specific opt-in mechanism is at all needed once we have the appropriate plugin APIs implemented. And those APIs are needed anyway if we want to allow plugins in any form in the sandbox. When the attribute is set, the content is treated as being from a unique origin, forms and scripts are disabled, links are prevented from targeting other browsing contexts, and plugins are disabled. A browser negotiating something with plugins using that API and enabling them despite @sandbox would violate the above requirement, no?
Re: [whatwg] Iframe Sandbox Attribute - allow-plugins?
On Thu, Jul 14, 2011 at 1:16 AM, Julian Reschke julian.resc...@gmx.de wrote: On 2011-07-14 08:22, Jonas Sicking wrote: On Wed, Jul 13, 2011 at 9:49 PM, Anne van Kesterenann...@opera.com wrote: On Wed, 13 Jul 2011 23:13:05 +0200, Julian Reschkejulian.resc...@gmx.de wrote: Yes, but we can *define* the flag in HTML and write down what it means with respect to plugin APIs. It seems much better to wait until it can actually be implemented. Especially since it's not at all clear to me that a specific opt-in mechanism is at all needed once we have the appropriate plugin APIs implemented. And those APIs are needed anyway if we want to allow plugins in any form in the sandbox. When the attribute is set, the content is treated as being from a unique origin, forms and scripts are disabled, links are prevented from targeting other browsing contexts, and plugins are disabled. A browser negotiating something with plugins using that API and enabling them despite @sandbox would violate the above requirement, no? True. I would be fine with removing the plugin requirement. Or changing it such that it states that plugins can only be loaded if it's done in a manner that ensures that all other requirements are still fulfilled. Or just dealing with this once there actually are plugins and plugin APIs which could be loaded while still fulfilling the other requirements. / Jonas
[whatwg] Iframe Sandbox Attribute - allow-plugins?
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox Are there plans to have an 'allow-plugins' value? I'm assuming there will be use-cases where the only protection that is desired is prevention of parent redirection. Thanks
Re: [whatwg] Iframe Sandbox Attribute - allow-plugins?
Adding allow-plugins today would defeat the prevention of parent redirection. The short answer is we need an API for informing plugins of the sandbox flags and a way of confirming that the plugins understand those bits before we can allow plugins inside sandboxed frames. Adam On Wed, Jul 13, 2011 at 12:53 PM, John Richards johnmrricha...@gmail.com wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox Are there plans to have an 'allow-plugins' value? I'm assuming there will be use-cases where the only protection that is desired is prevention of parent redirection. Thanks
Re: [whatwg] Iframe Sandbox Attribute - allow-plugins?
On 2011-07-13 22:31, Adam Barth wrote: Adding allow-plugins today would defeat the prevention of parent redirection. The short answer is we need an API for informing plugins of the sandbox flags and a way of confirming that the plugins understand those bits before we can allow plugins inside sandboxed frames. ...but that API is outside the scope of what the W3C and the WhatWG currently do, so I think it would be great if defining this flag could be decoupled from progress on the plugin API layers. Best regards, Julian
Re: [whatwg] Iframe Sandbox Attribute - allow-plugins?
On Wed, Jul 13, 2011 at 1:55 PM, Julian Reschke julian.resc...@gmx.de wrote: On 2011-07-13 22:31, Adam Barth wrote: Adding allow-plugins today would defeat the prevention of parent redirection. The short answer is we need an API for informing plugins of the sandbox flags and a way of confirming that the plugins understand those bits before we can allow plugins inside sandboxed frames. ...but that API is outside the scope of what the W3C and the WhatWG currently do, so I think it would be great if defining this flag could be decoupled from progress on the plugin API layers. It is coupled in the sense that we can't implement the flag unless and until such a plug-in API exists. Adam
Re: [whatwg] Iframe Sandbox Attribute - allow-plugins?
On 2011-07-13 22:58, Adam Barth wrote: On Wed, Jul 13, 2011 at 1:55 PM, Julian Reschkejulian.resc...@gmx.de wrote: On 2011-07-13 22:31, Adam Barth wrote: Adding allow-plugins today would defeat the prevention of parent redirection. The short answer is we need an API for informing plugins of the sandbox flags and a way of confirming that the plugins understand those bits before we can allow plugins inside sandboxed frames. ...but that API is outside the scope of what the W3C and the WhatWG currently do, so I think it would be great if defining this flag could be decoupled from progress on the plugin API layers. It is coupled in the sense that we can't implement the flag unless and until such a plug-in API exists. Yes, but we can *define* the flag in HTML and write down what it means with respect to plugin APIs. Best regards, Julian
Re: [whatwg] Iframe Sandbox Attribute - allow-plugins?
On Wed, 13 Jul 2011 23:13:05 +0200, Julian Reschke julian.resc...@gmx.de wrote: Yes, but we can *define* the flag in HTML and write down what it means with respect to plugin APIs. It seems much better to wait until it can actually be implemented. -- Anne van Kesteren http://annevankesteren.nl/
