Re: [whatwg] The iframe element and sandboxing ideas

2008-05-28 Thread Jonas Sicking



On Mon, 23 Apr 2007, Jonas Sicking wrote:
There's a big difference to that and to what I'm proposing. With what's 
in bug 80713 you're still limited to a box that basically doesn't take 
part of the outer page at all. For example in the table example in my 
original post the headers of the table would not resize to fit the 
column sizes in the includeed table.


Woah. That's far more radical. I have no idea how to do that. How would 
you make the parser not generate the implied elements and switch straight 
to the in table mode? How would you make the CSS model work with this? 
How would you define conformance for the document fragments?


The parser questions here are interesting for sure, but I believe they 
could be solved.


One way to solve the don't make the parser switch into mode X when it 
hits the iframe would be to teach the parser about include (or 
iframe seamless, or iframe include, or whatever it'll be called). 
That is pretty ugly though.


One way to solve the fragment issue would be to say that the inner 
document always has to be a full document, and then use a fragment 
identifier to point to the contents of a table.


The CSS model is simpler. XBL deals with exactly the same problem of 
combining multiple DOMs into a single flattened tree on which CSS is 
applied.


I'm still intending to do some testing with this idea once I get more 
time. A lot of the implementation details have to be solved for XBL anyway.


/ Jonas



Re: The iframe element and sandboxing ideas

2008-05-25 Thread Jon Ferraiolo
 proposal via typical ugly Ajax hacks, such as
 passing messages via postMessage (or the even uglier fragment
 identifer approach).

 Jon




 [image removed] Martin Atkins [EMAIL PROTECTED]



 Martin Atkins [EMAIL PROTECTED]
 Sent by: [EMAIL PROTECTED]
 05/22/08 05:20 AM

 [image removed]
 To

 [image removed]
 Ian Hickson [EMAIL PROTECTED]

 [image removed]
 cc

 [image removed]
 whatwg [EMAIL PROTECTED], HTMLWG [EMAIL PROTECTED],
public-webapi@w3.org

 [image removed]
 Subject

 [image removed]
 Re: The iframe element and sandboxing ideas

 [image removed]

 [image removed]



 Ian Hickson wrote:
  Summary:
 
   * I've added a sandbox= attribute to iframe, which by default
 disables a number of features and takes a space-separated list of
 features to re-enable:
 
 [snip list]

 Unless I'm missing something, this attribute is useless in practice
 because legacy browsers will not impose the restrictions. This means
 that as long as legacy browsers exist (i.e. forever) server-side
 filtering must still be employed to duplicate the effects of the sandbox.

 One alternative would be to use a different element name so that
 fallback content can be provided for legacy browsers. In the short term,
 this is likely to be something like this:

 sandbox src=/comments/blah
 iframe src=/comments/blah?do-security-filtering=1/iframe
 /sandbox

 Once a large percentage of browsers support sandbox authors can start
 to be less accommodating with their fallback content, either by
 filtering out HTML tags entirely (which I'd assume is easier than just
 filtering out script) or at the extreme just setting the fallback
 content to be Your browser is not supported.

 This comment does not address seamless, which seems to be orthogonal
 and can thus be equally applied to both sandbox and iframe as currently
 specified.


 [image removed]

Re: [whatwg] The iframe element and sandboxing ideas

2008-05-24 Thread Ojan Vafai
On Wed, May 21, 2008 at 3:30 PM, Ian Hickson [EMAIL PROTECTED] wrote:

  * I've added a seamless= boolean attribute to iframe, which, if
   the content's active document's URI has the same origin as the
   container, causes the iframe to size vertically to the bounding box
   of the contents, and horizontally to the width of the container,
   and which causes the initial containing block of the contents to be
   treated as zero height. In addition, styles on the root element of
   the content must inherit from the iframe instead of being the
   initial values, and the style sheets that apply to the iframe
   must also apply to the contents. In addition, any time the browsing
   context navigates itself, the parent browsing context gets
   navigated instead.


This looks awesome.

So, the whole point of these is defining elements that are isolated from
their surrounding context on different axes. Same origin iframes currently
just give you CSS isolation. sandbox affords script isolation. seamless
affords the ability to turn off the CSS isolation.

Seems to me that we need a third property which controls event isolation.
Currently events don't propagate in/out of iframes and event coordinates are
all relative to the iframe's viewport (e.g. on mouse events).

My first intuition was that seamless should also just propagate events and
have mouse coordinate be relative to the parent browsing context. But I can
think of cases where you would want to control the two separately. For
example, if you are especially concerned about performance and don't want
events in the parent browsing context to be handled by the iframe's
contents.

Ojan


Re: The iframe element and sandboxing ideas

2008-05-22 Thread Martin Atkins


Ian Hickson wrote:

Summary:

 * I've added a sandbox= attribute to iframe, which by default
   disables a number of features and takes a space-separated list of
   features to re-enable:


[snip list]

Unless I'm missing something, this attribute is useless in practice 
because legacy browsers will not impose the restrictions. This means 
that as long as legacy browsers exist (i.e. forever) server-side 
filtering must still be employed to duplicate the effects of the sandbox.


One alternative would be to use a different element name so that 
fallback content can be provided for legacy browsers. In the short term, 
this is likely to be something like this:


sandbox src=/comments/blah
iframe src=/comments/blah?do-security-filtering=1/iframe
/sandbox

Once a large percentage of browsers support sandbox authors can start 
to be less accommodating with their fallback content, either by 
filtering out HTML tags entirely (which I'd assume is easier than just 
filtering out script) or at the extreme just setting the fallback 
content to be Your browser is not supported.


This comment does not address seamless, which seems to be orthogonal 
and can thus be equally applied to both sandbox and iframe as currently 
specified.





Re: The iframe element and sandboxing ideas

2008-05-22 Thread Jon Ferraiolo

FYI - We have had some discussion in and around the topic of better iframes
at OpenAjax Alliance:

http://www.openajax.org/runtime/wiki/Better_IFrames_Better_Sandboxing

However, people see shortcomings with all proposals listed on that page.
Our hope was that the HTML5 leaders would figure out a good approach, so I
am glad to see that Ian has started discussion on this topic.

Regarding Martin's comments, I think it is a correct objective to find a
bridge between what exists with today's browsers and what we hope will
exist in future browsers. The Ajax community usually needs to get the
desired result in both legacy browsers and new browsers.

If you need to sandbox in today's browsers, what the community tends to use
one of two approaches: (1) require that sandboxed components be expressed
in a restricted subset of HTML and/or JavaScript, such as Caja or ADSafe or
the markup restrictions for portlets, (2) place the sandboxed components
into an IFRAME whose domain or subdomain differs from everything else on
the page (ie, leveraging the browser same-domain policy to achieve
sandboxing). The problem with approach #1 is that some functionality
(potentially critical) is disabled and developers have to in effect learn a
new language. The problem with approach #2 is that isolation is an
all-or-nothing proposition and there are shortcomings with IFRAMEs, such as
lack of automatic content sizing. Ian's proposal below addresses these
IFRAME shortcomings directly, which is great.

If I had time to think extensively about this issue (which I don't), I
would attempt to craft a proposal that used an approach where an Ajax
library performed the mapping between what exists today (i.e., IFRAME) and
what would exist in the future, where Ajax libraries could be eliminated
once older browsers were put out of commission. My initial thought would be
to put a 'sandbox' attribute on a DIV rather than on an IFRAME. That way,
you end up with more powerful sandboxing, along the lines of what Doug
Crockford proposed with his module tag. Newer browsers would deliver the
sandboxing features that Ian is proposing below. For older browsers,
someone could author an Ajax library that looked for DIV elements with a
'sandbox' attribute, and under the hood transformed the DOM such that it
achieved sandboxing via IFRAMEs and implements the flexibility that Ian
describes in his proposal via typical ugly Ajax hacks, such as passing
messages via postMessage (or the even uglier fragment identifer approach).

Jon






   
 Martin Atkins 
 [EMAIL PROTECTED] 
 n.co.uk   To
 Sent by:  Ian Hickson [EMAIL PROTECTED]  
 public-webapi-req  cc
 [EMAIL PROTECTED]   whatwg [EMAIL PROTECTED], HTMLWG
   [EMAIL PROTECTED],   
   public-webapi@w3.org
 05/22/08 05:20 AM Subject
   Re: The iframe element and
   sandboxing ideas
   
   
   
   
   
   





Ian Hickson wrote:
 Summary:

  * I've added a sandbox= attribute to iframe, which by default
disables a number of features and takes a space-separated list of
features to re-enable:

[snip list]

Unless I'm missing something, this attribute is useless in practice
because legacy browsers will not impose the restrictions. This means
that as long as legacy browsers exist (i.e. forever) server-side
filtering must still be employed to duplicate the effects of the sandbox.

One alternative would be to use a different element name so that
fallback content can be provided for legacy browsers. In the short term,
this is likely to be something like this:

sandbox src=/comments/blah
iframe src=/comments/blah?do-security-filtering=1/iframe
/sandbox

Once a large percentage of browsers support sandbox authors can start
to be less accommodating with their fallback content, either by
filtering out HTML tags entirely (which I'd assume is easier than just
filtering out script) or at the extreme just setting the fallback
content to be Your browser is not supported.

This comment does not address seamless, which seems to be orthogonal
and can thus

RE: [whatwg] The iframe element and sandboxing ideas

2008-05-22 Thread Kristof Zelechovski

Legacy browsers will use @SRC which must be filtered.  They will ignore the
new content (whatever the attribute name will be) altogether so it need not
be filtered. Fallback @SRC can contain a URL to an error page saying Sorry,
not in your browser.
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins
Sent: Thursday, May 22, 2008 2:21 PM
To: Ian Hickson
Cc: public-webapi@w3.org; whatwg; HTMLWG
Subject: Re: [whatwg] The iframe element and sandboxing ideas

Ian Hickson wrote:
 Summary:
 
  * I've added a sandbox= attribute to iframe, which by default
disables a number of features and takes a space-separated list of
features to re-enable:
 
[snip list]

Unless I'm missing something, this attribute is useless in practice 
because legacy browsers will not impose the restrictions. This means 
that as long as legacy browsers exist (i.e. forever) server-side 
filtering must still be employed to duplicate the effects of the sandbox.







Re: The iframe element and sandboxing ideas

2008-05-22 Thread Boris Zbarsky


Ian Hickson wrote:

 - by default, content in sandboxed browsing contexts, and any
   browsing contexts nested in them


How do those nested browsing contexts come about, given that later you say:

 - content in those browsing contexts cannot create new browsing
   contexts or open modal dialogs or alerts

?


   have a unique origin
   (independent of the origin of their URI); this can be overriden
   using the allow-same-origin keyword


So the parent page cannot script the contents of the iframe by default, right?


 - by default, script in those browsing contexts cannot run; this can
   be overriden using the allow-scripts keyword


What happens if the parent page sets window.location to a javascript: URI on the 
sandbox iframe?  Does the script run?  If so, in which browsing context?



   causes the iframe to size vertically to the bounding box
   of the contents, and horizontally to the width of the container


I assume that the bounding box is computed after setting the width?

By the width of the container do you mean that the iframe computed width 
should be equal to its containing block's computed width?  Or that the 
display:block non-replaced width algorithm from CSS should be used?



   and which causes the initial containing block of the contents to be
   treated as zero height.


So percentage heights would end up being 0, while the iframe would be whatever 
height is needed if one assumes they're auto?



   and the style sheets that apply to the iframe
   must also apply to the contents.


But the ' ' and '' combinators don't cross the iframe boundary, right?

This is all HIGHLY EXPERIMENTAL. I am looking for feedback on the general 
approaches taken.


As someone else pointed out, this doesn't seem like it would be usable without 
some UA sniffing or something, as things stand.


There are various things that this doesn't address yet; e.g. there's no 
way to force (or even allow) a non-seamless iframe to open links in the 
parent window.


This could be an @sandbox keyword value.

This attribute would 
take a string which would then be interpreted as the source document 
markup of an HTML document, much like the above


This seems very prone to security issues (injection of the closing quote in the 
content) to me...  The base64 approach is nice in that you can't shoot yourself 
in the foot with it.


-Boris



RE: [whatwg] The iframe element and sandboxing ideas

2008-05-22 Thread Kristof Zelechovski

1. Nested browsing contexts in a sandboxed frame cannot be created
dynamically but they can be defined by the inner markup.
2. If the frame is not allowed to execute scripts, setting location to
script should have no effect.
3. There is a potential discrepancy between applying parent width, which is
characteristic to block-level elements, and the declared element level in
that the level of a frame depends on an attribute.  This is unprecedented:
the elements in HTML have a fixed level by design.  Introducing a new
element should be reconsidered in view of that IMHO.
4. Percentage in height scales to the container's height, not to the initial
dimensions of the current element.  It is an error if the container's height
is left implicit or if the sum of percentages exceeds 100%.
5. The argument against SANDBOX is that the user could inject /SANDBOX.  The
argument against code attribute is that the user could inject a quote.
Aren't these similar enough to reconsider SANDBOX?  
It seems it is easier to sanitize quotes because the burden of quoting is on
the user.
Compare 'SANDBOX SANDBOX /SANDBOX /SANDBOX ' to 'SPAN
TITLE=quot; /SPAN ' that must be converted to 'SPAN
TITLE=quot;amp;quot;quot; /SPAN '.  The quoting required seems
straightforward.  I agree that using a data URL is simpler and cannot be
viewed as an obstacle to productivity since the author's text must be
processed anyway, so why not just encode it?  And it is more consistent with
contemporary technology.
HTH,
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Boris Zbarsky
Sent: Thursday, May 22, 2008 6:27 PM
To: Ian Hickson
Cc: public-webapi@w3.org; whatwg; HTMLWG
Subject: Re: [whatwg] The iframe element and sandboxing ideas

Ian Hickson wrote:
  - by default, content in sandboxed browsing contexts, and any
browsing contexts nested in them

How do those nested browsing contexts come about, given that later you say:

  - content in those browsing contexts cannot create new browsing
contexts or open modal dialogs or alerts

?

have a unique origin
(independent of the origin of their URI); this can be overriden
using the allow-same-origin keyword

So the parent page cannot script the contents of the iframe by default,
right?

  - by default, script in those browsing contexts cannot run; this can
be overriden using the allow-scripts keyword

What happens if the parent page sets window.location to a javascript: URI on
the 
sandbox iframe?  Does the script run?  If so, in which browsing context?

causes the iframe to size vertically to the bounding box
of the contents, and horizontally to the width of the container

I assume that the bounding box is computed after setting the width?

By the width of the container do you mean that the iframe computed width 
should be equal to its containing block's computed width?  Or that the 
display:block non-replaced width algorithm from CSS should be used?

and which causes the initial containing block of the contents to be
treated as zero height.

So percentage heights would end up being 0, while the iframe would be
whatever 
height is needed if one assumes they're auto?

and the style sheets that apply to the iframe
must also apply to the contents.

But the ' ' and '' combinators don't cross the iframe boundary, right?

 This is all HIGHLY EXPERIMENTAL. I am looking for feedback on the general 
 approaches taken.

As someone else pointed out, this doesn't seem like it would be usable
without 
some UA sniffing or something, as things stand.

 There are various things that this doesn't address yet; e.g. there's no 
 way to force (or even allow) a non-seamless iframe to open links in the 
 parent window.

This could be an @sandbox keyword value.

 This attribute would 
 take a string which would then be interpreted as the source document 
 markup of an HTML document, much like the above

This seems very prone to security issues (injection of the closing quote in
the 
content) to me...  The base64 approach is nice in that you can't shoot
yourself 
in the foot with it.

-Boris





Re: [whatwg] The iframe element and sandboxing ideas

2008-05-22 Thread Boris Zbarsky


Kristof Zelechovski wrote:

1. Nested browsing contexts in a sandboxed frame cannot be created
dynamically but they can be defined by the inner markup.


There was no mention of dynamically in Ian's proposal.  My assumption 
was that cannot create browsing contexts meant just that.  If it 
doesn't, the wording needs some changes.



2. If the frame is not allowed to execute scripts, setting location to
script should have no effect.


OK.  Again, that was not clear in the original proposal.


4. Percentage in height scales to the container's height, not to the initial
dimensions of the current element.  It is an error if the container's height
is left implicit


It's not an error in CSS.  Or are you suggesting a different algorithm?


or if the sum of percentages exceeds 100%.


Again, not a problem in CSS.  Percentages of auto just get treated as 
auto.  If you're suggesting a totally different algorithm, it needs a 
lot of fleshing out.



5. The argument against SANDBOX is that the user could inject /SANDBOX.  The
argument against code attribute is that the user could inject a quote.
Aren't these similar enough to reconsider SANDBOX?  


SANDBOX and the non-base64 attribute thing seem pretty similar in a lot 
of ways to me, except that the iframe (having a separate Window and 
such) might be easier to secure in existing implementations.


-Boris



Re: The iframe element and sandboxing ideas

2008-05-21 Thread Andrew Fedoniouk


Ian Hickson wrote:


Summary:

 * I've added a sandbox= attribute to iframe, which by default
   disables a number of features and takes a space-separated list of
   features to re-enable:


...

Makes sense, Ian.

Additionally to this, what about adding meta tag that disables or 
limits features of the page if it is running inside frame or iframe?


Say something like this:

html
  head
meta name=allowed-context value=standalone-only /
  /head
  ...
/html

That may prevent some types of malicious uses.

--
Andrew Fedoniouk.

http://terrainformatica.com