Arbitrary WebAPI JS instrumentation #642

birdsarah · 2020-05-09T09:31:27Z

Fixes #641

To do:

      js_instrument:true,
      js_instrument_modules: [
        // Shortcut
        "fingerprinting",
        // APIs
        "Storage",
        {"XMLHttpRequest": ["send"]},
        // Specific instances on window
        {"window.document": ["cookie", "referrer"]},
        {"window": ["name", "localStorage", "sessionStorage"]}
      ],
      http_instrument:true,
      callstack_instrument:true,

For follow-on issues:

Update openwpm-crawler with new input
~~Add an "all" option~~ (nope - crashes everything)
~~Do you want to be able to specify just a property? e.g. XMLHttpReqest.send vs XMLHttpRequest (this could be a follow-on PR)~~

Questions:

For "fingerprinting" - do we want to keep the current set of instrumented APIs which is some whole modules, and sometimes just a limited set of properties? For example, we only take pixelDepth and colorDepth from window.screen instead of the full 15 or so options. The difference might be starker on other modules, I haven't done a thorough review.
- Keep the same for now.
I'm leaving all logSettings options default. As best as I can tell we've never used them. Thoughts? (Given that we haven't used it, I'm tempted to propose removing it to simplify the code).
- I was wrong. They're all used (or desired in the webcompat work - master...motin:webcompat-instrumentation). This PR hopefully makes logSettings and it's default clearer.
Why not have it so settings are passed around as JSON and JSON is handled webext side.
- Because by making a magic js string we are actually referring to the window object as opposed to having a string in JSON. It's' the difference between '{object: window.CanvasRenderingContext2D.prototype, instrumentedName: "CanvasRenderingContext2D",...}' and {object: "window.CanvasRenderingContext2D.prototype", instrumentedName: "CanvasRenderingContext2D",...}. In the latter case where we're passing around JSON, on the JS side we then have to find a way to turn the string "window.CanvasRenderingContext2D.prototype" into the object window.CanvasRenderingContext2D.prototype.

Getting errors like OpenWPM: Error name: TypeError post_request_ajax.html:237:17 OpenWPM: Error message: can't redefine non-configurable property "UNSENT" post_request_ajax.html:238:17

birdsarah · 2020-05-12T23:05:03Z

@englehardt - how would you feel if "fingerprinting" instrumented a few more things e.g. whole of navigator and CanvasRenderingContext2D?

englehardt · 2020-05-12T23:15:36Z

@englehardt - how would you feel if "fingerprinting" instrumented a few more things e.g. whole of navigator and CanvasRenderingContext2D?

If it seems like it can be used for fingerprinting I think it's fair game. My only warning is that some APIs are incredibly noisy.

birdsarah · 2020-05-12T23:23:14Z

My only warning is that some APIs are incredibly noisy.

Yeah, I think I need to leave a more flexible solution open.

birdsarah · 2020-05-12T23:48:25Z

@englehardt - how do you feel about this as a starting point API for this PR. It will meet all my needs and the needs of the current fingerprinting instrumentation. We can follow-up with more implementation as needs arise (see "follow-on prs" above).

      js_instrument:true,
      js_instrument_modules: [
        // Shortcut
        "fingerprinting",
        // APIs
        "Storage",
        {"XMLHttpRequest": ["send"]},
        // Specific instances on window
        {"window.document": ["cookie", "referrer"]},
        {"window": ["name", "localStorage", "sessionStorage"]}
      ],
      http_instrument:true,
      callstack_instrument:true,

englehardt · 2020-05-13T19:07:41Z

@englehardt - how do you feel about this as a starting point API for this PR. It will meet all my needs and the needs of the current fingerprinting instrumentation. We can follow-up with more implementation as needs arise (see "follow-on prs" above).

      js_instrument:true,
      js_instrument_modules: [
        // Shortcut
        "fingerprinting",
        // APIs
        "Storage",
        {"XMLHttpRequest": ["send"]},
        // Specific instances on window
        {"window.document": ["cookie", "referrer"]},
        {"window": ["name", "localStorage", "sessionStorage"]}
      ],
      http_instrument:true,
      callstack_instrument:true,

This looks like a great starting point! Thanks!

* We build and mandate LogSettings. * We have a new JSInstrumentatinRequest that everything runs through * Preset, fingerprinting, will be specified in JSON

Enum for Operation

Changing my mind - all validation and construction to be done python side. This will reduce JS overhead at runtime.

Can't do all the things I want to with typing due to scope when content is loaded into page.

