[Feature Request] Add user analytics opt-out toggle in Settings

[Helweg]

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

Users currently have no control over analytics collection. PostHog initializes automatically on app launch and captures usage telemetry including navigation events, feature usage (model/provider selections, tool counts), and optionally work email addresses for users who registered as work users.

While we don't collect task inputs, prompts, or document contents, and we suppress IP capture, users still need a clear opt-out mechanism for privacy preferences and compliance requirements. I'm frustrated when applications don't provide transparent control over telemetry, especially when dealing with potentially sensitive AI workflows.

Checks

• I've searched the docs for a solution
• I've searched for existing Github issues

Describe the solution you'd like

Add a persistent analytics opt-out toggle in the Settings page (/settings) under a new "Privacy & Analytics" section that:

• Prevents PostHog initialization entirely when opted out (checked on app load via localStorage)
• Stops all event capture immediately when toggled off (no page reload required)
• Persists user preference across sessions using localStorage key kiln_ph_opt_out
• Never sends identification (email) or any events while opted out
• Re-enables analytics cleanly when toggled back on, calling posthog.opt_in_capturing()
• Includes clear privacy disclosure explaining what data is collected and when

UI requirements:

• Toggle switch component with clear on/off states
• Accessible (keyboard navigation, focus states, ARIA labels)
• Visual feedback on state change
• Explanatory text describing data collection scope (navigation, feature usage, no task content)

Technical implementation:

• New store: lib/stores/analytics.ts wrapping localStorage + PostHog opt_in/opt_out API
• Conditional PostHog init in routes/+layout.ts based on opt-out flag
• Guards around all posthog.capture() calls checking opt-out state
• New component: lib/ui/analytics_toggle.svelte

Acceptance criteria:

• Fresh opt-out prevents any request to analytics endpoint
• Toggling off stops event capture immediately without page reload
• No email/identification sent while opted out
• Re-enabling analytics resumes event capture correctly
• No console errors when PostHog is disabled
• Toggle is keyboard accessible (Tab, Space/Enter)
• Unit tests for analytics store logic
• E2E test verifying zero network activity when opted out
• Documentation updated in PRIVACY.md

Describe alternatives you've considered

1. Environment variable for disabling analytics - Not user-friendly for desktop app users who don't have easy access to environment configuration. Requires app restart.

2. Server-side preference storage - Would require user accounts and backend changes. Current privacy model is client-side only, which is simpler and more privacy-preserving.

3. Consent banner on first launch - Could be added in future as a progressive enhancement, but a settings toggle is more flexible for users who want to change their preference later.

4. Complete removal of analytics - Loses valuable product improvement insights. An opt-out preserves choice for both privacy-conscious users and product development needs.

Additional context

Current analytics scope (for transparency):

• Events captured: navigation ($pageview, $pageleave), feature usage (run_task, create_project, add_documents, connect_provider, etc.)
• Properties sent: model names, provider names, tool counts, sanitized URLs/routes
• PII: Only work email if user explicitly registered as work type and provided it
• Not captured: task inputs, prompts, document contents, raw URLs with query params
• Privacy measures: IP addresses suppressed via ip=0 parameter, autocapture disabled

Testing plan:

• Manual: DevTools Network tab → toggle off → navigate → confirm zero requests to https://ustat.getkiln.ai/i/v0/e/
• Unit: Analytics store initializes from localStorage, toggles state correctly, persists across instances
• E2E (Playwright): Automated scenario toggling off and navigating multiple routes, asserting no analytics network requests
• Accessibility: Keyboard-only navigation test, screen reader announcement verification

Related files:

• Analytics initialization: app/web_ui/src/routes/+layout.ts
• Analytics usage: app/web_ui/src/routes/(app)/+layout.svelte, app/web_ui/src/lib/utils/connect_ph.ts
• Settings page: app/web_ui/src/routes/(app)/settings/+page.svelte

[scosman]

We're trying to balance making sure Kiln is an awesome free product for individuals, and is also sustainable long term. That means for-profit companies using Kiln should contribute to its development (eventually).

Technically, we're a mix of true OSS/MIT code with zero analytics (the library, the OSS REST API), open formats (JSON you can read with our library or any other), and source-available code (the UI/app) which will have paid options for larger companies in the future. Analytics are only in the 3rd category.

Also important, even in the app: we never track prompts, model inputs, model outputs, project names, or other user-input strings. It's generalize analytics like "how many times did people use feature X / visit screen Y".

If a for-profit company needs a zero-analytics solution, we can definitely provide that! You can contact us to discuss details: https://kiln.tech/contact_sales

If anyone is doing not-for-profit work for a good cause and needs a no-analytics option, please reach out as well!

More details from Privacy Docs: https://docs.kiln.tech/docs/privacy

More context copied from the README:

The Kiln library with our core functionality is fully open source (MIT), while the Kiln desktop app is free to use, source-available, and may be licensed to enterprises in the future.

Why? We’re aiming to make Kiln fair and sustainable:

 - Kiln is always free for personal use.
 - Larger for-profit companies using Kiln Desktop may require a license in the future, but it is currently free.
 - This is based on the [fair code model](https://faircode.io/), with the goal of making Kiln sustainable.

Open Library and Data Format:
 - Kiln’s MIT OSS library contains all of the core logic of Kiln. It can do anything the app can do, just without the font-end/UI.
 - Kiln’s data format is open. You own and control your datasets, we don’t have access to them. The data is JSON formatted for maximal compatibility, ensuring zero lock-in.

Licenses

- Python Library (core logic/features): [MIT License](https://github.com/Kiln-AI/Kiln/blob/main/libs/core/LICENSE.txt)
- Python Server (REST API): [MIT License](https://github.com/Kiln-AI/Kiln/blob/main/libs/server/LICENSE.txt)
- Desktop App: free to download and use. 100% [source-available](https://github.com/Kiln-AI/Kiln/blob/main/app) with public builds for maximum transparency.