Dynamically changing of loader global

Mark S. Miller erights at google.com
Thu Dec 27 11:04:30 PST 2012

On Wed, Dec 26, 2012 at 3:03 PM, David Bruant <bruant.d at gmail.com> wrote:
> Le 26/12/2012 23:14, David Herman a écrit :
>> On Dec 24, 2012, at 2:34 PM, David Bruant <bruant.d at gmail.com> wrote:
>>> I've reading the loader API [1] and I was wondering if it was possible to
>>> dynamically change the global. I think it is by doing the following, but
>>> tell me if I'm wrong:
>> That wasn't the intention. It probably wasn't written out since the full
>> semantics isn't spelled out yet (though Sam and I have been making good
>> progress working through the details of the semantics), but the idea was
>> that the properties of the options object are read in up-front and stored
>> internally. The getter always returns that internally closed-over value that
>> was obtained when the loader was first created.
> Ok, thanks for the clarification. The strawman as it was didn't explain the
> full semantics hence my question.
>>> In other words, in the global in the loader the initial or the dynamic
>>> value of the "global" option?
>> The initial value. We can look into what it would mean to make it
>> modifiable, but we'd probably not make that the API; we'd probably just have
>> a setter.
> Good point.
> [Adding MarkM into the mix for this part]
> I wish to point out a potential security/convenience issue regarding
> inherited getter/setters. My point is broader than the 'global' loader
> situation (it includes everything covered by WebIDL for instance), but let's
> assume a 'global' setter is added to Loader.prototype and I'll draw the
> general conclusion from this example.
> If I want to share a single loader instance to someone else, but not provide
> access to the loader global, I have to delete Loader.prototype.global
> (otherwise, someone can extract the getter and use the reference to the
> loader instance to retrieve the global)
> The problem with deleting Loader.prototype.global is that it's deleted for
> every single instance which in turns make the code harder to write (because,
> defensively, one needs to extract the getter/setter pair an then use that
> instead of the more convenient "myLoader.global" syntax). The opposite way,
> if freezing Loader.prototype, it becomes *impossible* to revoke the
> capability to introspect instances using the inherited getters/setters.
> In essence, an inherited accessor means that the choice allowing access to a
> given property isn't a per-instance choice anymore. It's a per-"class"
> choice (keep it or remove it for every instance) which is probably fine for
> most situations, but certainly too coarse for some others.

This is a very good point. Is there any reason other than legacy
compat why WebIDL specifies inherited accessors rather than own

> Since the amount of storage is equivalent anyway (you need some sort of
> private property to associate the global to the loader instance), I would
> suggest to go to an own "global" data property for loaders... and I guess to
> stay away from inherited accessors when describing a per-instance property
> for the reasons I described.
> David


More information about the es-discuss mailing list