This reverts commit 8eb4edb.

birdsarah · 2020-06-26T04:23:15Z

@englehardt This PR is finished. I've incorporated all your suggestions / questions / concerns and the things we discussed in person the other day. The only thing I had to not do was "JSON everywhere". Half way through changing, I remembered why I don't do that. Here's why:

(copied from front matter on this PR)

Why not have it so settings are passed around as JSON and JSON is handled webext side.
- Because by making a magic js string we are actually referring to the window object as opposed to having a string in JSON. It's' the difference between '{object: window.CanvasRenderingContext2D.prototype, instrumentedName: "CanvasRenderingContext2D",...}' and {object: "window.CanvasRenderingContext2D.prototype", instrumentedName: "CanvasRenderingContext2D",...}. In the latter case where we're passing around JSON, on the JS side we then have to find a way to turn the string "window.CanvasRenderingContext2D.prototype" into the object window.CanvasRenderingContext2D.prototype.

Whilst it may be possible to do it via JSON being passed to the webext, I don't think it should hold up this PR. Users still write a python list or JSON, it's just the transport between python and webext that's finecky and I don't think this PR needs to guarantee that that interface will be stable.

englehardt

r+ with a few comments and nits. Thanks for taking this all the way and adding some thorough tests for the changes!

Whilst it may be possible to do it via JSON being passed to the webext, I don't think it should hold up this PR. Users still write a python list or JSON, it's just the transport between python and webext that's finecky and I don't think this PR needs to guarantee that that interface will be stable.

Okay that makes sense. I guess we could eval those strings, but that seems messy. Either way, no need to hold up this PR.

README.md

englehardt · 2020-07-01T23:47:15Z

automation/Extension/webext-instrumentation/src/types/browser-web-navigation-event-details.ts

@@ -45,11 +45,13 @@ export interface WebNavigationOnCommittedEventDetails
  transitionQualifiers?: TransitionQualifier[];
 }

