5 ms·

How to Control JavaScript's Strict Mode

chrismorgan 3y ago
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/Reference/Strict_mode https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- jraph 3y ago
  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?
  - chrismorgan 3y ago
    It’s about strictness scoping. https://old.reddit.com/r/webdev/comments/v877zq/why_cant_you_use_strict_in_function_with/ibp4lpd/ https://old.reddit.com/r/webdev/comments/v877zq/why_cant_you... gives a decent explanation, and https://github.com/rwaldron/tc39-notes/blob/d0c651b358b361b0855cfe7af9ba0b76cab73949/es7/2015-07/july-29.md#611-the-scope-of-use-strict-with-respect-to-destructuring-in-parameter-lists https://github.com/rwaldron/tc39-notes/blob/d0c651b358b361b0... is good and technical.
    - lakpan 3y ago
      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
      - jraph 3y ago
        > 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.
    - jraph 3y ago
      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.
- aragonite 3y ago
  > 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 https://v8.dev/docs/stack-trace-api#:~:text=strict%20mode
  - agos 3y ago
    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.
    - johncolanduoni 3y ago
      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.
gorkish 3y ago
Nobody really likes to talk about that time Perl and Javascript got drunk and hooked up.
- jraph 3y ago
  It happened at least twice. The first time, it gave jQuery, which notably inherited the $ and the terser syntax from perl. The second time, indeed, JS found Perl's "use strict" quite cute.
  - gorkish 3y ago
    I disagree that jquery adopted anything from perl. jQuery's $ is not a sigil.
  - lifthrasiir 3y ago
    It was originally `use strict` without any quotes, along with other possible `use ...` statements in the scrapped ES4 working draft. It seems that the exact person suggested this particular syntax was David-Sarah Hopwood [1], which suggestion was quickly adopted to the next draft of what eventually became ES5. [1] https://web.archive.org/web/20150525070848/https://mail.mozilla.org/pipermail/es5-discuss/2009-May/002591.html https://web.archive.org/web/20150525070848/https://mail.mozi...
    - jraph 3y ago
      It was good that it's a string literal, so it did not make the file incompatible with parsers that didn't support strict mode. You'd have to make sure your code behaved correctly both in sloppy mode and in strict mode. Probably irrelevant today.
      - lifthrasiir 3y ago
        That indeed was a big concern, and the initial proposal assumed that it at least has to survive the lexical analysis. At some point there were two syntaxes, `use strict` (optionally followed by a comma and other tokens) or `if (false) use(strict)` at one's choice. In comparison Hopwood's proposal was not even an actual proposal but quickly adopted due to its simplicity and robustness. The only complaint was a space in the literal.

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/Reference/Strict_mode https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

jraph 3y ago
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?
- chrismorgan 3y ago
  It’s about strictness scoping. https://old.reddit.com/r/webdev/comments/v877zq/why_cant_you_use_strict_in_function_with/ibp4lpd/ https://old.reddit.com/r/webdev/comments/v877zq/why_cant_you... gives a decent explanation, and https://github.com/rwaldron/tc39-notes/blob/d0c651b358b361b0855cfe7af9ba0b76cab73949/es7/2015-07/july-29.md#611-the-scope-of-use-strict-with-respect-to-destructuring-in-parameter-lists https://github.com/rwaldron/tc39-notes/blob/d0c651b358b361b0... is good and technical.
  - lakpan 3y ago
    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
    - jraph 3y ago
      > 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.
  - jraph 3y ago
    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.
aragonite 3y ago
> 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 https://v8.dev/docs/stack-trace-api#:~:text=strict%20mode
- agos 3y ago
  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.
  - johncolanduoni 3y ago
    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.

gorkish 3y ago

Nobody really likes to talk about that time Perl and Javascript got drunk and hooked up.

jraph 3y ago
It happened at least twice. The first time, it gave jQuery, which notably inherited the $ and the terser syntax from perl. The second time, indeed, JS found Perl's "use strict" quite cute.
- gorkish 3y ago
  I disagree that jquery adopted anything from perl. jQuery's $ is not a sigil.
- lifthrasiir 3y ago
  It was originally `use strict` without any quotes, along with other possible `use ...` statements in the scrapped ES4 working draft. It seems that the exact person suggested this particular syntax was David-Sarah Hopwood [1], which suggestion was quickly adopted to the next draft of what eventually became ES5. [1] https://web.archive.org/web/20150525070848/https://mail.mozilla.org/pipermail/es5-discuss/2009-May/002591.html https://web.archive.org/web/20150525070848/https://mail.mozi...
  - jraph 3y ago
    It was good that it's a string literal, so it did not make the file incompatible with parsers that didn't support strict mode. You'd have to make sure your code behaved correctly both in sloppy mode and in strict mode. Probably irrelevant today.
    - lifthrasiir 3y ago
      That indeed was a big concern, and the initial proposal assumed that it at least has to survive the lexical analysis. At some point there were two syntaxes, `use strict` (optionally followed by a comma and other tokens) or `if (false) use(strict)` at one's choice. In comparison Hopwood's proposal was not even an actual proposal but quickly adopted due to its simplicity and robustness. The only complaint was a space in the literal.