The math, not the marketing.
Privacy claims are only as good as the cryptography behind them. Here's exactly how Makro encrypts your macros, what our servers can and can't see, the attacks we've designed for, and the evidence we publish. Every parameter is listed. Every edge case is named.
What actually runs, when you save a macro.
Every macro gets its own IV, its own ciphertext, its own authentication tag. The device key is non-extractable - even with full access to the browser profile, an attacker can't pull it out as raw bytes. Here are the parameters, byte-for-byte.
crypto.getRandomValues(Uint8Array(32))crypto.getRandomValues{id, confirmBeforeExpand, copyToClipboard} · these unencrypted fields are bound into the auth tag so tampering or cross-record ciphertext swaps fail decryptionWhat you see. What we see.
Your macros exist in readable form only on your devices. Before they touch our sync infrastructure, they're encrypted with a key we don't have. Our servers store blobs that would take cosmological timescales to brute force.
How Makro differs, by default.
Most competitors encrypt on their servers and hold the keys. We encrypt on your device and don't. Here's how the standard text expanders stack up on the security questions that actually matter.
What happens when things go wrong.
Every threat model lives or dies by specificity. Here are four realistic compromise scenarios and what Makro's architecture does in each one. Spoiler: your macros stay unreadable in all four.
Your laptop gets stolen.
chrome.storage.local alongside the ciphertext, so at-rest encryption protects against raw disk-level access to browser LevelDB files, other extensions reading the storage partition, and casual inspection of storage exports. It does not protect against an attacker with direct runtime access to this extension's storage (same-user malware or an unlocked browser). True zero-knowledge at rest would require a passphrase on every browser startup, which we do not currently require. Cloud sync is a different story and is zero-knowledge - see threat 02.Our servers get breached.
A government comes knocking.
Someone intercepts your sync traffic.
Every permission, one purpose.
Makro declares the permissions below in its Chrome and Firefox manifests. Each has a specific job. Every permission and host, with its purpose, is itemized in the privacy policy; the ones users actually notice are detailed here.
tabs permission.rules.json), which rewrite the Origin header on requests to a local Ollama server, one for localhost:11434 and one for 127.0.0.1:11434, so Ollama's CORS check accepts them. offscreen runs the screenshot-OCR pipeline in a sandboxed document, Chrome only, no network.Every feature ships with an audit.
Security reviews aren't quarterly; they happen inside the development cycle. Before anything reaches production, it passes through a multi-layer review process - automated tests, AI-assisted code review from an independent model, and human sign-off on encryption-touching changes.
A chain of security scans, not one tool.
Security scanning runs at three levels: automated gates on every change, additional scanners as part of our review discipline, and policy commitments that kick in for substantial changes. The categories below are labelled so you can tell what's machine-enforced versus what's run as team practice.
Automated checks on every pull request. Our CI pipeline runs static analysis with a security-focused lint ruleset, a full unit-test suite, an extension-store linter, a clean release build, and a version-sync check across the extension manifests. Failures are visible on the PR and are resolved before merge.
Review-time scanner chain. On top of CI, our review workflow runs secrets scanning, dependency vulnerability checks, SQL-safety audits across database queries, and locale-parity checks across all seven supported languages. A behavioural regression suite revisits previously-fixed classes of bug before every release.
Substantial-change policy. Larger diffs get a second independent audit pass in addition to everything above. This is a policy commitment, not an automated build step; we keep it deliberately small on purpose so the reviewer has room to look at design, not only syntax.
READ ARCHITECTURE DOCUMENTWhat we do collect, stated plainly.
Here is every field the install ping and the weekly heartbeat send. No macro content, no AI prompts or responses, no browsing history. The extension has two analytics toggles in Settings and both default to off. With them off the weekly heartbeat still sends a small anonymous base payload, listed below; the toggles control everything beyond it.
navigator.userAgentData.platform · e.g. "macOS"analyticsBasicEnabled is on; a default install sends no device identifier at all
This is the only telemetry that is not opt-in. It fires once, on chrome.runtime.onInstalled with reason "install". It does not fire on update. Uninstalling is the only way to prevent it. (An internal isDev flag is also attached; it is always false for builds shipped from the Chrome Web Store or Firefox AMO and is only used to exclude our own development installs from aggregate counts.)
Default: both toggles off, anonymous base payload only. The heartbeat always sends the five base fields below. They carry no device identifier and no usage data, so they cannot be tied back to you. Everything past that is additive and gated on the two toggles. On Firefox this base payload is governed by the browser's own technical-data consent instead of an in-product toggle: Firefox 140 and later show that choice at install and declining it stops the heartbeat entirely, while on Firefox 128 to 139, which predates the prompt, Makro cannot confirm a choice was offered and does not send it at all.
settings.tier; never contains the license key itselfanalyticsBasicEnabled is on. Without it the base payload has no device identifier, so weekly actives are counted by heartbeat volume alonenavigator.userAgentData.brands[0].brand · e.g. "Chrome"moment:<key> entries recording which free-tier click opened an upgrade panel, repeated once per occurrence and capped at 50 per key and 150 overall, so it does encode counts. No timing, no macro-level data
Two event shapes share this endpoint. Every request includes name and page; the data object differs by event type.
.cta-btn, .nav-cta, [data-event])data-event attribute, its exact value becomes the event name. Otherwise the name is derived from the href: contains "chromewebstore.google.com" yields cws_click, contains "addons.mozilla.org" yields amo_click, anything else yields cta_click. The data-event attribute also serves as a way to opt a non-CTA element into tracking.<form>)data-eventaction attribute; falls back to the current pathname if the form does not set one. No form field values, no names, no file content are included.That is the complete list of endpoints the extension and the website call with any user-adjacent data. No pixels, no third-party analytics SDKs, no session replay. AI usage metadata (token counts, endpoint, model, cost) is retained for up to 90 days for billing; install and heartbeat aggregates are retained for cohort analysis.
What Makro never does.
Trust is often built as much by the things a product refuses to do as by what it chooses to build. Each item is either technically impossible given our design, or an active operational commitment.