Re: All ECMAScript attributes should be non-configurable

On Tue, Oct 11, 2011 at 12:26 PM, David Bruant <david.bruant@labri.fr>wrote:

> Le 30/09/2011 20:33, Erik Arvidsson a écrit :
>
>> Configurability is part of JavaScript and the web. If you don't want this
>> I suggest using (...) Caja (...)
>>
> This particular argument stayed in my mind for quite a long time.
> Currently, what SES does is, based on a "configurable environment", is to
> turn most things non-configurable (with initSES.js).
>
>
>  To allow subclassing and allow using monkey patching to fix bugs in
>> implementations.
>>
> But SES does not prevent monkey-patching to fix implementations. It would
> be still possible to:
> 1) load fixes
> 2) load initSES.js
>

Note that this is effectively how initSES.js itself works. Were current ES5
implementations correct, most of <
http://code.google.com/p/es-lab/source/browse/trunk/src/ses/repairES5.js>
would not be necessary. Although repairES5.js is bundled into initSES.js (by
concatenation), the best way to think of it is as a repair phase prior to
normal SES initialization.


>
> I think that none of us want configurability.


Such statements are too strong and beg for contradiction. I'm rather
confident some of the people on this list, indeed on this thread, do indeed
want configurability. Let's shift the discussion to your real point here,
which is to identify what configurability is and isn't good for, and when
those phases of computation occur.



> What we want is "configurability once", because it offers the potential to
> fix implementation bugs.


This use of mostly-pervasive initial configurability does indeed help such
initialization-time repairs. In fact, if everything non-standard were
configurable, as recommended at <
http://wiki.ecmascript.org/doku.php?id=conventions:make_non-standard_properties_configurable>,
much less of repairES5.js would be necessary, as the remainder of SES
initialization could then remove those non-standard elements that are absent
from our whitelist <
http://code.google.com/p/es-lab/source/browse/trunk/src/ses/whitelist.js#110
>.





> But when bugs are fixed, I'm not really sure we need configurability
> anymore. Reading a program where things are redefined all the time would be
> a nightmare. Moreover, it leaves security holes.
>

Agreed. I remember reading a paper about an empirical investigation of
monkey patching across a number of Python programs. Their conclusion is
that, for the majority of Python programs, such monkey patching happens only
during a setup phase and no longer happens once the post-setup logic of the
program starts running. I strongly suspect the same is true of actual
JavaScript programs.

Does anyone know the paper I'm referring to?



> But anyway, "configurability once" means configurability, so I join the
> side of attributes being configurable in the end. Even more since I
> discovered that WebIDL does type enforcement on the getter and setters which
> i'm sure at some point or another one browser will get wrong.
>
> David
>
>


-- 
    Cheers,
    --MarkM