Killing `Promise.fulfill`

Tab Atkins Jr. jackalmage at gmail.com
Wed Aug 21 22:22:32 PDT 2013


On Wed, Aug 21, 2013 at 5:55 PM, Mark S. Miller <erights at google.com> wrote:
> On Wed, Aug 21, 2013 at 5:33 PM, Tab Atkins Jr. <jackalmage at gmail.com>
> wrote:
>>
>> On Wed, Aug 21, 2013 at 5:12 PM, Mark S. Miller <erights at google.com>
>> wrote:
>>> On Wed, Aug 21, 2013 at 3:44 PM, Tab Atkins Jr. <jackalmage at gmail.com>
>>> wrote:
>>>> But I like just Promise(), sans "new".
>>>
>>> Good. I like it too, and Allen's latest draft class semantics enables
>>> the
>>> definition of classes that can do this reliably. But is there any way to
>>> reliably polyfill this in ES5? It's not clear. For the std promise API,
>>> given the urgency with which people want to use it *now*, I think this
>>> polyfillability is important.
>>
>> Yes, why wouldn't it be?  The test for promise-ness can be done today,
>> without special browser privilege, and distinguishing between
>> `Promise(foo)` and `new Promise(foo)` is a trivial matter of testing
>> the type of `this` inside the function.  (If it's instanceof Promise,
>> you were called with new.  Otherwise, you weren't.  This isn't 100%,
>> as people can fool you with Promise.call(), but that's not something
>> you need to actually worry about, I think.)
>
>
> This is an example of what I am worried about. Another is
>
>     Object.create(p, {value: Promise}).Promise(....)
>
> where p is a promise.

I'm not quite sure what this is supposed to do, because it's invalid
Object.create.  (Or rather, it creates a property named "value" with
default descriptors, which I'm sure isn't intended.)

> Perhaps it would help if, when we start to think "people can fool you
> with..." it would help to substitute "an attacker can fool you with...".

What exactly is the attack scenario being envisioned here, though?
Okay, you can call a function and supply your own `this` value.  And?
You can always do this, before or after construction.  I don't think
this lets you fool anything, because you, the attacker, have to run
your own code to make it happen.  You can't somehow trick the defender
into creating a tricky not-quite-authentic Promise, unless you've
tricked them into using eval() or something.  If the attacker is
getting to run code of its choosing, you've already lost.

Am I missing some obvious attack?

~TJ


More information about the es-discuss mailing list