Extension Privacy and Permissions
What the Umia Extension can access, what a verification reveals, and what you can check yourself
This page sets out what the Umia Extension can access, what each verification reads and reveals, who can see what, and how to check that the extension you installed is the one we published. Where something rests on trusting Umia rather than on the cryptography, it says so.
At a glance
| Site access at install | None. Chrome shows no "read and change your data" warning. |
| Who can start a verification | Only app.umia.finance. |
| Site access during a verification | The exact site the criterion reads, such as github.com, and nothing else. You approve it each time. |
| After a verification | Site access is removed automatically, whether the proof succeeded, failed or was cancelled. |
| Code from Umia's servers on that site | None. The extension runs no scripts supplied by a server. |
| What reaches Umia | The proof, plus fixed progress events. No page content, URLs or cookies. |
| What goes onchain when you bid | Your wallet, the criterion you proved, and a pseudonym for your account. |
Site access
- Install. The extension asks for no site access. It cannot read any page until you grant it.
- Enable on Umia. The first time you verify, the Umia app asks you to enable the extension for
app.umia.financeand Umia's API. This lets the Umia app start verifications. No other website can talk to the extension. - Verify. When you start a verification, Chrome asks for access to the one site the criterion reads, for example
github.com. Never a whole domain: approvingdevelopers.google.comwould not give access to Gmail. You can decline. - Finish. When the verification ends, for any reason, the extension removes that site's access. The next verification asks again. An update or browser restart also clears any access left over.
You can check and remove access at any time: open chrome://extensions, choose Details on Umia, and look under Site access.
During a verification the extension loads the page being proven in a tab, signed in as you, using your existing session on that site. Your password is never involved, and your session cookies are never sent to Umia.
What each criterion reads
Each criterion is a recipe: the page to load, what to match on it, and what to reveal. For example:
| Criterion | What it loads | What the proof reveals |
|---|---|---|
| GitHub contributor | Your own GitHub pull request search, scoped to the project and period the auction names | That you have at least one merged pull request there, and your GitHub account ID as a pseudonym |
| GitHub maintainer | A search of your own public repositories | That you own a public repository with at least the required stars, and your GitHub account ID as a pseudonym |
| Echo investor | Your Echo portfolio page | That you have put a nonzero amount into Echo rounds, not how much, and your Echo account email as a pseudonym |
| fomo clan | Your fomo account and profile | Which of the listed clans you belong to, and your fomo account ID as a pseudonym |
| fomo hold time | Your fomo account and profile | Your average hold time, which must be above the threshold, and your fomo account ID as a pseudonym |
Umia's attestor also sees the text it checks, such as the amount in your Echo portfolio. Only the criterion and the pseudonym go onchain.
Every recipe is published in full with each extension release (see Checking your install). The live registry lists the digest of every recipe it can serve, at /api/v1/zktls-registry/providers, so anyone can match what is live to what was published.
Who can see what
| Party | What it sees |
|---|---|
| You | Everything, in your own browser. |
| The site you verify on | A normal visit to that page by your account. |
| Umia's attestor | The site's hostname, the timing and size of the encrypted connection, and the parts of the response the proof reveals, including your account ID before it becomes a pseudonym. Never your password or session cookies. |
| Umia's API | The finished proof: your wallet, the criterion and the pseudonym. Plus the progress events above. |
| Everyone, onchain | When you bid with a proof: your wallet, the criterion and the pseudonym. |
The criterion itself is public
Anyone can see which criterion a bidding wallet proved. For a narrow criterion, such as contributing to one small project in one quarter, that alone narrows down who the wallet might belong to, even though the account is only a pseudonym.
Can Umia link your account to your wallet?
Today it could, and two things rest on trusting us not to:
- The attestor sees your account ID. Pseudonyms are currently computed on the attestor (Reclaim's
oprf-rawmode), so it receives your account ID in the clear before hashing it. We do not log or keep it, but you cannot verify that yet: the attestor does not run as a publicly verifiable build. - Umia holds the pseudonym key. A pseudonym is a keyed hash of your account ID. The attestor holds the key it uses, and a copy is kept offline for recovery. Whoever holds the key can recompute the pseudonym for a known account and find its wallet onchain. We use the offline copy only to recover the attestor.
The public can do neither: without the key, a pseudonym reveals nothing about the account behind it.
We plan to remove both assumptions:
- Blind the account ID in your browser. With Reclaim's client-side OPRF, the extension proves the account ID in zero knowledge and the attestor computes the pseudonym without ever seeing the ID.
- Remove the single key holder. Either run the attestor in a trusted execution environment with a published, reproducible build, so anyone can check the code that holds the key, or split the key with an independent operator, so no single party can compute pseudonyms alone.
No server code runs on the sites you verify
A recipe is data: a page, patterns to match and parts to reveal. The extension refuses any recipe that carries a script, and the registry refuses to save or serve one. What the extension does on a provider's site is fixed in the published extension code, not decided by a server at verification time.
Checking your install
Every version we publish to the Chrome Web Store is also published as an immutable release on umiafinance/extension. Once a release is published, GitHub prevents its tag and files from changing. Each release contains:
- the packaged extension, with an
artifact-manifest.jsonlisting every file's SHA-256 and the commit it was built from; zktls-recipes.json: every committed recipe, with its digest and the claim hashes an auction pins;SHA256SUMSfor the files above.
The release notes link the matching source on umiafinance/extension, which holds everything the build reads, including the SDK. Its README gives the commands to compare the extension Chrome installed with the release, and to rebuild the release yourself.
What this proves, and what it doesn't
You can check that the installed extension is exactly the published build, file for file. The one exception is the toolbar icons, which the Chrome Web Store re-encodes. You can also rebuild the release from source and get the same files. This covers the extension only, not Umia's attestor or API, which run on Umia's servers.
Audits
The extension and its SDK have not had an external audit yet. The zero-knowledge and attestation cryptography they use comes from the Reclaim Protocol.
Staying safe
- Install only from the Chrome Web Store listing. The extension ID is
ejcaahfcaaiblipldkfijdcbannidbdd. - Umia will never message you asking you to "verify now". Start verifications only from app.umia.finance.
- If you prefer, use a separate Chrome profile signed in only to the site you verify on.
- The extension is only needed for gated rounds. You can take part in public rounds without it.