How sign-in works

The sign-in card shows 1 button per provider: Google, Apple, Microsoft, Twitch.

Click one and the provider's own sign-in window opens. You approve there, under the provider's rules and with the provider's password, which Emojery never sees. The window closes, the extension receives a short-lived code from the provider, and you are signed in. The whole exchange asks the provider for exactly 1 thing, the standard openid scope: no name, no email, no picture, no contact list. The request never includes them, so there is nothing to decline.

No password is created on Emojery's side. There is no password to forget, no reset flow, and no password database to leak.

One fact: that your account signed in to Emojery, and when. That is the same thing any "Continue with Google" button tells Google, and it is the price of a sign-in a public proof can be built on.

• Never which pages. The extension does not talk to the provider again until your session expires, 30 days later. What you react to, where, and with which emoji goes only to Emojery's server, and only as a public identifier of the item.
• Never your reactions. The provider is not on the path of a reaction at all. Sign in, and it is out of the loop.
• Nothing from Emojery back to it. Emojery sends the provider nothing about you after the sign-in, because there is no channel to send it on.

The provider hands back an opaque subject id: a string that means "this account" to the provider and nothing to anyone else. Emojery keeps a keyed hash of that id, plus the provider's name, and that is your account record. The key that produces the hash is held outside the database, so a stolen copy of the database yields no ids, and a guessed provider account cannot be tested against it.

Not stored, because never requested: your name, your email address, your picture, your contacts. The privacy policy lists the record in full, and the FAQ has the short version.

A pseudonym that rotates every 30 days

Every accepted reaction lands in the public transparency log, and each entry carries a pseudonym rather than an account. The pseudonym comes from a signing key your extension creates on your device once every 30 days. Before the key can sign reactions, the operator signs it too, blind: the extension hides the key while the operator signs, so the signature proves "this key belongs to an enrolled account" without the operator learning which key it signed. The public log therefore shows that the number of keys never exceeds the number of accounts, and not which key is whose.

A proof that the account is real

Enrolling an account writes 1 more entry to the log: a zero-knowledge proof that the provider signed a sign-in for this account, checked against the provider's published keys, without revealing the account. Anyone running the open-source verifier can check that every account in the log traces back to a real provider sign-in, and that no key signs reactions without such an account behind it. Never in the log: the provider's id for you, or anything a provider could match against its own records.

The public log carries the proof, the blind signatures and the pseudonymous entries, and it is anchored and mirrored outside Emojery's control, so the operator cannot pad a count without opening real provider accounts, and every account opened is visible to anyone who recounts.

In plain words

When you sign in, Google (or Microsoft, or Apple) hands the extension a note with its own signature: "this person signed in to Emojery, and the sign-in is tied to this device key". Nobody can forge that signature, Emojery's operator included. But the note also carries your number at the provider, so it can't be shown to the world.

A zero-knowledge proof solves exactly that. It lets anyone check "I hold a real note signed by Google, it is about this key, and the account entry was computed from it by the published rule", while nobody sees the note itself. Think of a notary who looks at your passport and certifies "the passport is genuine and its holder is over 18" without showing the passport to anyone.

What it guarantees, and what it doesn't

Check it yourself

The open-source verifier checks every enrollment proof in the log with npx @emojery/verifier --full: the complete guarantee, at the cost of reading the whole log (minutes at today's volume, growing with the log).

To check one account, give it the entry number of that account's enrollment: npx @emojery/verifier --leaf <number> confirms the entry is in the log, checks its proof, and checks the provider's key against those copies, in seconds. Your own enrollment number is on the Account tab of the extension.

The rule the whole design serves: 1 provider account is 1 Emojery account, and 1 Emojery account holds 1 reaction per item. Changing your emoji replaces the old one; it never adds. Signing in from another browser with the same provider account lands on the same Emojery account, with the same history and the same reactions.

The honest edge of that rule: someone with 2 provider accounts has 2 Emojery accounts. What the log guarantees is that every account cost a real sign-in with 1 of 4 providers, and that each such account shows up as an enrollment anyone can count.

And if you change your mind, the popup has a "Delete account" button. One click and the account record is gone, and the reactions you left over time are subtracted back out of the counts they belong to. The log keeps the pseudonymous entries themselves, each with a public revocation appended after it — that reversal is what moves the counts.