+/*


Why comment these out?

Whoops. Was planning to delete them. They're not used anywhere so was just cleaning up. That can be separate PR.

englehardt · 2020-07-01T23:49:28Z

automation/js_instrumentation.py

@@ -5,7 +5,7 @@

 curdir = os.path.dirname(os.path.realpath(__file__))
 schema_path = os.path.join(
-    curdir, 'js_instrumentation', 'js_instrument_modules.schema'
+    curdir, os.pardir, 'schemas', 'js_instrument_settings.schema.json'


Is .schema.json the accepted naming pattern, or should this be _schema.json?

It's the naming pattern that the jsonschema2md uses by default. i'm not wed to it, I don't think it's a big change to jsonschema2md call to fix it.

If it's the default that's fine. No need to change, I just wanted to make sure this wasn't a bug.

package.json

test/openwpm_jstest.py

test/test_js_instrument.py

test/test_js_instrument_py.py

Co-authored-by: Steven Englehardt <englehardt@gmail.com>

* Add title * Fix typo in mac-osx hyperlink

We're not using the js in two htmls now, so unify like other test files

* pyside test must instrument browser apis * add more to readme to clarify instrumenting

birdsarah · 2020-07-08T06:50:43Z

@englehardt this is done. The bad test needed a bigger tweak (#642 (comment)) but nothing wild.

test/test_pages/js_instrument/instrument_pyside.html

birdsarah added 9 commits May 8, 2020 19:49

Add mdn-browser-compat-data

cd40e32

js_instrument_modules as list

a2531b2

Add mdn-browser-compat

b7403d0

Pass a list of instrumentingFunctions

d211a1c

Script to generate api data

7db500b

Working give or take

5046246

Getting errors like OpenWPM: Error name: TypeError post_request_ajax.html:237:17 OpenWPM: Error message: can't redefine non-configurable property "UNSENT" post_request_ajax.html:238:17

Small naming cleanup

2a97262

Handle non-configurable properties

946ec07

Lint

7fd8842

Add aspirational API

ba6ab10

birdsarah added 3 commits May 18, 2020 12:56

Merge branch 'master' into js-instrumentation

eba6c96

Begin migration to new JSInstrumentationRequest interface.

5276454

* We build and mandate LogSettings. * We have a new JSInstrumentatinRequest that everything runs through * Preset, fingerprinting, will be specified in JSON

Continue making progress

3d72db9

Enum for Operation

birdsarah marked this pull request as draft May 18, 2020 23:40

birdsarah changed the title ~~[WIP] Arbitrary WebAPI JS instrumentation~~ Arbitrary WebAPI JS instrumentation May 18, 2020

birdsarah added 8 commits May 18, 2020 19:06

Begin implementing jsModuleRequest validation.

a9f3d93

Changing my mind - all validation and construction to be done python side. This will reduce JS overhead at runtime.

Big cleanout- js-instrumentation work moving to python.

9139ebe

Continue update to python js-instrumentation

ce3b80e

Lint

cdd2f0d

Can't do all the things I want to with typing due to scope when content is loaded into page.

noqa on wip jsinstrumentation file

de83eac

Begin updating existing js instrument tests.

82720a2

Merge branch 'master' into js-instrumentation

d9266c6

Merge branch 'issue-443' into js-instrumentation

0226f8d

birdsarah changed the base branch from master to issue-443 May 19, 2020 04:43

Small cleanups

68f8077

birdsarah added 11 commits June 25, 2020 17:50

Clean-up naming in schema

bceda0e

Add processing of json schema to documentation

8c385e0

Rename js_instrumentation again and ref schema location

5b7e653

Pass JSON not a js string

8eb4edb

Do copying to xpi in npm postbuild step

fd844b3

Fix import in manual_test

2e8eaac

Revert "Pass JSON not a js string"

60bae1a

This reverts commit 8eb4edb.

Add titles to schema pieces

7072504

Merge branch 'master' into js-instrumentation

a21d40d

Add docs for js_instrument_settings

5a3230f

Bit more README cleanup

389f4a2

birdsarah marked this pull request as ready for review June 26, 2020 04:18

birdsarah requested a review from englehardt June 26, 2020 04:18

Merge branch 'master' into js-instrumentation

7a97b86

englehardt approved these changes Jul 2, 2020

View reviewed changes

birdsarah and others added 6 commits July 1, 2020 23:20

Update README.md

e9a7dc8

Co-authored-by: Steven Englehardt <englehardt@gmail.com>

Move updating schema docs section

12141c5

* Add title * Fix typo in mac-osx hyperlink

Make the single-key dictionary clearer

76b3712

Remove versions from npm package files

7dcebfc

Clean up instrument_existing_window_property.html and js

2a35910

We're not using the js in two htmls now, so unify like other test files

Fix pyside instrumentation test, add more clarificaiton to README

9559ec9

* pyside test must instrument browser apis * add more to readme to clarify instrumenting

englehardt reviewed Jul 8, 2020

View reviewed changes

test/test_pages/js_instrument/instrument_pyside.html Outdated Show resolved Hide resolved

birdsarah added 2 commits July 8, 2020 12:54

Use example.com and example.org as localDomains

e2ef603

context-manage open, and flake8

95465a8

birdsarah mentioned this pull request Jul 8, 2020

v0.11.0 / Firefox 78.0.1 release #706

Merged

englehardt merged commit aefa048 into master Jul 8, 2020

englehardt deleted the js-instrumentation branch July 8, 2020 22:55

birdsarah mentioned this pull request Jul 8, 2020

Improve utility of install.sh script #710

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Arbitrary WebAPI JS instrumentation #642

Arbitrary WebAPI JS instrumentation #642

birdsarah commented May 9, 2020 •

edited

Loading

birdsarah commented May 12, 2020

englehardt commented May 12, 2020

birdsarah commented May 12, 2020

birdsarah commented May 12, 2020

englehardt commented May 13, 2020

birdsarah commented Jun 26, 2020

englehardt left a comment

englehardt Jul 1, 2020

birdsarah Jul 2, 2020

englehardt Jul 1, 2020

birdsarah Jul 2, 2020

englehardt Jul 2, 2020

birdsarah commented Jul 8, 2020

Arbitrary WebAPI JS instrumentation #642

Arbitrary WebAPI JS instrumentation #642

Conversation

birdsarah commented May 9, 2020 • edited Loading

birdsarah commented May 12, 2020

englehardt commented May 12, 2020

birdsarah commented May 12, 2020

birdsarah commented May 12, 2020

englehardt commented May 13, 2020

birdsarah commented Jun 26, 2020

englehardt left a comment

Choose a reason for hiding this comment

englehardt Jul 1, 2020

Choose a reason for hiding this comment

birdsarah Jul 2, 2020

Choose a reason for hiding this comment

englehardt Jul 1, 2020

Choose a reason for hiding this comment

birdsarah Jul 2, 2020

Choose a reason for hiding this comment

englehardt Jul 2, 2020

Choose a reason for hiding this comment

birdsarah commented Jul 8, 2020

birdsarah commented May 9, 2020 •

edited

Loading