Add incognito mode for Search Assistant to allow use on confidential content

httpjames

It's important that Kagi is mindful of user data privacy when they are using Search Assistant with confidential documents, intellectual property or generally sensitive questions. Currently, it saves thread data associated with the user for authentication for 7 days, however, this is not enough for the above usecases.

In order for Search Assistant to stay compliant, there should be an "Incognito Mode" toggle, similar to how you can disable chat history on ChatGPT.

ChatGPT's "disable history" feature will disable visible history in the dashboard and exempt it from training data, but it will still keep the thread alive for 30 days for "abuse" monitoring. Search Assistant can do better.

I propose the following when the user enables Incognito Mode in Search Assistant:

Decrease the thread TTL to 1 hour or shorter AFTER the last message. Reset this timer every time the thread is modified.
Instead of associating the thread with the user, remove this association in the database by replacing it with bogus or a null value.
Modify authentication for incognito threads to accept the thread ID as a token to prove that they are the intended user. Don't allow receiving history for this thread (this can probably be stored in cookies with a TTL to allow refresh persistence). Only permit appending messages to the chat.
Increase the complexity and length of the thread ID to account for the fact that it will be the method of authentication.

By implementing the above, you will accomplish a much more private experience for sensitive queries because you will not have the information of which thread belongs to who, and since the TTL is much shorter, the user will be able to continue the conversation in a reasonable timeframe without leaving a long lasting trail in Kagi's database.

z64

httpjames

Modify authentication for incognito threads to accept the thread ID as a token to prove that they are the intended user. Don't allow receiving history for this thread (this can probably be stored in cookies with a TTL to allow refresh persistence). Only permit appending messages to the chat.

Could you clarify this a bit more? What I think you mean is preventing someone else from loading the thread history, even if they have a thread URL that you created. Because otherwise, there would be no point in loading a thread with no history.

Due to the complexity of assistant features, the entirety of thread data cannot be transferred with cookies. The size limitations make this impossible (4KB). Using i.e. localstorage would work, however this would lock the "incognito" feature to requiring JavaScript, among other downsides.

Assuming I have all the above correct, then there are other ways we can prevent unintended loading/leaking of threads, for instance having a separate "thread session" signature in cookies that we verify - something along those lines - that would tether the thread to only being readable by the current browser session, impossible for anyone else to read.

Vlad

httpjames I really like this idea.

I think we can go a step further and do not store the thread in the DB at all. The entire thread could be preserved in the browser session, say local storage. The thread would not have a special TTL and would be destroyed automatically on session/tab close.

This gets bit trickier with any uploaded docs, which we could also store in storage but reuploading every time is a bit tedious. Thoughts?

Finally does it not worry you sending content to anthropic/openai? I think ideall we would have open source models running on kagi infra that we can send this to. Main issue is that most of them are not very good.

Would really appreciate more feedback about this, very excited about potential.

z64

Currently, it saves thread data associated with the user for authentication for 7 days, however, this is not enough for the above usecases.

This is only for the purposes of the closed beta to give devs time to review buggy threads. The plan was to reduce this to 24 hours upon wide release.

(Your points are valid things for us to consider, just clarifying our intent with the TTL)

httpjames

z64 I did not take the cookie size limit into consideration. Creating a separate authentication cookie to load up chat history is a good replacement idea.

httpjames

Vlad Storing it in local storage is not a good idea for you guys. It would pretty much make you guys blind to abuse because there wouldn't be a "source of truth" for chat history. For example, I can start an incognito session and exploit the API to send whatever fake chat history I want.

Anthropic and OpenAI do not worry me. I trust them to handle and properly delete the data according to their retention policies. However, it would be nice to see a self-hosted Falcon-70B or 130B model to minimize the amount of control Anthropic and OpenAI have over "acceptable" uses and submitted data.

gp

Vlad Finally does it not worry you sending content to anthropic/openai? I think ideall we would have open source models running on kagi infra that we can send this to. Main issue is that most of them are not very good.

Perhaps it would be useful (more generally than just in an incognito mode) to show users visually where their query and associated context will go to? That would seem to fit in with the wider privacy-first mindset of Kagi.

I think people should be concerened by uploading content to third parties - not necessarily due to not trusting them, but because very often these documents will be confidential due to commercial sensitivity, where end users shouldn't be making that decision. Obviously if someone uploads work files to a service, that's on them... But it might be useful to consider ways to make users more aware when AI tools are used, where that information goes, so they can make an informed choice?

(And once there are local models on Kagi infra, that would help give a lightweight selling point in being pro-privacy)

Vlad

httpjames

It would pretty much make you guys blind to abuse because there wouldn't be a "source of truth" for chat history. For example, I can start an incognito session and exploit the API to send whatever fake chat history I want.

Not sure how is this an abuse vector?

RGBCube

httpjames I don't think making the AI "say" unhinged things by editing the response would be abuse. AI can't be held responsible at all and as the history is in the local storage in incognito sessions it would be obvious that the user did it.

z64

@Vlad

The entire thread could be preserved in the browser session, say local storage.

Besides the bandwidth problem, it would make the incognito mode require JS, which is kind of weird.

httpjames

z64 You'd also complicate the entire assistant infrastructure. The proposal above should make it a lot easier to maintain.

vicky

@Vlad Would it also be possible for Kali to check and automatically anonymize any user input in the prompt, such as an accidentally entered credit card number or an API key while pasting code?

Vlad

There a lot of things that can be done we need to ask the question what is the expectation. Chrome's Incognito mode is widely successful although it arguably does very little (but it is all users want it to do!).

So we are looking for an analogue of that for use with the Assistant.

httpjames

Vlad

Here's some wording I came up with. Inspired by Brave's private window disclaimer:

Vlad

Love it, thanks for taking time to incorporate that.

whs

I think E2E encryption could solve the thread-user association problem, but it would require JS. It could be that the user have to pick either E2E or no JS but not both.

User enter a search query
Client side JS generate a session keypair and send the public key along with the request.
Server create a thread ID and store the associated session public key
Client redirect to https://kagi.com/assistant?thread=threadid#sk=xxxx . Browser do not send the part after # to the server.
On any response, server encrypt the response to the session public key and store the encrypted response
Client side JS decrypt the server response

This would no longer require the thread ID to be associated to a user account and anyone can ask for any thread (that has an associated public key), but they cannot decrypt the content without the private key. Some metadata length is still leaked, however. such as the length and number of messages.

And this would still require some trust on the server which cannot be verified.

That the JS code is not silently changed to add backdoors
That the server do not store the plaintext response
That the server do not associate user ID with thread ID

Vlad

Done, Assistant is incognito by default.