Skip to content

Expose a stable asset from chrome:// to identify Tor, Base, and Mullvad Browser

To Quote @henry from #43308 (comment 3133265):

@thorin in that case I don't recommend using chrome://global/content/torconnect/tor-connect.svg because we're probably going to be moving torconnect back to browser once we no longer use it on android.

If a stable asset is desired, then I would open another issue similar to tor-browser#41892 to ask for this. And cc all the developers as well to spread awareness and so we can agree on something we'll all be happy to keep around for a while, so it really is stable!

We could then a comment in the chosen asset and the jar.mn saying "Do not remove or edit! See tor-browser#".

We should expose some stable asset for (at least) two purposes:

  • solve the chicken+egg problem of identifying if a browser is a particular browser in fingerprinting scripts

    • allow tools to ensure their users are connecting from a secure+private browser (i.e. Tor Browser)

      • SecureDrop does this in an unstable manner to ensure their users aren't connecting Brave, or Firefox + manual tor configuration
      • One could imagine other tools may want this as well (e.g. OnionShare, other sensitive onion-services /cc @rhatto)

    • hello future GitLab archaeologists! See this in-depth comment from @thorin for why this is desirable:

      @thorin said

      let me re-iterate what I asked for over a year ago - I closes the issue recently due to lack of interest and hope

      background

      • we can't hide TB
        • FP characteristics + tor
        • we're not trying to hide that we're TB
        • there is even a ticket somewhere about sending an onion HTTP header
      • we can't hide MB
        • ^ if we factor in that it's basically the same FP as TB minus a few bits
      • at some stage TB and MB can align their FPs (except the tor part)
        • this makes both groups benefit from more users which is a key part of FP protection, i.e you need a crowd and the larger the better
        • diffs are minimal: webrtc, media devices and wordmark/logo
      • TZP has different health check criteria for TB vs MB
        • because TB and MB FP's are currently different
        • that is if media devices leaked on TB I can't give it green thumbs up as MB
      • one day when both browsers are the same (sans tor), I won't need this
      • why do I need to know this beforehand and not deduce it after
        • because that's circuitous logic and flawed
        • I could make FF look like TB/MB (ignoring the tor part)
        • what if everything matched TB except two things - is it then TB or MB or FF?
        • I need definitive knowledge of the browser brand - which again we are not trying to hide

      TZP currently

      • checks for chrome://browser/content/abouttor/aboutTor.css [1] to determine if TB
        • if not TB, then it checks the combo of workmark and logo dimensions to determine MB or FF
        • so until we lock off chrome + resource, this has worked
      • if we lock off chrome + resource then I cannot determine how to apply some health checks
        • health checks are different for TB vs MB vs FF (yes, I also do health on FF and FPP)

      outcome required

      • 1: detect basebrowser vs any other forks/FF
      • 2: if basebrowser detect MB vs TB (until they align JS fingerprints in the future)

      solutions

      • lock off all chrome + resource
      • add two empty web-accesible files
        • bb.css
        • tb.css
      • use any sizes you want for any wordmarks and logos
        • they no longer accessible - no risk no fuss no footguns
      • when TB and MB align fingerprints one day, remove tb.css to remove that last difference

      [1] sidenote: android

      • chrome://browser/content/abouttor/aboutTor.css
        • ^ does not work on android since TBA13
        • so since TBA13 I have basically ignored android testing or health checks
      • chrome://global/content/torconnect/aboutTorConnect.css (added in TB13.5)
        • ^ I am told works on android but I tested it and it didn't - maybe I need to test again

It looks like the requirements are basically:

  • must be able to differentiate base-browser from other browsers and subsequently Tor + Mullvad Browser at least until their fingerprints converge
    • we probably would want to keep this even when the fingerprint converge for the SecureDrop and friends
    • I can't think of anything in the particular scenario of SecureDrop with Mullvad Browser which (in a world where the fingerprint is the same) would put users at risk, but it seems likely that Mullvad Browser + user-configured tor is less secure than default Tor Browser
  • must not be spoofable by extensions or about:config prefs
  • must be stable long-term and developer-friendly
  • must work on Android!

Questions:

  • @thorin how is TZP doing its detection now with chrome://browser/content/abouttor/aboutTor.css? Existence of the asset?
  • Do we want to expose further general debug info for stuff that is already measurable but also suffers a similar chicken+egg and stability problems (e.g. platform, OS, release channel, major version)?
    • if we do want this further info, how to encode it/present it?
  • Maybe an ignorant question: Do we want something that is detectable without JavaScript?
Edited by morgan
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information