GLDoze.
Privacy & Security

Your System. Your Privacy. Your Rules.

GLDoze is built around performance, transparency, and user control. We believe your computer should serve you without unnecessary background activity, concealed surveillance, or hidden access mechanisms. This page states what the project commits to, what has actually been verified, and what remains open — without claims we cannot back up.

The Five Commitments

Official GLDoze development commitments, each backed by engineering practice rather than marketing language.

NO BLOAT

Designed to avoid unnecessary components, background services, and resource consumption. Background services, timers and polling loops are inventoried and classified as essential, optional or candidate-for-optimization.

NO SPYWARE

No intentional secret monitoring of users or concealed collection of their personal activity.

NO TELEMETRY

No hidden usage analytics or undisclosed reporting of personal system information to GLDoze developers. This website carries no analytics, trackers or third-party scripts either.

NO BACKDOORS

No intentionally concealed mechanisms designed to bypass security protections or grant unauthorized access. Privileged operations require explicit administrator authentication, documented per operation.

NO UNIVERSAL MASTER PASSWORDS

No secret universal developer credential for unlocking users' protected vaults or encrypted data. Vault keys are derived from the user's own credentials only.

Changing a commitment is a documented process in the project's SECURITY.md, not a silent wording edit.

What Counts as Telemetry — and What GLDoze Does

Telemetry means usage analytics, behavioural data or personal system information transmitted to developers without the user asking. Loading a website you typed is not telemetry. Requesting an answer from a remote AI provider you configured is your directed activity — it still requires transparency, which is what this page provides.

No hidden collection, verified by inspection

A full audit of the application, installer scripts and this website found no first-party telemetry, analytics, tracking pixels or third-party tracking scripts. The embedded browser's background services that could report usage (component updater, network-time, usage-metrics reporting, domain reliability, background networking) are explicitly disabled on the browser's startup configuration, with a regression test guarding those settings. An automated no-telemetry scan runs with the project's test suite.

Honest limitation: absence of findings in an audit is not proof that no network activity can ever occur. The audit method, every inventoried connection and its purpose are published in the repository's network activity inventory.

Updates and External Connections

What connects out, when, and who decides.

Installation and updates

The bootstrap script downloads from this site over HTTPS and verifies a GPG signature against a pinned fingerprint before anything is installed. Nothing checks in silently in the background.

User-directed traffic

SSH/rsync to hosts you configure, websites you open in the integrated browser, mail you fetch, and media add-ons you enable connect only when you use them. These are inventoried per component.

GLDoze-initiated traffic

Beyond the explicit install/update download, the audit found no built-in reporting to GLDoze developers. Browser background reporting services are switched off and pinned by tests.

Local AI and Remote AI Are Different

A local model alone does not guarantee an offline application — so the boundary is stated explicitly.

Local inference stays local

The local model server listens on loopback only. Vision (image) requests are hard-routed to local workers by default and fail with a clear error instead of silently going remote.

Remote only if you configure it

Remote providers exist only when you add one yourself, with your own API key stored in credential storage — never in logs or settings files. Chat can use a configured provider; a hard "local only" switch disables even that.

You can always see where it went

Chat displays the provider and model, and labels remote providers plainly. Cross-provider fallback without disclosure was found in the audit, fixed, and is now covered by tests.

How Sensitive Credentials Are Handled

Stored per user, protected by your own secrets, never written to logs.

Credential storage

Passwords, SSH secrets and API keys live in the per-user keyring daemon (or the system secret service, if you prefer) — encrypted at rest with modern AEAD and a memory-hard KDF, reachable only inside your session.

Clipboard and logs

Copies are conditionally cleared after a timeout you configure — and we say plainly that a desktop clipboard manager may still retain them. Secrets are wiped from memory on every exit path and never appear in status text or logs.

Passing secrets to tools

SSH and mail integrations receive secrets through scoped local channels; automated tests scan source for credential-shaped strings and for secrets leaking into log statements.

GLVault: Security and Recovery Model

