Opened 2 years ago

Last modified 2 months ago

#21549 new task

Investigate wasm for linkability/fingerprintability/disk avoidance issues

Reported by: gk Owned by: tbb-team
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff60-esr, TorBrowserTeam201809
Cc: dmr, mcs, brade, legind Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by dmr)

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

Child Tickets

Change History (20)

comment:1 Changed 2 years ago by cypherpunks

Keywords: ff52-esr removed

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.

comment:2 Changed 2 years ago by gk

Keywords: ff59-esr added
Sponsor: Sponsor4

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.

comment:3 Changed 13 months ago by gk

Keywords: ff60-esr added; ff59-esr removed

Firefox 60 is the new ESR.

comment:4 Changed 8 months ago by gk

Keywords: TorBrowserTeam201807 added
Priority: MediumHigh

comment:5 Changed 7 months ago by gk

Keywords: TorBrowserTeam201808 added; TorBrowserTeam201807 removed

Move our tickets to August.

comment:6 Changed 6 months ago by gk

Priority: HighVery High

comment:7 Changed 6 months ago by gk

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.

comment:8 Changed 6 months ago by dmr

Cc: dmr added

comment:9 in reply to:  1 Changed 6 months ago by dmr

Description: modified (diff)

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.

comment:10 Changed 6 months ago by gk

Cc: mcs brade added
Keywords: TorBrowserTeam201808R added; TorBrowserTeam201808 removed
Status: newneeds_review

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.

comment:11 Changed 6 months ago by mcs

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

comment:12 Changed 6 months ago by gk

Keywords: TorBrowserTeam201808 added; TorBrowserTeam201808R removed
Status: needs_reviewnew

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

comment:13 Changed 6 months ago by reportUrl

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

comment:14 Changed 6 months ago by gk

Keywords: TorBrowserTeam201809 added; TorBrowserTeam201808 removed

Moving our tickets to September 2018

comment:15 Changed 2 months ago by legind

Cc: legind added

comment:16 Changed 2 months ago by 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.

comment:17 in reply to:  16 Changed 2 months ago by gk

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?

comment:18 Changed 2 months ago by 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?

comment:19 in reply to:  18 Changed 2 months ago by gk

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).

comment:20 Changed 2 months ago by gk

Oh, and one additional point: we might want to have some WebExtensions exceptions on the higher levels of the security slider for things like JIT (see: #23719) which is kind of related.

Note: See TracTickets for help on using tickets.