Dynamically changing of loader global
dherman at mozilla.com
Fri Dec 28 11:47:24 PST 2012
On Dec 26, 2012, at 3:03 PM, David Bruant <bruant.d at gmail.com> wrote:
>> 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)
Heh, good luck with that. A loader is a very high privilege object. Just removing the getter is not going to help you, when you can easily write
For security, it's much better to treat a loader is a super-powerful object, and completely deny access to it to untrusted code. That's one of the reasons why there's no f.getLoader() or getCurrentLoader() API. The System object is a loader, but when you create a sandbox, you would typically censor or attenuate its power.
More information about the es-discuss