Private Slots

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Jan 16 17:07:42 PST 2013


On Jan 16, 2013, at 4:34 PM, Brandon Benvie wrote:

> That's true, restricting their ability to be modified quells that concern. The only other concern would be to make sure there isn't any extension points left open in the default builtins. For example, if Object.@@create wasn't specified by default (and the algorithm still ended up deferring to it, I'm not sure if it does or not for "plain" objects) then a malicious late-comer could insert their own @@create here and tap into every object literal and tag them or some such thing. As long as all the builtins have this door closed then it's not an issue.

Or any intentionally open doors are closable by subsystems such as SES.

I believe that  all the language level semantics that invoke extension points have fallback that are used if no extension point property is found.  Certainly that is my intent. If you find any that aren't that way, let me know.

Allen



> 
> 
> On Wed, Jan 16, 2013 at 7:26 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> 
> On Jan 16, 2013, at 4:03 PM, Brandon Benvie wrote:
> 
>> That's exactly how I was thinking of it. @@hasInstance and @@create live on Function.prototype so the only protection a sandbox has from letting any and all comers muck with them is in them not being reflected.
>> 
>> Overriding Function.prototype.@@create (and the custom ones e.g. Boolean.@@create) would allow you to touch every single object that is created before any other code as access to it. Overriding Function.prototype.@@hasInstance would give you access to every object used on the LHS of instanceof and every function on the RHS of instanceof (`this` inside @@hasInstance). These seem like things that SES would absolutely want access prevented to. The default functionality itself may be mundane, but the exposure of the operands is itself the power those functions have.
> 
> For this reason, I've been specifying all of the @@create methods for standard built-ins as non-writable, non-configurable, just like the "prototype" property has always been specified. The rationale, is that just like "prototype" the integrity of @@create is essential to any function that needs to define it.
> 
> In this light, it may also make sense to make Function.prototype.@@ and Function.prototype.@@hasInstance non-writable, non-configurable.  Regardless of the defaults, SES could presumably defend itself in the same same way.
> 
> I don't see any real need to restrict access to all predefined @@create methods.  If you invoke it directly (or copy it to another object) about the worse you can do is make an initialized Boolean (in this example) instance which if throw if any of the Boolean methods are applied to it.  If you use it to create such an instance and then manually apply the Boolean constructor to initialize it you getting that is basically equivalent to (new Boolean).__proto__ = whatever.  It isn't clear that the object you would get is dangerous  or anymore so that you would get if you evaluated: new (class extends Boolean)
> 
> Allen
> 
> 
> 
> 
> 
>> 
>> 
>> On Wed, Jan 16, 2013 at 6:53 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> 
>> On Jan 16, 2013, at 3:20 PM, Brandon Benvie wrote:
>> 
>> > It's worth noting that private Symbols *are* used by the ES6 spec to solve a number of other problems currently. They are used to provide easy to use hooks for overriding builtin functionality: @@hasInstance, @@create, @@toStringTag, @@iterator, and @@ToPrimitive. Some of these (@@toStringTag, @@iterator) likely make sense as unique symbols, but the others protect access to powerful capabilities that should likely be protected. Without private symbols, it would be difficult to expose these APIs in the easily hookable manner they are provided now. Using prototypal inheritance along with private symbols to protect access is exactly how these hooks are made easy to use.
>> >
>> 
>> 
>> Let's refer to all of these built-in @@symbols as language extensions points.
>> 
>> Upon my first reading of the above, I wasn't sure I agreed with Brandon.  After all, language extension point symbols all need to be publicly available (presumably via module imports)  if certain forms of extended abstractions are going to be defined by ES code.  From that perspective regular non-private Symbols should be fine for representing language extension points. (BTW, note I avoid saying "unique symbol" as that isn't current part of the ES6 vocabulary.  We have Symbols, some of which are private.  But all of them (including private Symbols) are unique values.)
>> 
>> However, here is why it might make sense to make some of language extension points private:  If you are creating a sandboxed environment where you would like to limit the availability of some of the language extension points and hence the ability to define new abstractions with the extended functionality.   A sandbox's module loader can presumably restrict access to the modules that would export some or all of the language extension points.  However, if the language extension points are represented using regular, non-private Symbols then it still might be possible to discover the language extension points via reflection and then use them to circumvent the sandbox restrictions.  If they are represented as private Symbols this would not be possible.
>> 
>> So that is a theoretical reason why  we might want language extension points to be private Symbols. But, in practice, it isn't clear to me why you would want to sandbox any of the currently identified language extension points in this manner.  They all have utility in defining application level abstractions.  That's why they're there. If you take them away you have a less powerful language.  It also isn't clear what potential hard is exposed by them.
>> 
>> Does anyone have particular language extension points that they think need to be restricted in this manner?
>> 
>> Allen
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130116/753866df/attachment.html>


More information about the es-discuss mailing list