The password manager's guarantees — and their honest limits.

  • Explicit unlock only. The vault opens through its own password gate; there is no automatic unlock, silent decryption or secondary bypass.
  • Envelope encryption. Exports use a random data key that is wrapped by your passphrase (memory-hard KDF) and, only if you opt in, by a per-file recovery key shown exactly once.
  • Recovery is yours, or it is gone. Anyone holding a valid recovery key can open that export — store it separately. GLDoze cannot retrieve a lost key: lose both the passphrase and the recovery key and the export is unrecoverable, by design.
  • No developer back door. No shared developer password or master key exists that could unlock your vault — the audit searched the code and its history for universal credentials.
  • Legacy files stay readable and are never rewritten on open; upgrading to the new format is an explicit re-export you control.
  • Plaintext export is deliberate, warned about, and never the default.

Details, threat model and the specialist-review checklist: GLVault architecture notes and the GLVault security model.

Legitimate Privilege vs. Concealed Access

Root access exists — always explicit, always yours to approve.

Some operations genuinely require administrator rights (installing, service control, protected files). GLDoze routes them through the system's polkit mechanism: every privileged action demands administrator authentication — never your own account's password as a stand-in — with the scope shown before you approve. A dedicated root helper speaks a fixed, validated request protocol over a local-only socket and re-checks identity and policy on every call.

The distinction this project holds itself to: a legitimate privileged helper has a documented purpose, an explicit authorization requirement and a stated boundary. A backdoor would be an undocumented way around one. An independent-style review of every authentication and privilege surface found two real defects (an over-broad grant and a shared default room key), both fixed with regression tests pinning them: authentication & privilege review.

Open Source, Open Process

Everything on this page is checkable.

Public repository

Source, issues and development happen in public on the project's own Forgejo. The audit documentation — baseline, network inventory, minimal-system design, privilege review, vault model, AI data flows — lives in the repository next to the code it describes.

Continuous checks

Anti-regression guards for polkit grants, telemetry patterns, secret leakage, documentation integrity and vault/recovery behaviour run with the test suite, so the commitments degrade loudly instead of silently.

Documented decisions

Security-sensitive choices are recorded in the repository's security documentation, with a defined process for changing the five commitments.

Reporting a Vulnerability

How to reach the project, and what to expect.

Open an issue on the public tracker at git.gldoze.de/gldoze/desktop for problems that are safe to discuss openly, including privacy regressions and hardening gaps. Include what you did, what you expected, what happened, and the version or commit you tested.

For reports that should not be public, write to security@gldoze.de. Mail lands in a local mailbox on the project's own server (the same host that runs the Forgejo and this domain's DNS) — no third-party mail service is involved. Transport uses opportunistic STARTTLS; no response time is promised, same as the tracker. The full policy, including triage order and what reports can reasonably expect (without response-time promises we could not keep), is in SECURITY.md.

Current Verification Status and Known Limitations

Internal engineering assessments — not independent certification. No security audit by a third party, no certification, and no claim of perfect security or zero vulnerabilities is made.

  • NO BLOAT — partially verified. Background services inventoried and measured; the main idle render loop remains a measured, documented optimization candidate.
  • NO SPYWARE — verified within defined scope. No collection or transmission mechanisms found in code or site, within the limits of a static-plus-snapshot audit.
  • NO TELEMETRY — verified within defined scope. No analytics anywhere; browser background reporting disabled and test-pinned; automated scan guards regressions.
  • NO BACKDOORS — partially verified. One over-broad privilege grant and one shared default key found and fixed; two residual items (helper caller ACLs, an authentication test-hook hardening step) remain open and documented.
  • NO UNIVERSAL MASTER PASSWORDS — verified within defined scope. No universal credential exists in the codebase; recovery mechanisms are user-held and separately documented.

Open items we do not hide:

  • A legacy application password remains stored in plaintext until its credential-store migration lands.
  • The vault password gate has no attempt throttling or strength floor yet.
  • Two embedded-browser background requests await confirmation on the next browser restart.
  • One legacy application still fetches over cleartext HTTP internally; its transport fix is queued.
  • No software bill of materials or dependency-CVE scanning exists yet; upstream browser advisories must be tracked manually.

Full evidence, methodology and limitations: docs/security/ in the source repository.