HTML5 media support may lead to fingerprinting

I have found out that Tor Browser 4.0 can play videos that older versions of TBB couldn't. It's because the new firefox can load gstreamer plugins into the browser and play mp4 files (inside what I believe to be HTML5 player). I fear this means that gstreamer is able to connect directly or send sensitive information to the server where the video file is hosted. If you change "media.gstreamer,enabled" to "false", it prevents gstreamer from being loaded, but it might cause fingerprinting problems.

Any thoughts on this? Should this be enabled? Or maybe change it in later versions.

It could still be used maybe in TAILS, to make vimeo and other websites able to play videos (using gstreamer in a more secure environment).

added TorBrowserTeam201910 component::applications/tor browser owner::tbb-team priority::high severity::normal status::new tbb-fingerprinting type::defect labels

Firefox using several external multimedia frameworks (GStreamer DirectShow WMF OMX Apple's_MP3), which used to playback media files even if browser plugins disabled. Some of them are proprietary software. Even if no interface for some of them to deanon users directly, it's still vector to exploit bugs, which can't be fixed by Tor Browser update.

Yet, it's realistic way to fingerprint users, HTML5 allows to enumerate supported MIMEtypes/codecs. With simple feedback from canPlayType it's possible to detect platform and/or used OS version or used version of external multimedia framework or presence of them at least.

Trac:
Keywords: N/A deleted, tbb-fingerprinting added
Component: - Select a component to Tor Browser
Owner: N/A to tbb-team

I reviewed the coupling for gstreamer and other codecs on Linux, MacOS, and Windows (see content/media in the Firefox source tree), and it appears that the actual networking is performed over nsIChannels, which should be proxied. See #13020 (moved). The only exception I found was for Android, where RTSP could be used, which uses UDP and not nsIChannels.

Granted the fact that these codecs are binary may mean that they do all sorts of strange things, so prefs to disable these codecs may still be useful for the security slider (#9387 (moved)). We already were thinking of disabling everything but WebM and VP8-9 at the high security level there.

As for fingerprinting, OS fingerprinting is the next cliff of fingerprinting issues, and I suspect a lot of things actually allow the OS type to be inferred in various ways. I think trying to solve the OS fingerprinting issues before dealing with more serious things that actually allow more detailed inference about the computer may be a mistake, especially when it comes at the cost of functionality. Hence I'm trying to break out the fingerprinting issues that likely only yield the OS type into their own sub-tag (tbb-fingerprinting-os).

That said, if different people's computers may have different versions of these codecs installed because of third party software or OS localization/version differences, and that fact is still detectable, then this may be a more serious concern.

Trac:
Summary: Tor Browser 4 loads external plugins to HTML5 media support may lead to OS fingerprinting
Keywords: tbb-fingerprinting deleted, tbb-fingerprinting-os added

We already were thinking of disabling everything but WebM and VP8-9 at the high security level there.

Media plugins and stuff should be disabled by default like browser plugins disabled now. It's not about slider, or slider should to have negative levels that will allow to shoot in the foot, which happens if flash plugin enabled.

OP here:

Mike, thank you for the info (missed that ticket, sorry!). However two questions:

1. What do you mean "binary"? Gstreamer is free software. Are you talking about the codecs installed in the system itself? I would assume using a distro like Debian or Trisquel (which use only free software) would aleviate this issue.

2. So, could this be used in security/privacy manner? Or we should maybe leave it to TAILS? I ask because since TAILS provides a more "fail close" environment, maybe it could be left enabled there but disabled in native TBB. Opinions? Should hackers go and watch redtube porn videos on tor browser bundle with this, or will their momma know their into asian chicks?? :P

Trac:
Cc: N/A to gk

Skruffy pointed out that http://html5test.com/ is a useful test to inspect various aspects of html5 support at a glance. Much of that is based on browser feature set, but there are a few things that are OS dependent there, too.

https://www.mozilla.org/en-US/security/advisories/mfsa2015-31/

Security researcher Aki Helin reported a use-after-free when playing certain MP3 format audio files on the web using the Fluendo MP3 plugin for GStreamer on Linux. This is due to a flaw in handling certain MP3 files by the plugin and its interaction with Mozilla code. This can lead to a potentially exploitable crash.

Set all open tickets without a severity to "Normal"

Trac:
Severity: N/A to Normal

Version also.

Trac:
Username: omg
Keywords: tbb-fingerprinting-os deleted, tbb-fingerprinting-os-version added
Reviewer: N/A to N/A
Sponsor: N/A to N/A

Trac:
Keywords: tbb-fingerprinting-os-version deleted, tbb-fingerprinting-os added

FWIW: we should use this bug as well to think about possible issues with/solutions for the MediaCapabilities API as well. https://bugzilla.mozilla.org/show_bug.cgi?id=1461454 is the tracking bug on Mozilla's side. Research by tjr suggests that this is indeed not only an OS fingerprinting vector, thus raising prio. See the thread on tbb-dev for more details: https://lists.torproject.org/pipermail/tbb-dev/2019-January/000946.html

Trac:
Priority: Medium to High
Keywords: tbb-fingerprinting-os deleted, tbb-fingerprinting added

Trac:
Summary: HTML5 media support may lead to OS fingerprinting to HTML5 media support may lead to fingerprinting

Trac:
Keywords: N/A deleted, ff68-esr, tbb-9.0-must, TorBrowserTeam201910 added

For review: https://github.com/acatarineu/tor-browser/commit/13543

This should skip checking for hardware acceleration or performing a benchmark when RFP is enabled, and always set smooth = true and powerEfficient = true instead. I only modified one case, since AFAIK it's the only one where the value smooth or powerEfficient depend on hardware capabilities.

The intent was to implement the solution mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1461454#c6.

Trac:
Status: new to needs_review
Keywords: TorBrowserTeam201910 deleted, TorBrowserTeam201910R added

I think it would be better to put the RFP behavior in a more obvious place:

an else if case here: https://searchfox.org/mozilla-esr68/source/dom/media/mediacapabilities/MediaCapabilities.cpp#285

containing

MediaCapabilitiesInfo(true, true, true)

Trac:
Status: needs_review to needs_revision
Keywords: TorBrowserTeam201910R deleted, TorBrowserTeam201910 added

Revised: https://github.com/acatarineu/tor-browser/commit/13543+1.

Out of curiosity, is there a reason why MediaCapabilitiesInfo(true, true, true) is better than MediaCapabilitiesInfo(true, true, false), or is it just that we had to pick one? In Linux (true, true, false) seems to be more common, but maybe the other is more found in Windows and Mac?

Trac:
Status: needs_revision to needs_review
Keywords: TorBrowserTeam201910 deleted, TorBrowserTeam201910R added

Sorry; I don't have an informed opinion on that - I'll defer to you. I just wanted the RFP case to be clearer.

Ok, let's leave it as it is then.

Replying to acat:

Ok, let's leave it as it is then.

Cherry-picked to tor-browser-68.1.0esr-9.0-2 (commit 990e3caf34672b64f30db79f585903b8ce4f88d6).

I wonder whether we should pick (true, true, false), though, instead. Leaving this ticket open to decide this.

Trac:
Status: needs_review to new
Keywords: TorBrowserTeam201910R deleted, TorBrowserTeam201910 added

I thought a bit more, I don't have a very strong opinion in favor of one or another, basically because I'm not sure how this API will be used by websites. But I think it may be better to be conservative and say it's not power efficient while it actually may be than the opposite. For smooth the same reasoning might apply, but I think it's not so common to find cases where the returned info is (true, false, false) (I did not find those in a couple of home machines, although it may be possible in slow machines).

Since we have to pick one, I'm voting for (true, true, false): https://github.com/acatarineu/tor-browser/commit/13543+2.

Trac:
Status: new to needs_review
Keywords: TorBrowserTeam201910 deleted, TorBrowserTeam201910R added

Replying to acat:

I thought a bit more, I don't have a very strong opinion in favor of one or another, basically because I'm not sure how this API will be used by websites. But I think it may be better to be conservative and say it's not power efficient while it actually may be than the opposite. For smooth the same reasoning might apply, but I think it's not so common to find cases where the returned info is (true, false, false) (I did not find those in a couple of home machines, although it may be possible in slow machines).

Since we have to pick one, I'm voting for (true, true, false): https://github.com/acatarineu/tor-browser/commit/13543+2.

Looks good to me. I cherry-picked your fixup to tor-browser-68.1.0esr-9.0-3 (commit 084aa467fafc8aee4c2fbb57e872096386aca775).

I guess on hindsight I should have put the MediaCapabilities related work in a proper child ticket and treat this one as just a meta/parent one. We should review the HTML5 fingerprinting scope here and then file child tickets from now on. If we think we are good after review, let's close this bug.

Trac:
Keywords: TorBrowserTeam201910R deleted, TorBrowserTeam201910 added
Status: needs_review to new

Trac:
Keywords: tbb-9.0-must deleted, N/A added

The ff68-esr specific bits are gone.

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

mentioned in issue #18782 (moved)

mentioned in issue #22548 (moved)

mentioned in issue #26146 (moved)

mentioned in issue #31591 (moved)

moved to tpo/applications/tor-browser#13543 (closed)