There is an attack that a padlock does not stop. Somebody who gains control of a domain's DNS can obtain a genuine certificate for it, because a certificate authority checks control of the domain and they have it. The clone then has a valid certificate, the right name, a closed padlock, and a copy of a site whose code is public.

The defence has to be something the clone does not have and your browser already remembers.

What happens

The first time you use the app, your browser downloads our application key and pins it. On every visit after that it checks the key it is shown against the one it kept.

Sensitive requests, sign in among them, are encrypted to that key before they are sent, on top of TLS. A clone receives bytes it cannot open, so a password typed into a convincing copy is not a password anybody learns.

If the key changes without a signed handover from the old one, the app stops loading and shows a page explaining what happened, with both fingerprints side by side.

Rotation, without teaching you to click through warnings

Keys are replaced from time to time. When that happens, the old key signs a statement naming the new one, and your browser follows it silently. You are never asked to accept a new key, because a service that regularly asks you to accept a new key has trained you to accept the attacker's.

The known gap

Your first visit has nothing to compare against. If that visit is already under attack, your browser pins the attacker's key.

Nothing inside a browser fixes that. What narrows it: the browser extension ships with the key inside it and arrives through a different channel, and the fingerprint is published in the signed canary and can be compared by eye. It is written in four character groups so it can be read aloud.

Checking by hand

The fingerprint your browser pinned is shown in your settings. It should match the one in the canary. If it does not, stop, do not sign in, and tell us through a channel that does not go through this site.