Skip to content
Snippets Groups Projects
New look: Off

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

    • Closed Issue created by morgan @morgan

    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

    Designs

      Child items 0

      2. No child items are currently assigned. Use child items to break down this issue into smaller parts.

      Activity

      Please register or sign in to reply