github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-05 18:38:17 -05:00
Code Issues 1.1k Packages Projects Releases 126 Wiki Activity

[GH-ISSUE #21544] feat: Add option to disable or restrict "Analytics/Analyse" dashboard for GDPR compliance #58179

New Issue
Closed
opened 2026-05-05 22:28:44 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-05-05 22:28:44 -05:00
Owner
Copy Link

Originally created by @sct-hm on GitHub (Feb 17, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/21544

Check Existing Issues

  • I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.

Verify Feature Scope

  • I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.

Problem Description

Problem / Background

After upgrading to newer OpenWebUI versions (e.g. v0.8.3), the new Analytics (Analyse) feature provides a dashboard that shows all models and associated chats in one place.

In environments with multiple users and/or regulated requirements (e.g. EU), this is problematic from a GDPR / privacy-by-default perspective. Even if the page is intended to be admin-only, many organizations:

  • cannot allow any UI that aggregates or exposes cross-user chat metadata/content,
  • require a hard “off” switch (or strict scoping) for auditing/compliance reasons,
  • want to prevent accidental misconfiguration (e.g. someone being granted admin).

Actual behavior

Analytics dashboard is present and (from the UI) appears to aggregate and display model usage and related chats across the instance, which can conflict with GDPR/compliance expectations.

Why this matters (GDPR / compliance)

  • Data minimization & purpose limitation: analytics-style cross-user overviews may exceed the purpose users expect.
  • Least privilege: admin access is sometimes necessary for other tasks, but should not automatically imply access to all chat metadata/content.
  • Defense in depth: an explicit disable option reduces risk from misconfiguration.

Version

  • OpenWebUI: v0.8.3 (and likely later)
  • Deployment: (please advise what info you need; I can provide Docker/K8s details)

Additional context

If there is already a way to disable this feature (env var, config flag, permission), please document it clearly in the docs and release notes.

Thanks!

Desired Solution you'd like

Expected behavior

Provide a documented, explicit configuration to disable Analytics entirely and/or limit it to privacy-safe aggregates.

Requested options (any of the following would help)

  1. Hard disable switch

    • Environment variable, e.g. DISABLE_ANALYTICS=true or ENABLE_ANALYTICS=false
    • And/or admin setting in UI.
    • When disabled, remove/hide the Analytics navigation entry and block the backend routes.

  2. Scope Analytics by user / tenant

    • Ensure Analytics only shows data for the currently authenticated user unless a separate, explicit permission is granted.

  3. Aggregation-only mode

    • Allow showing only anonymized/aggregated metrics (no chat titles, no message excerpts, no user identifiers).

Alternatives Considered

No response

Additional Context

No response

Originally created by @sct-hm on GitHub (Feb 17, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/21544 ### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description ## Problem / Background After upgrading to newer OpenWebUI versions (e.g. v0.8.3), the new **Analytics (Analyse)** feature provides a dashboard that shows **all models and associated chats** in one place. In environments with multiple users and/or regulated requirements (e.g. EU), this is problematic from a **GDPR / privacy-by-default** perspective. Even if the page is intended to be admin-only, many organizations: - cannot allow any UI that aggregates or exposes cross-user chat metadata/content, - require a hard “off” switch (or strict scoping) for auditing/compliance reasons, - want to prevent accidental misconfiguration (e.g. someone being granted admin). - ## Actual behavior Analytics dashboard is present and (from the UI) appears to aggregate and display model usage and related chats across the instance, which can conflict with GDPR/compliance expectations. ## Why this matters (GDPR / compliance) - Data minimization & purpose limitation: analytics-style cross-user overviews may exceed the purpose users expect. - Least privilege: admin access is sometimes necessary for other tasks, but should not automatically imply access to all chat metadata/content. - Defense in depth: an explicit disable option reduces risk from misconfiguration. ## Version - OpenWebUI: v0.8.3 (and likely later) - Deployment: (please advise what info you need; I can provide Docker/K8s details) ## Additional context If there is already a way to disable this feature (env var, config flag, permission), please document it clearly in the docs and release notes. Thanks! ### Desired Solution you'd like ## Expected behavior Provide a **documented, explicit configuration** to disable Analytics entirely and/or limit it to privacy-safe aggregates. ### Requested options (any of the following would help) 1. **Hard disable switch** - Environment variable, e.g. `DISABLE_ANALYTICS=true` or `ENABLE_ANALYTICS=false` - And/or admin setting in UI. - When disabled, remove/hide the Analytics navigation entry and block the backend routes. 2. **Scope Analytics by user / tenant** - Ensure Analytics only shows data for the currently authenticated user unless a separate, explicit permission is granted. 3. **Aggregation-only mode** - Allow showing only anonymized/aggregated metrics (no chat titles, no message excerpts, no user identifiers). ### Alternatives Considered _No response_ ### Additional Context _No response_
GiteaMirror commented 2026-05-05 22:28:47 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Feb 17, 2026):

Could you clarify what exactly about the Analytics dashboard needs to be hidden, and what specific GDPR obligation you believe it triggers?

Looking at the arguments listed:

Why this matters (GDPR / compliance)
Data minimization & purpose limitation: analytics-style cross-user overviews may exceed the purpose users expect.
Least privilege: admin access is sometimes necessary for other tasks, but should not automatically imply access to all chat metadata/content.
Defense in depth: an explicit disable option reduces risk from misconfiguration.

Data minimization doesn't apply here. The data already exists. Open WebUI already logs it. From a legal standpoint, hiding the Analytics dashboard doesn't change anything. You are already processing the data, and are already under GDPR as-is. The dashboard itself doesn't change that.

And "Data minimization" doesn't fit for a couple of reasons:

  1. The analytics are very minimal. You basically only see which model was used how much and which user sent how many requests, and these metrics aren't even fully accurate, because if a user deletes a chat, the shown metrics also change.
  2. You already have all the data. Data minimization is about not collecting and processing data you don't need, so this argument of data minimization does not apply here at all. You already have the data either way (so the principle doesn't apply here), and finally
  3. having administrative oversight over very basic statistics is well within the rights of an admin under legitimate interest.

Least privilege is also not the right framing here. It is well established in the docs and our security guidelines that an admin can do absolutely everything. If you don't want the admin to see chats, turn off the env var that allows access to the user's chats. If you don't want the admin to be able to export the database, there's an env var for that too. Same for the BYPASS ADMIN ACCESS CONTROL env var for models, prompts, and knowledge bases. As an admin, you can already tinker with models, connections, RAG settings, export all configuration options, edit a user's password, see the user's email, profile picture, oauth, name, and their full profile.

To clarify what the Analytics dashboard actually shows: you do not get access to chat content, as claimed in your issue. And you don't get access to per-chat metadata either. It is aggregated metadata over all chats of a user, and separately, data over how much a model is being used across the instance. So there's no single-chat metadata, no chat content and for chat content access specifically, there's already an env var to disable that.

Defense in depth

Defense in depth: an explicit disable option reduces risk from misconfiguration.

It's not clear how adding a toggle to disable the Analytics dashboard, where nothing is configurable, lowers misconfiguration risk. And even if it did, defense in depth is about layered security controls, not about hiding a read-only analytics view.

As a side note: 2 out of the 3 reasons listed aren't actually GDPR-related arguments, least privilege and defense in depth are general security principles.

<!-- gh-comment-id:3917139212 --> @Classic298 commented on GitHub (Feb 17, 2026): Could you clarify what exactly about the Analytics dashboard needs to be hidden, and what specific GDPR obligation you believe it triggers? Looking at the arguments listed: > **Why this matters (GDPR / compliance)** > Data minimization & purpose limitation: analytics-style cross-user overviews may exceed the purpose users expect. > Least privilege: admin access is sometimes necessary for other tasks, but should not automatically imply access to all chat metadata/content. > Defense in depth: an explicit disable option reduces risk from misconfiguration. **Data minimization** doesn't apply here. The data already exists. Open WebUI already logs it. **From a legal standpoint, hiding the Analytics dashboard doesn't change anything**. You are already processing the data, and are already under GDPR as-is. The dashboard itself doesn't change that. And "Data minimization" doesn't fit for a couple of reasons: 1) The analytics are very minimal. You basically only see which model was used how much and which user sent how many requests, and these metrics aren't even fully accurate, because if a user deletes a chat, the shown metrics also change. 2) You already have all the data. <ins>**Data minimization is about not collecting and processing data you don't need**</ins>, so this argument of data minimization does not apply here at all. You already have the data either way (so the principle doesn't apply here), and finally 3) having administrative oversight over very basic statistics is well within the rights of an admin under legitimate interest. **Least privilege** is also not the right framing here. It is well established in the docs and our security guidelines that an admin can do absolutely everything. If you don't want the admin to see chats, [turn off the env var that allows access to the user's chats](https://docs.openwebui.com/reference/env-configuration#enable_admin_chat_access). If you don't want the admin to be able to export the database, [there's an env var for that too](https://docs.openwebui.com/reference/env-configuration#enable_admin_export). Same for the [BYPASS ADMIN ACCESS CONTROL env var](https://docs.openwebui.com/reference/env-configuration#bypass_admin_access_control) for models, prompts, and knowledge bases. As an admin, you can already tinker with models, connections, RAG settings, export all configuration options, edit a user's password, see the user's email, profile picture, oauth, name, and their full profile. To clarify what the Analytics dashboard actually shows: **you do not get access to chat content**, as claimed in your issue. **And you don't get access to per-chat metadata either**. It is aggregated metadata over all chats of a user, and separately, data over how much a model is being used across the instance. So there's no single-chat metadata, no chat content and **for chat content access specifically, there's already an env var to disable that.** **Defense in depth** > Defense in depth: an explicit disable option reduces risk from misconfiguration. It's not clear how adding a toggle to disable the Analytics dashboard, where nothing is configurable, lowers misconfiguration risk. **And even if it did, defense in depth is about layered security controls, not about hiding a read-only analytics view.** As a side note: 2 out of the 3 reasons listed aren't actually GDPR-related arguments, least privilege and defense in depth are general security principles.
GiteaMirror commented 2026-05-05 22:28:48 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Feb 17, 2026):

I'm genuinely curious if there's a concrete reason the dashboard needs to be hidden, because if there isn't, it would be preferable to avoid adding yet another configuration option for something that isn't required for neither security nor legal compliance.

The data is there either way.
Get it via the API endpoints - or - query it with a simple, single, small SQL query or have it be displayed in the admin panel. Legally, nothing changes. For security purposes - nothing changes as far as i can tell.

<!-- gh-comment-id:3917161290 --> @Classic298 commented on GitHub (Feb 17, 2026): I'm genuinely curious if there's a concrete reason the dashboard needs to be hidden, because if there isn't, it would be preferable to avoid adding yet another configuration option for something that isn't required for neither security nor legal compliance. The data is there either way. Get it via the API endpoints - or - query it with a simple, single, small SQL query or have it be displayed in the admin panel. Legally, nothing changes. For security purposes - nothing changes as far as i can tell.
GiteaMirror commented 2026-05-05 22:28:49 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Feb 17, 2026):

Requested options (any of the following would help)
Aggregation-only mode
Allow showing only anonymized/aggregated metrics (no chat titles, no message excerpts, no user identifiers).

This is already the case if you disabled https://docs.openwebui.com/reference/env-configuration#enable_admin_chat_access (which i assume you did?) - if this is disabled, no chats, no chat titles, no message excerpts, nothing of this is visible.

<!-- gh-comment-id:3917210100 --> @Classic298 commented on GitHub (Feb 17, 2026): > **Requested options (any of the following would help)** > Aggregation-only mode > Allow showing only anonymized/aggregated metrics (no chat titles, no message excerpts, no user identifiers). This is already the case if you disabled https://docs.openwebui.com/reference/env-configuration#enable_admin_chat_access (which i assume you did?) - if this is disabled, no chats, no chat titles, no message excerpts, nothing of this is visible.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#58179
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?