feat: privacy option where admins cannot easily see user data

[darkvertex]

Is your feature request related to a problem? Please describe.

Set up a shared instance of Open Web UI at work and employees are slightly uncomfortable with the idea that an admin can dump their personal conversations (even though it's "for work".)

Describe the solution you'd like
It'd be nice if conversations were more obfuscated or encrypted in some way that admins cannot easily dump all data when a sort of "private server mode" is enabled globally, and they can only reset user passwords or trash users, but not get to the convos.

[Lanhild]

@darkvertex That's a job for more roles. Currently there is admin and user.

What you're suggesting would need an additional role, or to completely remove the ability to download the database from the UI.

While I believe doing the latter would be a huge downgrade, it'd be the easiest as far as how I understand your point.

Now, your issue is not solvable as in the admin most certainly has access to the UI container anyway, which contains the database itself.

@tjbck I feel like this is a non-issue, what do you think?

[justinh-rahb]

To be honest, yes, this feels unreasonable to me. If you're using some service such as a chat or messenger app for work/school, you can expect that admins have access to that content and you'll have no say in it.

[tjbck]

let's move to discussion, it's definitely an interesting feature request to ponder on.

[fps-admin]

As corporate emails, chats should have some sort of protection or obfuscation imho. We sometime deal with organization that require to be GDPR compliant. Downloading the entire database seams like a nice dev feature but for operators it's maybe a bit too much. Maybe another role level could be the answer.

[Lanhild]

About the GDPR part, I'm not sure that "chats" specifically fall under this legislation

[fps-admin]

GDPR is only one of many corporate compliance rule. The end-users chat is one thing, the information they put in is another. In some cases I can imagine some users inputting data that is protected information (controlled source code, SSN, addresses, etc..). One of the key benefits of a self-hosted system is that information is kept under key instead up getting uploaded to [insert big AI company here].

[cheahjs]

I currently run this patch on my own fork to disable chat exports (forgot to disable DB exports as well): 49dcf68

The thing is, without E2E encryption, an admin with access to the underlying database where Open WebUI is hosted will always have access to a user's saved conversations. We can put roadblocks in place to make it less easy, like disabling the API endpoints for exporting chats, but without E2EE, users cannot guarantee that their conversations are private.

[justinh-rahb]

I can see both side of the coin I guess. While you might have organizations that would prefer or be required to limit information access even to admins, there will certainly be just as many that do not want users to be able to hide or self-remove content (permanently).

Making a system that can cater to both simultaneously would be a tall order, but perhaps it's easier to reason about if we stick to either/or for now: a toggle to either enable or disable E2EE. Disabled would essentially just be as the application functions now, enabled would add encryption and disable ability to dump the DB from the admin UI (since it'd be unreadable anyway).

[fps-admin]

One of the reasons for delegating admin access to non-super-admins is the management of user accounts. Onboarding end-users and reseting password is usually considered a level 1 support task. They usually don't get access to the full database of a system they do support for.
As for the encryption side of things, on premise hosting can be done on hardened systems with at-rest encryption and robust AAA in place and the transit to end-users can be done via HTTPS. The only key part missing would be at the database or field level. A key or salt could be provided to the application to access the sqlite stored data.

[tjbck]

One elegant solution might be adding an option to turn off chat history but still be able to save the chats locally like the earlier versions of Open WebUI.

[justinh-rahb]

I think I like where else that could go... this could bring back possibility of a build-flag system to produce the lite version again.

[Lanhild]

One elegant solution might be adding an option to turn off chat history but still be able to save the chats locally like the earlier versions of Open WebUI.

That'd be the safest bet, agreed

[justinh-rahb]

Just thought, there would be various frontend features that rely on backend chat storage that would need disabling as well, so it seems build arguments may be unavoidable.

[darkvertex]

I like this idea.

Could even be a toggle for some kind of extra-private "ephemeral mode" toggle in the chatbox that makes it not store the conversation messages serverside (nor permanently clientside) while this mode is ON...

In other words, if you enable it, have a brief conversation with an LLM, and close the tab, those messages would be gone and no admin would have been able to retrieve them because they were not stored to begin with in the first place.