5 ms·

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

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-plugin/ https://support.torproject.org/glossary/add-on-extension-or-... [1] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/24321 https://gitlab.torproject.org/tpo/applications/tor-browser/-...

JumpCrisscross 2y ago
> 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?
- noident 2y ago
  It must be a small fraction since they released their Tor onion service 3 hours ago in the original linked article :)
  - JumpCrisscross 2y ago
    I’m not diminishing Kagi or Tor, I’m asking for validation for the former expanding resources.
noident 2y ago
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.
- abound 2y ago
  [I work at Kagi] The extension is open-source [1], including the Rust code that produces the WASM [2]. You should be able to produce a bit-compatible binary from these repos, and if not, please file a bug! [1] https://github.com/kagisearch/privacypass-extension https://github.com/kagisearch/privacypass-extension [2] https://github.com/kagisearch/privacypass-lib/ https://github.com/kagisearch/privacypass-lib/

JumpCrisscross 2y ago

> 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?

noident 2y ago
It must be a small fraction since they released their Tor onion service 3 hours ago in the original linked article :)
- JumpCrisscross 2y ago
  I’m not diminishing Kagi or Tor, I’m asking for validation for the former expanding resources.

noident 2y ago

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.

abound 2y ago
[I work at Kagi] The extension is open-source [1], including the Rust code that produces the WASM [2]. You should be able to produce a bit-compatible binary from these repos, and if not, please file a bug! [1] https://github.com/kagisearch/privacypass-extension https://github.com/kagisearch/privacypass-extension [2] https://github.com/kagisearch/privacypass-lib/ https://github.com/kagisearch/privacypass-lib/