Skip to content
Snippets Groups Projects

ImportantGoogleChromeBugs

Last edited by Alexander Færøy

PageOutline

Important Google Chrome Bugs

It would be great if the Tor Project could create a Chrome extension to upgrade Google Chrome's Incognito Mode into a full privacy mode that protects against all network adversaries, giving Chrome users real privacy-by-design if and when they want it.

Ideally, we'd like some help in the form of several improvements to Incognito Mode to reduce linkability while using the mode.

However, we still have a few important issues to tackle before even low-grade privacy-by-design can be provided through Tor in Incognito mode. This page exists to track those issues by referencing relevant items in the Chromium bug tracker.

The following groups of bugs are ordered from most important to least.

Proxy Bypass Bugs

First and foremost, there are a few bugs that allow direct bypass of the Incognito mode proxy settings. Without fixes for these bugs, there is little point in attempting a Tor extension at all, since the user's real IP can be revealed in typical use cases, even without any actual exploit attempt.

In addition, the following behaviors still need to be investigated:

  • Can we block drag and drop events? On most desktops, the OS actually pre-loads the URL associated with a drag event as soon as you start dragging an object, even if you don't drop it on the desktop.
  • Do WebSockets behave correctly? On Firefox, they leaked DNS.
  • Do the NTLM and SPNEGO HTTP authentication methods bypass the proxy? OS libraries used for those, too.

Browser State Leak Bugs

After issues that allow direct proxy bypass, there are still a number of ways that browser state can cross between Incognito mode and regular browsing. These bugs are a huge concern for us, as they can allow tracking of the user between normal and Torified Incognito modes. There are also even some ways that Incognito browsing activity can be written to disk as a result of these bugs.

  • Maintain separate TLS session caches per-profile - fixed in december 2011 (wild guess: 18.0.970.1), workaround: none?
  • XXX: SPDY state and connection reuse, HTTP keepalive connection reuse, and HSTS state? Probably all shared...
  • XXX: The CryptoAPI dependency on Windows probably means most or all TLS state is shared, including TLS session resumption and session tickets, the user cert store, intermediate TLS certificate cache, and OCSP cache..

UI barriers

Third Party Identifiers

In Tor Browser, we prevent third parties from tracking you across top-level domains by "double-keying" identifier sources to the url bar domain and the third party. It sure would be nice if the third party cookie option in Chrome did this, too. Here's the list of related issues:

  • XXX: Bug number? The Third Party Cookie pref should also "double-key" or disable DOM storage, cache, HTTP Auth and HSTS for third parties. In Tor Browser, we double-key most of this stuff rather than disable it, to minimize breakage.
  • XXX: Bug Number? window.name should not persist across domains
  • XXX: Bug Number? SSL Session ids and TLS session tickets should be disabled for third parties.
  • XXX: Bug Number? SPDY can store session IDs and other state, and has insane keep-alive properties. SPDY state should be similarly jailed to URL bar domain, and third party requests and state should not cross url bar barriers.

Fingerprinting Issues

Fingeprinting is a complicated problem, and there is much debate about how well it can be solved. It's unlikely that we'll be able to completely conceal the differences between a Windows user and a Linux user, but it is certainly possible to push Javascript from being able to determine quite so much about a computer's configuration and hardware. Here are some of the worst examples we've found:

  • XXX: needs bug HTML5 Canvas should be permission-based for reading image data (rendering to it is fine, only extraction is an issue). There is a Chrome addon for this, but it is prone to races due to async script injection. We need a real solution.
  • XXX: needs bug The GamePad API allows USB device IDs for any controller-like devices to be enumerated by JS.
  • XXX: needs bug CSS Media Queries allow screen info and even user-selected system theme colors and other user-configured UI information to be extracted by CSS (even without JS). Spoof/disable for Incognito Mode.
  • XXX: needs bug WebGL should not expose OpenGL/DirectX extension and device capabilities (aka should run in "W3C minimal mode") in Incognito Mode
  • XXX: needs bug NTLM and SPNEGO Auth should not send machine hostname or username in Incognito Mode.
  • XXX: needs bug The desktop and taskbar resolution should not be available to CSS or JS -- provide content window size only.
  • XXX: needs bug Addons should be able to install a font pack for exclusive use in Incognito Mode.
  • XXX: needs bug Disable high-resolution DOM and network performance timers in Incognito Mode
  • XXX: needs bug Reduce Javascript Date and event timestamp precision in Incognito mode (this increases the runtime and reduces the accuracy of performance fingerprinting)

Those are the major issues. You can see the full list of fingerprinting issues in Firefox in our bug tracker, past and present.

These bugs are related to addressing fingerprinting issues. Solutions to fingerprinting are still more art than science at this point. What we need are flexible APIs to allow us to prototype potential solutions. These issues are not blockers, but are things we would strive to have before Chrome could become the recommended tor browser. There's probably [more to add](https://www.torproject.org/projects/torbrowser/design/#fingerprinting-linkability) to this list, too.

 * [Apply content scripts to about: and data: urls](https://code.google.com/p/chromium/issues/detail?id=55084) - workaround: disable javascript (mentions #1816)
 * [Content script injection not working on Extensions gallery](https://code.google.com/p/chromium/issues/detail?id=33505)
 * [Add API - QWebUserEnvironment](https://bugs.webkit.org/show_bug.cgi?id=56678) - required to hide window port size and resolution, resolved: won't fix
 * [Make CSSMedia queries pass through Chrome and ChromeClient](https://bugs.webkit.org/show_bug.cgi?id=56482) - resolved: won't fix
 * [Delegate some read-only DOM properties to FrameLoaderClient and ChromeClient](https://bugs.webkit.org/show_bug.cgi?id=56274) - resolved: won't fix

Note that webkit has a set of tools to control fingerprinting that Chrome could use.

Blue-sky API wishlist

The plugin sandboxing support can potentially allow us to write a more restricted sandbox that we deem will allow Flash and other plugins to be safe enough to use in the mode. There is no bug for it yet, but it would build on this one: https://code.google.com/p/chromium/issues/detail?id=50796

Comments

    Please register or sign in to add a comment.