Session token is shown briefly in URL bar when performing search in Firefox

[raxod502]

This is a follow-on from https://kagifeedback.org/d/2550-add-kagi-search-shouldnt-save-with-session-token-in-url/7 since I didn't see anywhere it has been discussed on GitHub. As reported in that feedback thread, when you do a search while using the Kagi for Firefox addon, the session token is temporarily shown in the URL bar as a query parameter. I took a screen recording demonstrating the behavior, but for obvious reasons that is problematic to post here.

I had a quick look through the code to see if this seemed more like an addon coding issue or more like a Firefox API design issue. What I found surprised me:

browser_extensions/shared/src/background.js

Lines 123 to 146 in 5190249

	await browser.declarativeNetRequest.updateDynamicRules({
	addRules: [
	{
	id: 1,
	priority: 1,
	action: {
	type: 'modifyHeaders',
	requestHeaders: [
	{
	header: 'X-Kagi-Authorization',
	value: sessionToken,
	operation: 'set',
	},
	],
	},
	condition: {
	urlFilter: '||kagi.com/',
	resourceTypes: ['main_frame', 'xmlhttprequest'],
	},
	},
	],
	removeRuleIds: [1],
	});
	}

This code seems to suggest that we are transparently authenticating all Kagi requests using a header. Great: but then what is the point of setting the session token in the query parameter? It seems like we could just remove that and eliminate the security risk, while still having search work in private browsing windows automatically.

[z64]

Hi @raxod502 ! I think I understand the situation, @PixeLInc may correct me, but I will dump what I think is all the relevant context:

There are two primary ways of setting Kagi as your default in Firefox:

1. Using the "add search engine" from the URL bar, as shown in our docs
2. Using this extension

Here is how the first option works:

1. Firefox discovers this via https://kagi.com/opensearch.xml
2. This XML file describes to Firefox how to query Kagi
3. It gets registered as a search engine

It looks something like this:

<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
<ShortName>Kagi</ShortName>
<Description>A privacy-focused, user-centric search engine.</Description>
<InputEncoding>UTF-8</InputEncoding>
<Image width="180" height="180" type="image/png">https://kagi.com/apple-touch-icon.png</Image>
<Image width="48" height="48" type="image/x-icon">https://kagi.com/favicon.ico</Image>
<Image width="32" height="32" type="image/png">https://kagi.com/favicon-32x32.png</Image>
<Image width="16" height="16" type="image/png">https://kagi.com/favicon-16x16.png</Image>
<Url rel="results" type="text/html" template="https://kagi.com/search?q={searchTerms}"/>
<Url rel="suggestions" type="application/x-suggestions+json" template="https://kagisuggest.com/api/autosuggest?q={searchTerms}"/>
</OpenSearchDescription>

There is a problem. This will work in normal browsing, but not private browsing, of course - there's no cookies carried over. But if you actually do this yourself, you'll see it actually does work in private browsing.

What actually happens is we dynamically generate opensearch.xml to include your currently active session token. So what gets installed is actually from an XML file that looks more like this:

<Url rel="results" type="text/html" template="https://kagi.com/search?q={searchTerms}&token=<SESSION TOKEN HERE>"/>

And now it works in private browsing too, like magic - with two caveats:

• That session token isn't invalidated. If that happens, you'd have to remove and re-add Kagi as your engine again.
• It places the token in the URL. As you observe, we do a redirect to scrub it.

Given the limitations of opensearch.xml, this was deemed as acceptable tradeoff to remove the friction of people trying to use Kagi in private browsing - instead of getting hit with a login screen.

---

OK, so you set Kagi as your default in Firefox using the native method, and now you heard about our extension and want to start using that. You install the extension, and it says you're good to go. What happens now?

Now you have BOTH mechanisms working at the same time.

• From the native search engine config, it has the token in the search URL.
• The extension is sending the header.

If you already had Kagi configured via the "native" method, the extension won't (can't? don't know) overwrite the search engine config.

I did a simple test; if I completely remove Kagi from FF's search engines, and ONLY install the extension, then it works in the desire-able manner, only using the header, zero redirects.

---

So, what can we as extension authors do in this situation?

• Can DNR also remove the token param? This would be ideal. (I'm personally unfamiliar with the details of extension APIs)
• Are user's stuck with the clumsy process of having to unintstall Kagi first before installing the extension? Or, at least perform a relog to invalidate the session ID? The redirect would still happen, but at least the token value would be useless. Sadly, FF doesn't let you just edit the dang thing to remove it, like you can on Chrome etc.
• We could rework the "session link" mechanism altogether in some way, but note that we already have a massive population of users using it (probably almost all FF users, at the least).

---

More I could say, but hopefully that is enlightening. Thanks for raising the issue again, and would be happy if we could find an improvement.

[MrSarno]

Are user's stuck with the clumsy process of having to unintstall Kagi first before installing the extension?

I’m not OP and I’ve just read your (very thorough & informative!) comment now, so I’m not yet sure how I feel - but out of interest, do you think you as a team would be open to the idea of explicitly mentioning this on Kagi’s sign in page?

I feel like as a one-off inconvenience, it’s maybe acceptable - provided users are informed so they know what to do.

[z64]

@MrSarno If we can't simply fix it via the extension API (or another way), then yes we can certainly consider some form of explicit communication to users, in either the extension UI or otherwise. Definitely preferred to explore all avenues of automatic solutions that don't require any user intervention or extra documentation, etc.

[raxod502]

Wow, that is an amazing response! Thank you so much! You're exactly right that this is just due to legacy holdover configuration from before I was using the addon, and now that I disabled the addon, removed both copies of the Kagi search engine entry from Firefox, and re-enabled the addon (+ opened it on a Kagi page), it is working exactly as intended. Beautiful.

[z64]

I talked with our engineer @fvirdia who implemented our Privacy Pass extension who more or less ran into this exact same problem - FF users with token searches, breaking the anonymity pact - and we implemented a workaround there that we think should work for this too.

We'll look into that further, but if anyone reading the above has other suggestions, we're all ears! We weren't 100% happy with the workaround we did either, skirting around limitations in the DNR API...

[cyb3rko]

A temporary workaround is just prepending a long string in the URL so the token is pushed out of the URL bar.

If anybody's interested, I wrote a small post about it:
https://bsky.app/profile/cyb3rko.de/post/3m46ic4gfrk2z

[raxod502]

But... why not simply install the latest version of the addon, which doesn't have this problem? As mentioned in #95 (comment)?

[cyb3rko]

But... why not simply install the latest version of the addon, which doesn't have this problem? As mentioned in #95 (comment)?

Because some people (me included) can not simply install extensions in their browser on corporate laptops for security reasons.

And some other people don't want to install extensions for everything, especially if you care about your fingerprint.