@@toStringTag spoofing for null and undefined

[Rick Waldron]

On Wed Jan 21 2015 at 4:11:04 PM Mark Miller <erights at gmail.com> wrote:

> On Wed, Jan 21, 2015 at 1:05 PM, Jordan Harband <ljharb at gmail.com> wrote:
>
>> > Just checking: Are we talking about adding it to each instance as a
>> non-configurable non-writable data property?
>>
>> Mark: No, not to each instance, but to Array.prototype,
>> Function.prototype, etc. If someone wants to override it on a specific
>> instance that's fine, and I don't think it's important to protect against
>> that.
>>
>
> In that case, I find this unacceptable, as it breaks the branding
> invariant that some legacy ES5 code depends on.
>

I just want to clarify, this is what you're referring to, correct?

> Object.getOwnPropertyDescriptor(Object.prototype, Symbol.toStringTag)
undefined

> Object.defineProperty(Object.prototype, Symbol.toStringTag, {
  value: "Whatever I want it to be"
});

> Object.prototype.toString.call(function() {})
"[object Whatever I want it to be]"
> Object.prototype.toString.call("A string")
"[object Whatever I want it to be]"
> Object.prototype.toString.call({})
"[object Whatever I want it to be]"
> Object.prototype.toString.call(1)
"[object Whatever I want it to be]"



This wouldn't be possible if all built-in prototypes had an explicitly
defined @@toStringTag that was  { [[Enumerable]]: false, [[Writable]]:
false, [[Configurable]]: false } (which is what I believe Jordan is
presenting)

Rick


>
>
>
>>
>> > I would not be happy with making the built-ins nonconfigurable. Just
>> like Function.prototype.length, it should be unlocked.
>>
>> Domenic: Changing Function#length makes sense to me - the Function#bind
>> shim does nasty things to ensure "length" is set properly, for example, and
>> it would be much easier if the length was editable. Do you have a use case
>> in mind where you'd want to change a language builtins' @@toStringTag value?
>>
>> We can always unlock it later, but it seems like we can't lock it down
>> once it's unlocked, so without any valid use cases, it seems like a risky
>> move to unlock it now.
>>
>> On Wed, Jan 21, 2015 at 1:00 PM, Mark S. Miller <erights at google.com>
>> wrote:
>>
>>> On Wed, Jan 21, 2015 at 12:57 PM, Mark Miller <erights at gmail.com> wrote:
>>> [...]
>>>
>>>> Is there anyone who wouldn't be happy with "all
>>>>> builtins' @@toStringTag is not configurable" and "drop the ~ prefixing
>>>>> completely"?
>>>>>
>>>>
>>>> Just checking: Are we talking about adding it to each instance as
>>>> unconfigurable?
>>>>
>>>
>>> Sorry, incomplete question. Meant:
>>>
>>> Just checking: Are we talking about adding it to each instance as a
>>> non-configurable non-writable data property?
>>>
>>>
>>> --
>>>     Cheers,
>>>     --MarkM
>>>
>>
>>
>
>
> --
>   Cheers,
>   --MarkM
>  _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150121/b751b95e/attachment-0001.html>