1628853 - Expose an option to disable //#sourceURL= pragma handling

Status: RESOLVED FIXED

(Core :: JavaScript Engine, enhancement, P2)

Description

[Sarah Bird]

Attachment: Network stack trace from akam get request

Background: while investigating tracking scripts, I discovered that //# sourceURL can be used to alter the script url shown in the JS stack trace, which is an issue for measurement - https://github.com/mozilla/OpenWPM/issues/597. I have now discovered, this also affects network stack trace.

Steps to reproduce:

1. go to www.mattressfirm.com (this problem isn't specific to mattressfirm.com it is just a site where you can see this behavior - we could make a test / demo site if needed)
2. observe in devtools network tab a script is loaded from forter.com (something like https://15912b5d40f0.cdn4.forter.com/sn/15912b5d40f0/script.js)
3. filter network tab with string "akam" you'll observe a network request, something like https://media-akam.licdn.com/cdo/cdxs/r20.gif?rnd=1586462843566
4. click on request and then stack trace and see that the call is attributed to (program):2

Expected result: call is attributed to https://15912b5d40f0.cdn4.forter.com/sn/15912b5d40f0/script.js

This result holds after I change devtools.source-map.client-service.enabled and devtools.debugger.source-maps-enabled to false.

If you view the source of the forter script, you can see the end of it is //# sourceURL=(program):2

If you want additional evidence that the request to media-akam came from the forter script, in this gist I have deobfuscated the script and you can see the forter script assembling the call to the media-akam domain here.

Being able to attribute networks and interconnections of domains, scripts, and requests is important for tracking research. Although we probably don't want to change the sourceURL behavior by default, it would be good to have a pref with which to alter it.

(apologies in advance if this pref exists and I just haven't found it yet).

I found these other bugs that may be relevant: https://bugzilla.mozilla.org/show_bug.cgi?id=1622158 and https://bugzilla.mozilla.org/show_bug.cgi?id=1224078

Comment 1

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Thanks for the report!

I can't see any requests when filtering the Network panel using akam so, it would be great if you could provide simple & specific test page.

Honza

Comment 2

[Sarah Bird]

Sorry the test case didn't work for you. Could be lots of reasons. I made a test page: http://www.sarahbird.org/tests/sourceURL/

Comment 3

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Thanks for the test case!

If I understand this report correctly, you are looking for a pref that we could use to disable support for # sourceURL directive entirely, correct?

Honza

Comment 4

[Sarah Bird]

are looking for a pref that we could use to disable support for # sourceURL directive entirely?

That sounds right. But I don’t have any particular solution in mind. My need is to be able to attribute activity* back to its source and not have the originator be able to mask themselves.

`* For activity, I am currently considering network / webRequest & JavaScript API access. But there may be things that I haven’t yet thought of. Flagging :englehardt in case he has other activity that we should be mindful of.

We can share more information on how OpenWPM instrument things if that would be useful.

Comment 5

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Logan, you've been doing some analysis of # sourceURL recently. Is there a good simple way to disable support for it?

Honza

Comment 6

[Logan Smyth [:loganfsmyth]]

sourceURL and sourceMappingURL are both related to debugging but independent features, so the source-map feature flag does not affect it. The easiest option to disable it would be to add an option into SpiderMonkey itself to disable exposing the sourceURL value. It has to be in SpiderMonkey because new Error().stack also includes the sourceURL URL, it's not just the stack traces exposed via the debugger UI that are aware of this URL.

Comment 7

[Sarah Bird]

And, for what it’s worth, new Error().stack is how we get meta data as we instrument the JS API in OpenWPM: we listen for calls to APIs, then if one of interest is hit, we throw an error to get the stack trace to pull info about what script called the API. This is the basis for how we detect fingerprinting.

https://github.com/mozilla/OpenWPM/blob/9ee48cdb82e0baeb74defa1cfecfd256b799c6c2/automation/Extension/webext-instrumentation/src/lib/js-instruments.ts#L334-L345

Comment 8

[:Harald Kirschner :digitarald]

I have some idea how OpenWPM as a crawler works, but will follow up async to learn more.

Sarah, if I understand correctly, you need a way to disable sourceURL support for running OpenWPM to get access to the raw stack data – correct?

Comment 9

[Sarah Bird]

:digitarald - good talking today. I would like to disable anything that might interfere with the ability to locate the origin of JS API requests and network requests.

Comment 10

[:Harald Kirschner :digitarald]

Logan, per comment 6, should we move it over to the JS component?

Comment 11

[Logan Smyth [:loganfsmyth]]

Yep, moving it sounds good.

@Sarah Would it be reasonable if the option also disabled sourcemaps? I've been trying to decide how broadly the option should apply. On one side it could literally only affect new Error().stack , and in the middle it could disable specifically //#sourceURL= and at the other extreme it could disable all //#sourceXX= pragma parsing.

Comment 12

[Sarah Bird]

Would it be reasonable if the option also disabled sourcemaps?

Yes! I think it would be confusing otherwise.

(I didn't mention sourceMappingURL as I hadn't investigated whether it has the same effect)

Comment 13

[Logan Smyth [:loganfsmyth]]

sourceMappingURL will only affect DevTools, not new Error().stack so that's why I ask, but if the objective is essentially "show me the files without manipulation" in general for both devtools and new Error().stack then disabling both pragma types makes sense I think.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The product::component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 15

[Logan Smyth [:loganfsmyth]]

Attachment: Bug 1628853 - Expose a feature flag to enable/disable //# sourceXX= parsing. r=arai!

These pragmas can be used to influence stack trace filenames, and to affect
how and where files show up in developer tools. In some circumstances, it can
be nice to disable allof that functionality in order to ensure that you get
the stack trace and debug information as SpiderMonkey sees it.

Comment 16

[Steven Englehardt [:englehardt]]

Sorry for the delay here in chiming in here, and thanks for picking this up so quickly!

As Sarah mentions, we grab the call stack in two places:

• For js calls by throwing an error in overwritten getter/setter methods we use to instrument built-in JS APIs
• For http requests by grabbing the stack in an http-on-opening-request observer.

It sounds like these changes will cover the new Error().stack case. Will they also cover the stack accessed via Components.stack? See: https://github.com/mozilla/OpenWPM/blob/efb191a7f46e2eb0b2a531ca50711b6620df2372/automation/Extension/firefox/src/privileged/stackDump/OpenWPMStackDumpChild.jsm#L122.

Comment 17

[Logan Smyth [:loganfsmyth]]

Will they also cover the stack accessed via Components.stack?

Yep, this should all be addressed by this change.

Comment 18

[Sarah Bird]

Is it possible that this patch will get merged this week, I’d like to run a crawl with this new functionality enabled.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/be6222ed13e7
Expose a feature flag to enable/disable //# sourceXX= parsing. r=arai

Comment 20

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/be6222ed13e7