Opened 2 years ago

Last modified 3 days 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: ff68-esr, TorBrowserTeam201907
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 (22)

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 17 months ago by gk

Keywords: ff60-esr added; ff59-esr removed

Firefox 60 is the new ESR.

comment:4 Changed 12 months ago by gk

Keywords: TorBrowserTeam201807 added
Priority: MediumHigh

comment:5 Changed 11 months ago by gk

Keywords: TorBrowserTeam201808 added; TorBrowserTeam201807 removed

Move our tickets to August.

comment:6 Changed 10 months ago by gk

Priority: HighVery High

comment:7 Changed 10 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 10 months ago by dmr

Cc: dmr added

comment:9 in reply to:  1 Changed 10 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 10 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 10 months ago by mcs

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

comment:12 Changed 10 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 10 months ago by reportUrl

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

comment:14 Changed 10 months ago by gk

Keywords: TorBrowserTeam201809 added; TorBrowserTeam201808 removed

Moving our tickets to September 2018

comment:15 Changed 6 months ago by legind

Cc: legind added

comment:16 Changed 6 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 6 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 6 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 6 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 6 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.

comment:21 Changed 10 days ago by legind

Update: in https://github.com/EFForg/https-everywhere/pull/18093, HTTPS Everywhere includes WASM optimizations. So Tor Browser would see an OOTB performance increase and memory overhead decrease by enabling WASM in extension-land.

comment:22 Changed 3 days ago by gk

Keywords: ff68-esr TorBrowserTeam201907 added; ff60-esr TorBrowserTeam201809 removed

We have #23719 for the slider related things and this bug for the general enabling. Talking to Luke I think we are in good shape (surprise!) and nothing stood out. One thing that remains to test is whether New Identity is actually blowing away WASM related cache in case someone used Tor Browser outside of Private Browsing Mode (there are no WASM cache entries written to disk in that mode).

Note: See TracTickets for help on using tickets.