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 <[email protected]> wrote: > On Mon, Sep 8, 2014 at 8:45 AM, Mark S. Miller <[email protected]> wrote: > >> On Mon, Sep 8, 2014 at 8:35 AM, Andrea Giammarchi < >> [email protected]> 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 <[email protected]> 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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
