TorBrowser Noscript plugin does not block HTML5 audio/video tags
Software: TorBrowser 3.5.1 Relevant to recent bug: https://trac.torproject.org/projects/tor/ticket/8386
The TorBrowser software design document states:
"Plugins must be restricted Even if plugins always properly used the browser proxy settings (which none of them do) and could not be induced to bypass them (which all of them can), the activities of closed-source plugins are very difficult to audit and control. They can obtain and transmit all manner of system information to websites, often have their own identifier storage for tracking users, and also contribute to fingerprinting.
Therefore, if plugins are to be enabled in private browsing modes, they must be restricted from running automatically on every page (via click-to-play placeholders), and/or be sandboxed to restrict the types of system calls they can execute. If the user agent allows the user to craft an exemption to allow a plugin to be used automatically, it must only apply to the top level url bar domain, and not to all sites, to reduce cross-origin fingerprinting linkability. "
What this implies, is that software components to the browser should be under scrutiny from a security standpoint. I hold that the audio/video rendering engine of firefox is such a component.
From the design: "We have verified that these settings and patches properly proxy HTTPS, OCSP, HTTP, FTP, gopher (now defunct), DNS, SafeBrowsing Queries, all javascript activity, including HTML5 audio and video objects..." Also: "The adversary simply renders WebGL, font, and named color data to a Canvas element, extracts the image buffer, and computes a hash of that image data. Subtle differences in the video card, font packs, and even font and graphics library versions allow the adversary to produce a stable, simple, high-entropy fingerprint of a computer." Finally, "At least two HTML5 features have different implementation status across the major OS vendors: the Battery API and the Network Connection API. We disable these APIs through the Firefox preferences dom.battery.enabled and dom.network.enabled. "
So you have determined that the audio and video object are properly proxied, yet the features conflict with the security requirement. Basically, you have blocked WebGL and several HTML5 subcomponents, for reasons of security and fingerprint-ability, but are not blocking the audio/video tag, which likely has the same issues. It appears your study only included audio/video proxying, and not the security, fingerprint-ability, or data retention requirements.
The audio/video tags are HTML5 tags that allow the loading, streaming, storing, proxying, and playing of rich-media content such as audio and videos. This software is built into Firefox. It is a multimedia engine written in C++ for variety of platforms and shipped with the Firefox code. It is not necessary for browsing. Other researchers have deemed there will be trouble here, with flash you have one player, multiple platforms--here, there will be different implementations in every browser--a zero-day paradise.
The rational is simple: Adobe wrote Flash 10 years ago and there are still 130 vulnerabilities EVERY YEAR, for what amounts to simply a vector graphics/video player! And that is from developers that have feedback from millions of systems and specialize in writing that type of code. I hold that the Mozilla developers do not have the same experience as the Flash developers, and hence will have the same, if not more, vulnerabilities in their implementation of these HTML5 tags. Granted this is a "how many piano tuners are in Chicago" analysis, but it may be valid.
Therefore, I conclude, that the audio/video tags are against the design of the tor browser at this point. Even though the code may be open source, it cannot be deemed to be secure, or even more secure than flash. Yet, Flash/Gnash has not been endorsed/recommended. I do not believe the tor project has the bandwidth to ensure these tags will meet the design at this point.
Therefore, I see that having these components ON by default is a defect.
Here is the relevant diff files: https://gitweb.torproject.org/torbrowser.git/commitdiff/db11fa55d2a27a01f766bb0c90858381fd9f0c97 https://gitweb.torproject.org/torbrowser.git/commitdiff/94b632f285c92e57dd88af18ede4448d6e1a901c
Trac:
Username: gilidula