Investigate wasm for linkability/fingerprintability/disk avoidance issues

In order to avoid the asm.js disaster we should investigate whether wasm complies with our design requirements. It got [in Firefox 52] but [in ESR 52].

added BugSmashFund TorBrowserTeam201910R actualpoints::1.5 component::applications/tor browser ff68-esr owner::tbb-team points::1 priority::very high resolution::fixed severity::normal status::closed tbb-9.0 type::task labels

status-firefox-esr52: disabled https://bugzilla.mozilla.org/show_bug.cgi?id=1342060#c23 But, please, don't postpone such tasks to the next esr.

Trac:
Keywords: ff52-esr deleted, N/A added

If we get earlier to it fine with me. But that needs to get addressed latest with the switch to esr59. Addjusting the key words and sponsor field.

Trac:
Keywords: N/A deleted, ff59-esr added
Sponsor: Sponsor4 to N/A

Firefox 60 is the new ESR.

Trac:
Keywords: ff59-esr deleted, ff60-esr added

Trac:
Priority: Medium to High
Keywords: N/A deleted, TorBrowserTeam201807 added

Move our tickets to August.

Trac:
Keywords: TorBrowserTeam201807 deleted, TorBrowserTeam201808 added

Trac:
Priority: High to Very High

I think we can disable WASM for 8.0 until we are sure we are good here. If we happen to do the analysis and proper patches earlier, great.

Trac:
Cc: N/A to dmr

Replying to cypherpunks:

status-firefox-esr52: disabled https://bugzilla.mozilla.org/show_bug.cgi?id=1342060#c23 But, please, don't postpone such tasks to the next esr.

Indeed disabled in esr52. pref javascript.options.wasm

More details (beyond the comment): https://bugzilla.mozilla.org/show_bug.cgi?id=1342440 https://hg.mozilla.org/releases/mozilla-esr52/rev/e07850f191a0

Changing the description so that others don't need to read comments to know about this.

Trac:
Description: In order to avoid the asm.js disaster we should investigate whether wasm complies with our design requirements. It got enabled in Firefox 52 (and presumably in ESR 52 as well): https://bugzilla.mozilla.org/show_bug.cgi?id=1342060.

to

In order to avoid the asm.js disaster we should investigate whether wasm complies with our design requirements. It got [in Firefox 52] but [in ESR 52].

Let's disable it for now until we are confident we can enable it and let it govern by the security slider. See: bug_21549 (https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_21549&id=19ad2e4d07a06e529920f082eb7d5fdd87e380d4) in my public tor-browser repository.

Trac:
Keywords: TorBrowserTeam201808 deleted, TorBrowserTeam201808R added
Status: new to needs_review
Cc: dmr to dmr, mcs, brade

r=mcs, r=brade Looks good to us.

Thanks. Cherry-picked to tor-browser-60.1.0esr-8.0-1 (commit 3c6862f6cc8a7dc59b9eba41638100638ecb33b0). Setting back to new for the investigation part.

Trac:
Keywords: TorBrowserTeam201808R deleted, TorBrowserTeam201808 added
Status: needs_review to new

Is this enough after tiering was enabled? https://bugzilla.mozilla.org/show_bug.cgi?id=1277562

Trac:
Username: reportUrl

Moving our tickets to September 2018

Trac:
Keywords: TorBrowserTeam201808 deleted, TorBrowserTeam201809 added

Trac:
Cc: dmr, mcs, brade to dmr, mcs, brade, legind

Relevant to HTTPS Everywhere, which would like to rewrite portions of the code in WASM for better performance: https://github.com/EFForg/https-everywhere/issues/17143.

Replying to legind:

Relevant to HTTPS Everywhere, which would like to rewrite portions of the code in WASM for better performance: https://github.com/EFForg/https-everywhere/issues/17143.

I think we could bypass the investigation for HTTPS Everywhere (and extensions in general) at least by assuming it belongs to privileged code (which it does) and that the linkability etc. concerns only applies to content (which I think is not unreasonable). The idea then could be to implement a switch to being able to disable WASM and similar things (ASM.js comes to mind) for content only while leaving chrome like code untouched.

Or maybe the chrome/content separation already exists and WebExtensions are just not properly added to the chrome bucket?

@gk I'm concerned that extensions are a single-click install in most cases, and privileging them in general will open identifiable characteristics to possibly irresponsible third parties. Can we whitelist WASM by extension ID?

Replying to legind:

@gk I'm concerned that extensions are a single-click install in most cases, and privileging them in general will open identifiable characteristics to possibly irresponsible third parties. Can we whitelist WASM by extension ID?

Maybe. However, the current policy is that users are responsible themselves for possible fallout if they are installing other extensions into their Tor Browser. This is not recommended for all sorts of reasons.

Webextensions got already "privileged" by allowing JavaScript to run in general if it is disabled in the browser (you might remember https://bugzilla.mozilla.org/show_bug.cgi?id=1329731). I think it is more straightforward to follow the reasoning dveditz outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=1329731#c7 arguing that disabling WASM for extensions (while allowing it for the remaining parts of the privileged browser) is not the right solution.

FWIW: that Mozilla bug might be a good start for investigating how to enable WASM for extensions only but not content (by checking the principal accordingly).