On Fri, Feb 3, 2012 at 1:08 PM, David Bruant <bruan...@gmail.com> wrote:
> Le 03/02/2012 17:54, John J Barton a écrit :
>> iframes seem to be effective for the cases David outlined.
> I can come up with more use cases ;-) Regardless of use cases iframes
> will always have an overhead against just loading some code with
> attenuated authority.
To support the attenuation of authority you have to create a container
(authority boundary) and you have to attenuate the API you give the
loaded code. These activities are not free.
For the container, the important question (which I do not know the
answer to): can the container be isolated from the rest of the Web app
running in the window? Is there any impact on the rest of the
application from the choice to allow untrusted code to be loaded into
it?
To ask the same question in a more personal way: I've read code with
PropertyDescriptor/freeze() etc. Will I have to write that kind of
code?
>
> For instance, if we want to create a game where participants submit some
> code to compete with each other. When loading the participants code,
> iframes can have a performance issue and asynchronous communication as
> done in the browser (with HTML5 cloning algorithm as the "richest form
> of sharing") may be very limitating.
Both technologies require the attenuated API. Since this API is the
security hole, it will require a great deal of attention. I think in
practical cases this effort will dwarf other issues.
> However, being able to load the
> code in the same frame ("vat" as said in the concurrency strawman) would
> certainly yield better performance.
I thought this way as well only a few months ago. But the Chrome
multi-process architecture convinced me to reconsider. Integration
calls, the kind of API a security barrier can support, are just not
performance sensitive by design. And JSON messaging performs very
well.
> The only remaining threat would be DoS (both in memory and CPU time), an
> alternative allowing performance, rich interaction and preventing by
> design DoS is what is presented on the concurrency strawman. But we're
> not there and iframes are far from providing the same level of control.
Will the security solution prevent the untrusted code from
manipulating the DOM tree outside of a specific element?
(I appreciate your answers even if my questions sound pointed)
jjb
>
> David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
