Hacker News Reader

Comment by chrismorgan | Hacker News Reader

The MDN documentation of strict mode covers approximately the same scope as this article, and quite a bit more, in a way that I find much easier to follow (it’s reference, whereas this article is narrative):

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

View on HN

> In strict mode it's no longer possible to "walk" the JavaScript stack. Many implementations used to implement some extension features that make it possible to detect the upstream caller of a function. When a function fun is in the middle of being called, fun.caller is the function that most recently called fun, and fun.arguments is the arguments for that invocation of fun. Both extensions are problematic for "secure" JavaScript because they allow "secured" code to access "privileged" functions and their (potentially unsecured) arguments.

This affects V8's stack frames as well [1]. Is this related to the principle of least privilege? Can someone explain what specific vulnerability could result from allowing "secured code to access privileged functions and their (potentially unsecured) arguments" in Javascript?

https://v8.dev/docs/stack-trace-api#:~:text=strict%20mode

your login function receives a username and a password from the form, checks them with a network call, and then sends an "user logged" event by calling a function of a third party library like Google Analytics or Sentry. Now it would be quite dangerous if the code in that function could access the parameters of the original caller which include sensitive data. This gets worse as you consider the entire supply chain of dependencies.

Does this really make a practical difference? In your example malicious dependency code could just add a keydown listener on the document to lift a password.

I'm surprised by this:

> The "use strict" directive can only be applied to the body of functions with simple parameters. Using "use strict" in functions with rest, default, or destructured parameters is a syntax error.

    function sum(a = 1, b = 2) {
      // SyntaxError: "use strict" not allowed in function with default parameter
      "use strict";
      return a + b;
    }

Not that I would see myself doing this, I would put strict mode in a function containing all the code of the file that does not take any argument (or maybe dependencies), but why would "use strict"; be forbidden here?

It’s about strictness scoping. https://old.reddit.com/r/webdev/comments/v877zq/why_cant_you... gives a decent explanation, and https://github.com/rwaldron/tc39-notes/blob/d0c651b358b361b0... is good and technical.

Thanks, very interesting.

A bit hard to understand this transcript without context but it really reads like SpiderMonkey and Chakra were actually able to parse this. V8 people didn't like it, the others were like "ok, whatever" and they ended up disallowing it in the spec.

I guess it allows simplifications in the parsers by not having a "strict or sloppy, don't know" mode for default parameter values, while not blocking actual use cases.

That seems weird to me. Does strict mode affect parsing?

I thought that parsing completed before execution, so why couldn’t the parser generate the same AST for these two functions?

(a) => a === undefined ? 1 : a

(a = 1) => a

> Does strict mode affect parsing?

Actually, yes. default parameter values could contain things that are allowed in sloppy mode and are syntax errors in strict mode. For instance, a leading zero in numbers without explicitly specifying the base, duplicate property names, the with statement, new reserved words and using delete on a variable name.

You need to disallow those in the parameter values in strict mode, but you only know this after encountering the "use strict" marking in the function body if you were not already in strict mode. You can make a parser able to do this, but it is more complex. I guess they decided that this complexity is not worth it.

Reply on news.ycombinator.com