Avoid ambiguous "extract a source map comment" algorithms

[nicolo-ribaudo]

During the October 2024 TC39 plenary meeting, it was raised that providing multiple methods of extracting a source map comment that yield different results can cause a security/privacy problem.

This is because on some platforms it can be used as a way to track whether the user is trying to debug the code, or to grab the user's IP thanks to the devtool trying to fetch the source map fro a remote server. Users on those platforms that want to prevent this from happening can pre-scan their code to know if it contains a source map comment or not. However, having two methods of doing so that yield different results can cause these tools to miss some of the comments.

We still got approval from TC39 for submitting our final draft to Ecma, but it was conditional on us:

• adding an explicit warning about this case in the specification (done in Add security warning for ambiguous source maps #137)
• working to resolve the problem in the next edition

This issue is to track the solution. I propose that there can be two "success outcomes"

1. the two algorithms are refined so that they always lead to the same result
2. the regexp-based algorithm is refined so that it can find a subset of the comments found by the parsing-based algorithm, rather than being two sets that simply intersect.

From the discussion during plenary, we concluded that one of the first steps should be to early-exit from the regexp-based algorithm whenever there is a comment that contains one of `, ", ', */. This would avoid ambiguity in cases like

let a = `
//#sourceMapURL=...
//`

This solution is probably not complete though, and this issue is to keep track of it.

[szuend]

With debugId picking up steam, we should address this sooner than later.

I have a slight preference for 2) and would go about it this way:

• We recommend in the spec that tooling puts all //# magic comments into a block at the end of a script. Note that this is most likely a file, but can also be a string passed to eval or the function constructor. In ECMA speak we can say only white space and line terminator tokens should follow the magic comments, no other comments or JS syntax.
• The regex approach searches lines backwards looking for //# but stops if it finds anything else.

I think this would be sufficient to implement 2). Basically the regex approach would never find a "false positive" and the regex approach would be a subset of the parsing approach.

If tooling follows the spec recommendation, a client can use the regex approach, otherwise a full parse may be needed. But it will never be the case that the regex finds a magic comment that is not actually valid (e.g. because it was in a template literal).