Comment by noident

1 year ago

I'm not affiliated with the Tor Project organization, but I have some questions.

From Tor docs [0]:

> Add-ons, extensions, and plugins are components that can be added to web browsers to give them new features. Tor Browser comes with one add-on installed: NoScript. You should not install any additional add-ons on Tor Browser because that can compromise some of its privacy features.

How does Kagi square this with Privacy Pass, which requires a browser extension rejected by Tor [1]? Did Kagi analyze whether it is possible to bucket users of Tor into two distinct groups depending on whether the extension is installed? Do I need to trust another organization other than the Tor project to keep the signing keys for the extension safe? Was there any outreach to the Tor community at all prior to releasing this feature?

It's great that they're Torifying the service, but depending on a 3rd party extension is not ideal.

[0] https://support.torproject.org/glossary/add-on-extension-or-...

[1] https://gitlab.torproject.org/tpo/applications/tor-browser/-...

I sat down on my desktop to take a closer look at how Kagi implemented this. It turns out that the privacy pass extension isn't the one implemented by CloudFlare (and rejected by Tor), but a new extension called Kagi Privacy Pass.

Ok, let's look at the source.

    curl -L https://addons.mozilla.org/firefox/downloads/file/4436183/kagi_privacy_pass-1.0.2.xpi > /tmp/extension.xpi
    unzip /tmp/extension.xpi -d /tmp/extension
    cd /tmp/extension

Alright, here's some nice, clean, easy-to-read Javascript. Nice! Wait, what's that?

    // ./scripts/privacypass.js
    /*
     * Privacy Pass protocol implementation
     */
    
    import init, * as kagippjs from "./kagippjs/kagippjs.js";
    ...
    // load WASM for Privacy Pass core library
    await init();

I opened ./kagippjs/kagippjs.js and was, of course, greeted with a WASM binary.

I personally would not install unknown WASM blobs in Tor browser. Source and reproducible build, please!

Let's continue.

    // get WWW-Authenticate HTTP header value
    let origin_wwwa_value = "";
    const endpoint = onion ? ONION_WWWA_ENDPOINT : WWWA_ENDPOINT;
    try {
      const resp = await fetch(endpoint, { method: "GET", headers: { 'X-Kagi-PrivacyPass-Client': 'true' } });
      origin_wwwa_value = resp.headers.get("WWW-Authenticate");
    } catch (ex) {
      if (onion) {
        // this will signal that WWWA could not fetch via .onion
        // the extension will then try normally.
        // if the failure is due to not being on Tor, this is the right path
        // if the failure is due to being on Tor but offline, then trying to fetch from kagi.com
        //   won't deanonymise anyway, and will result in the "are you online?" error message, also the right path
        return origin_wwwa_value;
      }
      throw FETCH_FAILED_ERROR;
    }

What?? If the Onion isn't reachable, you make a request to the clearnet site? That will, in fact, deanonymize you (although I don't know if Tor browser will Torify `fetch` calls made in extensions). You don't want Tor browser making clearnet requests just because it couldn't reach the .onion! What if the request times out while it's bouncing between the 6 relays in the onion circuit? Happens all the time.

> Was there any outreach to the Tor community at all prior to releasing this feature?

Do we know what fraction of Kagi users access it through Tor?

  • It must be a small fraction since they released their Tor onion service 3 hours ago in the original linked article :)