How to ensure that your script runs first in a webpage

David Bruant bruant.d at gmail.com
Fri Feb 3 13:08:10 PST 2012


Le 03/02/2012 17:54, John J Barton a écrit :
> On Fri, Feb 3, 2012 at 8:12 AM, Mark S. Miller <erights at google.com> wrote:
>> On Fri, Feb 3, 2012 at 7:36 AM, John J Barton <johnjbarton at johnjbarton.com>
>> wrote:
>> [...]
>>> I'm not saying we can't do better, I am claiming that the impact of
>>> adding security features to the programming language is not (yet?)
>>> justified.
>>
>> I must have missed something. What language change suggestions are you
>> reacting to?
>>
>> ES5 already supports SES and ES6 will as well, probably somewhat better. The
>> "costs" were largely non-controversial and are behind us in any case.
>>
> Well David seems to be building up to something, so I wanted to get
> some controversy out in front.
For now, I wasn't suggesting any change in the language. It's just that
on es-dicuss, I had said a couple of times that JavaScript security
relied on whoever runs first and that I had found a way to guarantee it
with CSP that I wanted to share.
Discussion led to finding that in web browsers, running first, may not
be enough sometimes, but the issue is solved with CSP anyway. Again, no
need to ad something to ECMAScript. Actually my point was that in
CSP-enabled browser, there is no need for anything else.


>>>  There are better solutions based on iframes that do not
>>> require such large investments. In particular, systems like q-comm
>>> allow controlled API access between isolated JS environments.
>>
>> I am (as you know) a big fan of q-comm and such Q libraries, as well as the
>> communicating event loop model where iframe/worker like units only interact
>> by asynchronous messages. These certainly have their place, and that place
>> is huge.
>>
>> However, I *strongly* disagree that iframes are a better security mechanism
>> than the language-based mechanisms provided by SES. iframes are an unholy
>> mess, and *by design and specification* (both old and HTML5) cannot support
>> confinement. The best way to leverage the security that Q-like libraries can
>> provide is to see them as extending SES out onto the network.
> 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.

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. However, being able to load the
code in the same frame ("vat" as said in the concurrency strawman) would
certainly yield better performance.
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.

David


More information about the es-discuss mailing list