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: 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: 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: 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