Re: [whatwg] Sandboxing scripts in pages

[James M Snell]

Comments on a blog, no. (I'm not sure who brought up that use case). I'm
thinking more along the lines of widgets embedded into a page. E.g.,
many users of our internal blogs like to embed widgets from various
external sites into their templates.  Many of these are embedded using
.  Because these scripts run within the context of
the larger page, a potentially malicious script that has access to the
complete DOM could silently scrape content from the page and send that
out to an external server.

Again, I'm not proposing any particular solution.  Nor am I saying there
aren't already existing solutions to these problems that can work.  What
I'm saying is that having some way of isolating a script would be ideal
and I was curious as to what others had to say about it.

- James

Jorgen Horstink wrote:
> 
> On Jan 12, 2007, at 10:30 PM, James M Snell wrote:
> 
>>
>> Anne van Kesteren wrote:
>>> [snip]

 Frames are a terrible solution. The content is after all a part of the
 page it's hosted in, but we want to sandbox it to make sure it can't
 do any harm.
>>>
>>> The proposed alternative is severely underdefined and won't work for the
>>> foreseeable future anyway.
>>> [snip]
>>
>> Minor nit:
>>
>>   s/proposed alternative/simple strawman to illustrate the point/
>>
>> I just want the behavior or something that comes close without
>> necessarily having to resort to aggressive filtering.  That is, I don't
>> necessarily want to eliminate scripts from the comments, I just want to
>> be able to limit their impact.
>>
>> Either way, I'm fully aware that any new invention here would take a
>> while to actually work.
>>
>> - James
>>
> Please provide a real use case. I second Anne's point of comment
> sanitation. Can you give me one single use case when it is useful to use
> ECMAScript in a comment on a blog? Secondly, just as Bjoern states; a
> malicious script could easily position new element on top of other
> elements. Or do you want to restrict that too? I cannot see what CSS has
> to do with it, since it is not a style issue, but a DOM access behavior
> issue.
> 
> -- Jorgen
> 
> 

Re: [whatwg] Sandboxing scripts in pages

[Andrew Fedoniouk]

Why not to do something like this:

   function evalInSandbox(str)
   {
 var window = null; // shields of global objects
 var document = { managedThunk1: function() {...}; managedThunk2: 
function() 
{...};  }
 var self = null;

 function getElement(id)
{

}
 eval(  str );
   }

?

So
   evalInSandbox("getElement('id')");  will succeed
and
   evalInSandbox("document.getElementById('id')");  will fail.

Andrew Fedoniouk.
http://terrainformatica.com



- Original Message - 
From: "James M Snell" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 12, 2007 8:34 AM
Subject: [whatwg] Sandboxing scripts in pages


| Hello,
|
| I've recently been musing over some ideas around sandboxing scripts and
| styles within a document [1].  The basic idea is to have some means of
| isolating potentially untrustworthy scripts.
|
|  From my blog entry: "Scripts within the sandbox would only see the DOM
|  of the sandbox. Methods defined outside the sandbox would still be
|  accessible. External methods could return objects from outside the
|  sandbox."
|
| The example I go on to give is this:
|
|  
|  
|
|  function getElement(id) {
|return document.getElementById(id);
|  }
|
|
|
|  
|  
|// this will fail because b1 does not exist in sandbox a
|document.getElementById('b1').innerHTML = "foo";
|
|// this will succeed because getElement(id) can be called from
|  within sandbox a
|getElement('b1').innerHTML = "foo";
|  
|
|
|
|  
|
|  
|  
|
| The use of the sandbox tag is purely illustrative.  As Asbjørn Ulsberg
| points out in the comments on my entry, the same effect could be
| achieved using either a new DOM and/or CSS property. For instance, we
| could replace the  with  (or
| some variation thereof).
|
| Whatever shape the mechanism ultimately takes, having a way of isolating
| scripts within a document would be extremely beneficial.
|
| Thoughts?
|
| - James
|
| [1] http://www.snellspace.com/wp/?p=582
| 

Re: [whatwg] Sandboxing scripts in pages

[Jorgen Horstink]

On Jan 12, 2007, at 10:30 PM, James M Snell wrote:



Anne van Kesteren wrote:

[snip]


Frames are a terrible solution. The content is after all a part  
of the

page it's hosted in, but we want to sandbox it to make sure it can't
do any harm.


The proposed alternative is severely underdefined and won't work  
for the

foreseeable future anyway.
[snip]


Minor nit:

  s/proposed alternative/simple strawman to illustrate the point/

I just want the behavior or something that comes close without
necessarily having to resort to aggressive filtering.  That is, I  
don't
necessarily want to eliminate scripts from the comments, I just  
want to

be able to limit their impact.

Either way, I'm fully aware that any new invention here would take a
while to actually work.

- James

Please provide a real use case. I second Anne's point of comment  
sanitation. Can you give me one single use case when it is useful to  
use ECMAScript in a comment on a blog? Secondly, just as Bjoern  
states; a malicious script could easily position new element on top  
of other elements. Or do you want to restrict that too? I cannot see  
what CSS has to do with it, since it is not a style issue, but a DOM  
access behavior issue.


-- Jorgen

Re: [whatwg] Sandboxing scripts in pages

[James M Snell]

Anne van Kesteren wrote:
>[snip]
>>
>> Frames are a terrible solution. The content is after all a part of the
>> page it's hosted in, but we want to sandbox it to make sure it can't
>> do any harm.
> 
> The proposed alternative is severely underdefined and won't work for the
> foreseeable future anyway.
> [snip]

Minor nit:

  s/proposed alternative/simple strawman to illustrate the point/

I just want the behavior or something that comes close without
necessarily having to resort to aggressive filtering.  That is, I don't
necessarily want to eliminate scripts from the comments, I just want to
be able to limit their impact.

Either way, I'm fully aware that any new invention here would take a
while to actually work.

- James

Re: [whatwg] Sandboxing scripts in pages

[Anne van Kesteren]

On Fri, 12 Jan 2007 22:09:40 +0100, Asbjørn Ulsberg  
<[EMAIL PROTECTED]> wrote:
Use an  and use cross-document messaging? This has been  
discussed a lot by the way.


Frames are a terrible solution. The content is after all a part of the  
page it's hosted in, but we want to sandbox it to make sure it can't do  
any harm.


The proposed alternative is severely underdefined and won't work for the  
foreseeable future anyway.



Let's say we'd like to sandbox anonymous user-contributed comments on a  
blog, but not comments from logged in users. That would require all  
anonymous comments to be placed within an iframe. For 100 anonymous  
comments, that's 100 iframes on a single web page. Don't tell me that's  
an elegant solution.


Why wouldn't have you have comment sanitization? Nope that you could use  
data: URIs on the s.



--
Anne van Kesteren

Re: [whatwg] Sandboxing scripts in pages

[Asbjørn Ulsberg]

On Fri, 12 Jan 2007 17:37:43 +0100, Anne van Kesteren <[EMAIL PROTECTED]>  
wrote:



Whatever shape the mechanism ultimately takes, having a way of isolating
scripts within a document would be extremely beneficial.


Use an  and use cross-document messaging? This has been  
discussed a lot by the way.


Frames are a terrible solution. The content is after all a part of the  
page it's hosted in, but we want to sandbox it to make sure it can't do  
any harm.


Let's say we'd like to sandbox anonymous user-contributed comments on a  
blog, but not comments from logged in users. That would require all  
anonymous comments to be placed within an iframe. For 100 anonymous  
comments, that's 100 iframes on a single web page. Don't tell me that's an  
elegant solution.


--
Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

Re: [whatwg] Sandboxing scripts in pages

[Anne van Kesteren]

On Fri, 12 Jan 2007 20:53:12 +0100, Asbjørn Ulsberg  
<[EMAIL PROTECTED]> wrote:
The CSS property has already been mentioned on this list, but the  
discussion faded kind of quick so I would like to bring it up again.


Probably because CSS is off-topic for this list. There's www-style for  
that.



--
Anne van Kesteren

Re: [whatwg] Sandboxing scripts in pages

[Asbjørn Ulsberg]

On Fri, 12 Jan 2007 17:34:03 +0100, James M Snell <[EMAIL PROTECTED]>  
wrote:



Whatever shape the mechanism ultimately takes, having a way of isolating
scripts within a document would be extremely beneficial.


+1. I think having a separate HTML element is the wrong solution, but a  
CSS property called 'reset'[1] and a DOM property called 'restrict'[2]  
could achieve the same goal but without "polluting" HTML with stuff that  
isn't really HTML related and which semantics doesn't make sense in an  
HTML context.


The CSS property has already been mentioned on this list, but the  
discussion faded kind of quick so I would like to bring it up again.



1. With the possible values of '*' (resets the inheritance and cascade of  
all properties) and all CSS property values defined in CSS1+2+3.

2. Not sure which values this property should have yet.

--
Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

Re: [whatwg] Sandboxing scripts in pages

[Bjoern Hoehrmann]

* James M Snell wrote:
>Whatever shape the mechanism ultimately takes, having a way of isolating
>scripts within a document would be extremely beneficial.

It would be helpful if you could first explain what pain you are trying
to solve and how your solution would solve it. For example, a malicious
script could create a new layer in the sandbox and position it so that
it is rendered on top of the rest of the document. Why wouldn't that be
a problem? Or, since the script in the sandbox apparently can execute
all other author-defined functions, what if the author of the host page
includes some scripting library that, say, provides indirect access to
document.cookie; a malicious script could then easily steal the cookie.

You naturally also cannot use 

Re: [whatwg] Sandboxing scripts in pages

[Dean Edwards]

Anne van Kesteren wrote:
On Fri, 12 Jan 2007 17:34:03 +0100, James M Snell <[EMAIL PROTECTED]> 
wrote:

Whatever shape the mechanism ultimately takes, having a way of isolating
scripts within a document would be extremely beneficial.

Thoughts?


Use an  and use cross-document messaging? This has been 
discussed a lot by the way.




I posted a method to do this recently:

http://dean.edwards.name/weblog/2006/11/sandbox/

-dean

Re: [whatwg] Sandboxing scripts in pages

[Anne van Kesteren]

On Fri, 12 Jan 2007 17:34:03 +0100, James M Snell <[EMAIL PROTECTED]>  
wrote:

Whatever shape the mechanism ultimately takes, having a way of isolating
scripts within a document would be extremely beneficial.

Thoughts?


Use an  and use cross-document messaging? This has been discussed  
a lot by the way.



--
Anne van Kesteren

[whatwg] Sandboxing scripts in pages

[James M Snell]

Hello,

I've recently been musing over some ideas around sandboxing scripts and
styles within a document [1].  The basic idea is to have some means of
isolating potentially untrustworthy scripts.

  From my blog entry: "Scripts within the sandbox would only see the DOM
  of the sandbox. Methods defined outside the sandbox would still be
  accessible. External methods could return objects from outside the
  sandbox."

The example I go on to give is this:

  
  

  function getElement(id) {
return document.getElementById(id);
  }



  
  
// this will fail because b1 does not exist in sandbox a
document.getElementById('b1').innerHTML = "foo";

// this will succeed because getElement(id) can be called from
  within sandbox a
getElement('b1').innerHTML = "foo";
  



  

  
  

The use of the sandbox tag is purely illustrative.  As Asbjørn Ulsberg
points out in the comments on my entry, the same effect could be
achieved using either a new DOM and/or CSS property. For instance, we
could replace the  with  (or
some variation thereof).

Whatever shape the mechanism ultimately takes, having a way of isolating
scripts within a document would be extremely beneficial.

Thoughts?

- James

[1] http://www.snellspace.com/wp/?p=582

Re: [whatwg] and style=''

[Alexey Feldgendler]

On Fri, 12 Jan 2007 10:03:34 +0100, Henri Sivonen <[EMAIL PROTECTED]> wrote:

Furthermore, I suggest allowing style='' on all elements, because only 
allowing it on  and  would only move WYSIWYG output even more 
to the direction of Karl Dubost's caricature of HTML 6.0.


I second that.

Excluding |style| would lead to hundreds of CSS rules with id-selectors to
emulate that. I can't say it's better.


--
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com

Re: [whatwg] Proposing URI Templates for WebForms 2.0

[Anne van Kesteren]

On Fri, 12 Jan 2007 12:22:25 +0100, Jerome Louvel <[EMAIL PROTECTED]>  
wrote:
That would be so nice to see such a proposal accepted for HTML 5.0, in  
addition to adding support for PUT and DELETE actions.


FYI, Web Forms 2 which in due course will be part of the HTML5 proposal  
already includes support for PUT and DELETE.



--
Anne van Kesteren

Re: [whatwg] contenteditable, and

[Anne van Kesteren]

On Fri, 12 Jan 2007 13:16:04 +0100, Spartanicus  
<[EMAIL PROTECTED]> wrote:

CSS table layouts share all of the many drawbacks of HTML table layouts,
except for the false semantics (one of the least significant issues
IMO).


I agree, CSS needs something like the XUL flexible box model.



Afaics this is off topic for this list, so I'm not going to add further
to this thread spin off.


It prolly is, oh well.


--
Anne van Kesteren

Re: [whatwg] versus |cite|

[Anne van Kesteren]

On Fri, 12 Jan 2007 12:51:05 +0100, Matthew Raymond  
<[EMAIL PROTECTED]> wrote:

   Well, why not overload the |cite| attribute so that it's valid to use
the URL for a  element? Example:

| 
|   How times have changed, said
|   
| http://ln.hixie.ch/?start=1163122250&count=1";>
|   Ian
| 
|   .
| 


How about:

  Blah, said Baz


--
Anne van Kesteren

Re: [whatwg] contenteditable, and

[Spartanicus]

"Alexey Feldgendler" <[EMAIL PROTECTED]> wrote:

>> It often is, sadly. When people really, really want a grid layout model 
>> and try to fake it with positioning or floats, the result tends to be 
>> more brittle and (particularly with positioning) less fluidly scalable 
>> than a  layout (positioning being worse than floats but see 
>> http://dbaron.org/log/2005-12#e20051228a ).
>
>Just a side note: for grid layouts, display: table-* should be used.

CSS table layouts share all of the many drawbacks of HTML table layouts,
except for the false semantics (one of the least significant issues
IMO).

Afaics this is off topic for this list, so I'm not going to add further
to this thread spin off.

-- 
Spartanicus

(email whitelist in use, non list-server mail will not be seen)

Re: [whatwg] contenteditable, and

[Tom Pike]

Alexey Feldgendler wrote:
> On Fri, 12 Jan 2007 09:41:42 +0100, Henri Sivonen <[EMAIL PROTECTED]> wrote:
> 
>>> Is the effort to get people to use CSS instead of  for layout
>>> abad idea?
> 
>> It often is, sadly. When people really, really want a grid layout
>> modeland try to fake it with positioning or floats, the result tends
>> to bemore brittle and (particularly with positioning) less fluidly
>> scalablethan a  layout (positioning being worse than floats but
>> seehttp://dbaron.org/log/2005-12#e20051228a ).
> 
> Just a side note: for grid layouts, display: table-* should be used.

It should, but in the current web authoring world where Internet
Explorer users cannot be ignored, that is not an option.

Best regards
Tom Pike

[whatwg] versus |cite|

[Matthew Raymond]

   There's been some debate about the |cite| attribute versus the 
element. There problem with the attribute is that it doesn't allow for
non-text content and isn't visible on legacy browsers. The problem with
the element is that there are no means of associating it with quotes or
blockquotes.

   Well, why not overload the |cite| attribute so that it's valid to use
the URL for a  element? Example:

| 
|   How times have changed, said
|   
| http://ln.hixie.ch/?start=1163122250&count=1";>
|   Ian
| 
|   .
| 

   You could then have multiple |cite| attributes point to the same
 element, and the  element doesn't necessarily have to be in
close proximity, markupwise, to the referencing  or .

Re: [whatwg] contenteditable, and

[Alexey Feldgendler]

On Fri, 12 Jan 2007 09:41:42 +0100, Henri Sivonen <[EMAIL PROTECTED]> wrote:

Is the effort to get people to use CSS instead of  for layout a 
bad idea?


It often is, sadly. When people really, really want a grid layout model 
and try to fake it with positioning or floats, the result tends to be 
more brittle and (particularly with positioning) less fluidly scalable 
than a  layout (positioning being worse than floats but see 
http://dbaron.org/log/2005-12#e20051228a ).


Just a side note: for grid layouts, display: table-* should be used.


--
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com

Re: [whatwg] Proposing URI Templates for WebForms 2.0

[Jerome Louvel]

Hi Mike,

That would be so nice to see such a proposal accepted for HTML 5.0, in 
addition to adding support for PUT and DELETE actions.


Even though the URI template RFC is not finalized yet, we already have a 
complete support for it, on the server-side, in the Restlet framework. 
We happily use them for our URI-based routing and I think they add a lot 
of expressiveness while keeping a simple syntax. Usage example:

http://www.restlet.org/tutorial#part11

They are also supported in WADL, the RESTful description language, and 
in the OpenSearch specification. Extending their usage to HTML forms 
sounds like a logical and useful step.


Regards,
Jerome Louvel
http://blog.noelios.com


Mike Schinkel wrote :

For those interested, I posted the following on the WHATWG working group
blog proposing URI Templates be used for forms for WebForms 2.0 :

http://blog.whatwg.org/proposing-uri-templates-for-webforms-20

I posted a longer one here:

http://blog.welldesignedurls.org/2007/01/11/proposing-uri-templates-for-webf
orms-2/

[whatwg] and style=''

[Henri Sivonen]

http://whatwg.org/specs/web-apps/current-work/#the-font

The definition of  and style='' seems like a compromise that  
isn't good for either side of the style='' debate. Can it be  
reconsidered, please?


Using  as a block container is less backwards  
compatible than . (Test case for Gecko DOM Inspector:  
http://hsivonen.iki.fi/test/wa10/adhoc/block-in-font.html ) Using  
 for the inline case makes a political point but  
offers no technical benefit over  which the guilty  
tools are already emitting.


Therefore, I suggest allowing style='' on  and . OTOH,  
there's no point in reintroducing  if its HTML 3.2-compatible  
attributes are not conforming.


Furthermore, I suggest allowing style='' on all elements, because  
only allowing it on  and  would only move WYSIWYG output  
even more to the direction of Karl Dubost's caricature of HTML 6.0.


P.S. I don't like style='', either. I just don't think it could be  
eradicated without giving rise to something equally bad or worse.


P.P.S. On IRC, Tantek Çelik suggested reading the discussions that  
the XHTML 2.0 folks had on this topic instead of having the same  
discussions all over again.


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: [whatwg] contenteditable, and

[Henri Sivonen]

On Jan 12, 2007, at 05:25, Matthew Paul Thomas wrote:

Is the effort to get people to use CSS instead of spacer GIFs a bad  
idea?


Is the effort to get people to use .. instead of  or  
 a bad idea?


No. In those cases the alternatives are substantially different  
technically. Not only that, CSS is more powerful and makes things  
substantially easier and more maintainable even for authors who don't  
care about the philosophy behind the advocacy.


With  vs. , the argument is over which identifier (opaque  
string that can be compared for equality) is used as an element name.  
There's no substantial technical difference.


Is the effort to get people to use CSS instead of  for  
layout a bad idea?


It often is, sadly. When people really, really want a grid layout  
model and try to fake it with positioning or floats, the result tends  
to be more brittle and (particularly with positioning) less fluidly  
scalable than a  layout (positioning being worse than floats  
but see http://dbaron.org/log/2005-12#e20051228a ).


There were, I'm sure, many more occurrences of those problems than  
there were improper uses of  and . And the efforts to  
replace them are much older than the effort to get people who don't  
think about semantics to use  and , which has hardly even  
started yet.


Considering the IIIR draft I referenced and the Siegel article that  
Anne mentioned, the  vs.  discussion seems to actually be  
older. But regardless of the exact age of the debate, my secondary  
point was that the expected payoff is so light that I don't think  
spending another 14 years on this is worthwhile. My opinion would be  
different if the expected payoff was insanely great.


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/