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

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.

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.