Privacy Policy

Open Headers is committed to protecting your privacy and ensuring transparency about how our software operates. This Privacy Policy explains our data practices for the Open Headers browser extension and companion app.

1. Overview

Open Headers consists of:

• A browser extension for managing HTTP headers (available for Chrome, Firefox, Edge, and Safari)
• An optional companion desktop application for accessing local system resources

Every network call the software can make is publicly documented byte-for-byte in our wire-transparency documentation, so our privacy claims can be verified from the outside — with browser DevTools or a system-level packet capture — without trusting us.

2. Information collection and use

What we collect

We do not collect:

• Personal information or account identity
• Browsing history
• URLs, hostnames, header names, or header values
• Request or response data
• Rule contents, configurations, or any data from your computer

The only data that ever reaches us is the anonymous usage counting described in section 3 — which features get used, never what you use them on.

Local storage only:

• Your header configurations are stored locally in your browser using the browser’s storage API
• Dynamic header sources accessed through the companion app remain on your local device
• Your configurations and data are never transmitted to our servers or third parties

How information is used

All configuration data is used solely for the functioning of the extension and remains on your device. We have no access to this information.

3. Anonymous usage counting (telemetry)

The browser extension, the desktop app, and the command-line tool count which features get used — nothing more. This helps us understand what to improve, and it is designed so that it cannot carry your data:

• A fixed event vocabulary, compiled into the app. Only seven event types exist (first run, session start, feature used, rule created, import run, workflow run, error code), and every field in them comes from a fixed list — feature names, platform (such as mac/win/linux), browser, app version, interface language, distribution channel (which store the app was installed from), and coarse size buckets (such as “1–5 rules” — never exact counts). Free-form text is structurally impossible, so URLs, headers, request or response data, rule contents, and file paths cannot appear in an event.
• Anonymous, with an identifier you control. Events carry a random session id minted when the app starts (held in memory only, never saved) and a random install identifier that groups counts from the same installation — it is generated by a coin flip, never derived from your device, network, or any account, so it identifies the install, not you. Turning usage counting off (Settings → General) deletes it — a later re-enable starts with a fresh identifier that cannot be linked to the old one, so the switch doubles as a reset. There is no account, no fingerprinting, and IP addresses are not stored; our server records only the coarse two-letter country code its infrastructure resolves at the network edge, plus how old the install is in broad buckets (days “2–7”, never exact).
• Inspectable, byte for byte. Settings → General → “View telemetry events” shows every event of your current session exactly as sent (or as suppressed, when the channel is off). The exact wire payload is also published in our wire-transparency documentation.
• Disclosed, and off with one switch. Usage counting is disclosed here, in the store listings, and in the setting itself. The extension and desktop app have a single toggle in Settings → General; the command-line tool honors OH_TELEMETRY=0 or a config key. Off means off — the channel goes completely silent, the install identifier is deleted, and every feature keeps working. When the extension is uninstalled, the browser opens our site once so we can count the departure; that request carries only the random install identifier.
• Hard-off on server surfaces. The daemon, the self-hosted web app it serves, and the MCP server never send telemetry and contain no code path to do so.

4. Data sharing and transfer

We do not share or sell any data. Anonymous usage counts are received and stored in our own Cloudflare account (Cloudflare is our infrastructure provider and the only data processor involved); no third-party analytics service or SDK is used, and nothing else is collected in the first place.

5. Local communication

The browser extension and companion app communicate locally via WebSocket on port 59210. This connection:

• Is limited to localhost (127.0.0.1)
• Does not transmit data over the internet
• Requires explicit user action to enable
• Uses a simple JSON-based protocol for requesting and receiving header values

6. Permissions

The extension requires certain permissions to function:

• storage: To save your header configurations
• alarms: For scheduling header updates
• scripting: To initialize extension functionality
• declarativeNetRequest: To modify HTTP headers
• host_permissions (<all_urls>): To modify headers for your specified domains

These permissions are used solely for the extension’s core header modification functionality and not for collecting information.

7. Security

We prioritize security through:

• Local-only data storage
• No external network connections beyond documented endpoints (license renewal, update checks, notification manifests, anonymous usage counting) and destinations you configure yourself
• Publicly documented wire behavior that anyone can verify with a packet capture
• Regular security updates and a published vulnerability disclosure policy

8. Children’s privacy

Open Headers is a developer tool and not intended for use by children under 13 years of age.

9. Changes to this policy

We may update this Privacy Policy from time to time. We will notify users of any changes by updating the “Effective Date” at the top of this policy.

10. Transparency commitment

Open Headers is proprietary software with a verifiable privacy posture. We publish:

• A wire-transparency specification documenting the exact payload of every network call the software can make — including every telemetry event
• A security whitepaper describing the architecture behind these guarantees
• A vulnerability disclosure policy

Because the software’s outbound behavior is fully documented, you can verify our privacy claims yourself with browser DevTools or a system-level packet capture — no source access or trust in us required.

11. Contact information

If you have questions about this Privacy Policy or the Open Headers project, please:

• Create an issue at github.com/OpenHeaders/open-headers
• Email us at contact [at] openheaders.io

We welcome feedback on both our software and our policies.

12. Consent

By using Open Headers, you consent to this Privacy Policy. As we do not collect any personal information, there is no personal data to manage or delete; anonymous usage counting can be switched off at any time in the app.

This Privacy Policy is provided to meet browser extension store requirements and to be transparent about our commitment to privacy and data security.