"use strict" VS setTimeout

Mark S. Miller erights at google.com
Mon Sep 8 09:53:06 PDT 2014


No, this isn't an information disclosure or any other security issue. It is
"only" a modularity issue.



On Mon, Sep 8, 2014 at 9:49 AM, Jasvir Nagra <jasvir at gmail.com> wrote:

> On Mon, Sep 8, 2014 at 8:45 AM, Mark S. Miller <erights at google.com> wrote:
>
>> On Mon, Sep 8, 2014 at 8:35 AM, Andrea Giammarchi <
>> andrea.giammarchi at gmail.com> wrote:
>>
>>> Boris and Mark, I was talking about engines, already inevitably able to
>>> distinguish strict from sloppy,
>>>
>>
>> We have made great progress in JS better able to implement/emulate the
>> APIs we expect browsers to provide. One of the design constraints on WebIDL
>> is "can it be implemented in JS, perhaps by a proxy?" Exotic object
>> behavior that cannot be implemented even by proxies is held with great
>> suspicion, though some of this remains.
>>
>> So I would generally avoid having the engine observably make a test that
>> JS can't do. Again, one of these remains as well: a magical sloppy.caller
>> can't reveal a non-sloppy caller.
>>
>>
>>
>>> but in any case in JS is straight forward to know if you are under
>>> strict directive or not.
>>>
>>> ```js
>>> var isStrictAvailable = (function(){'use strict';return !this}());
>>> var isThisStrict = isStrictAvailable && (function(){return !this}());
>>> ```
>>>
>>
>> That test only one's own lexical scope. It does not test a function value
>> given to you across an API boundary.
>>
>
> Agreed. Can you say why this is a desirable property?  I ask mostly to
> understand what the consequences are of some side-channel leak which allows
> a caller to decide the strictness of a particular function (say via
> toSource fr'instance) that it is calling - are there security consequences?
>
>
>>
>>
>>> Btw, I laughed hard than I've should have on this:
>>>
>>> > "Now it just happens that Blink, IE and WebKit (or at least Safari)
>>> have buggy requestAnimationFrame implementations."
>>>
>>> Best Regards
>>>
>>
>> ;)
>>
>> Please do file bugs on these and post the links. Thanks.
>>
>>
>>
>>
>>>
>>> On Mon, Sep 8, 2014 at 3:41 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>>>
>>>> On 9/8/14, 10:25 AM, Andrea Giammarchi wrote:
>>>>
>>>>> Apologies, now I see what you meant and I think option 2 would be
>>>>> probably ideal. ES5+ engines can easily retrieve "strictness"
>>>>>
>>>>
>>>> In script?  How?  (Again, clearly in the VM implementation I can do
>>>> this.)
>>>>
>>>>  Going through the list of all properties it looks like at the end of
>>>>> the
>>>>> day only things to improve/change are:
>>>>>
>>>>> requestAnimationFrame
>>>>> setInterval
>>>>> setTimeout
>>>>>
>>>>
>>>> requestAnimationFrame doesn't have this problem.  See <
>>>> http://www.w3.org/TR/animation-timing/#dfn-invoke-callbacks-algorithm>
>>>> and the text about "callback this value" at <http://heycam.github.io/
>>>> webidl/#es-invoking-callback-functions>: it defaults to undefined
>>>> unless specified otherwise, and the requestAnimationFrame spec doesn't
>>>> specify otherwise.  You can see a testcase for this behavior at
>>>> http://jsfiddle.net/xpwr1ozx/
>>>>
>>>> Now it just happens that Blink, IE and WebKit (or at least Safari) have
>>>> buggy requestAnimationFrame implementations.  Specifically, Blink and IE
>>>> pass a Window as "this" (I didn't check which Window) and WebKit passes the
>>>> function itself as "this" as far as I can tell(!).  Firefox follows the
>>>> spec and passes undefined.  Please feel free to file bugs on the other
>>>> implementations!
>>>>
>>>>  Although I have honestly no idea how to explain via W3C pages that JS
>>>>> might be strict or not ... seems to me that "_strictness_" should be
>>>>> outside the DOM knowledge so .... probably this should be part of ES
>>>>> specification.
>>>>>
>>>>
>>>> The normal way this would be done is that ES would expose an abstract
>>>> operation that returns true or false for strictness of a function and then
>>>> DOM would invoke that abstract operation.  Though obviously the DOM could
>>>> just directly check the [[Strict]] internal slot too if there is no
>>>> abstract operation defined for it.
>>>>
>>>> -Boris
>>>>
>>>
>>>
>>
>>
>> --
>>     Cheers,
>>     --MarkM
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140908/50e53058/attachment.html>


More information about the es-discuss mailing list