Frequently asked questions

Google classifies gmail.readonly as a restricted scope. Clearing that warning requires an annual third-party security assessment called CASA, which costs several hundred euro a year. This is a free extension with no revenue, written by one person, so that assessment has not been paid for.

Google permits an unverified app to be published with a limit of 100 users. At the warning screen, click Advanced and then continue.

On Firefox that link names allizom.org rather than Auto Auth Filler. That is Mozilla's own domain: Firefox derives the OAuth redirect address from it, and Google's warning names the redirect target rather than the application. The address has no DNS record at all, so nothing is ever sent there. The extension reads the authorisation code out of the tab address locally and closes the tab.

The cap is set by Google and does not reset. Once 100 Google accounts have granted access, no further account can sign in until the app is fully verified. If that becomes a real problem, it is a good problem, and it would justify paying for the assessment.

Outlook, iCloud Mail and IMAP each mean their own authentication, their own API, their own review process and their own privacy disclosures. Gmail was chosen because it is the one most people use. Support for another provider is possible but is a substantial piece of work rather than a setting.

Sites email one-time codes during sign-in, sign-up, password reset, email confirmation and checkout. That set is not something anyone can list, so a list of allowed sites would silently fail on the one site you needed.

What the content script actually reads is form-field metadata: the field name, id, placeholder, aria-label, the associated label, the input mode, the maximum length and the text of the surrounding form. It does not read page content generally, does not watch what you type and sends nothing anywhere. On a page where nothing scores above the detection threshold it does nothing at all: no overlay, no network request.

The alternative, activeTab, only grants access after you click the toolbar icon. At that point you have done as much work as opening your inbox, and the extension has no reason to exist.

Card fields are rejected on three signals: the browser's own cc-csc, cc-number and cc-exp autocomplete tokens, unambiguous card wording in both languages and words that mean a card security number only on a payment form. Refusal is absolute rather than a low score, so no other evidence can outvote it.

A 3-D Secure challenge during checkout still works, because that is a genuine emailed code rather than card data.

Safari extensions can only be built, signed and tested with Xcode, which runs on macOS only. The developer of this extension works on Windows and has no Mac, so a Safari build cannot be produced, let alone tested. Shipping one would also require an Apple Developer membership at $99 a year, and an iOS extension has to be delivered inside an App Store app.

There is also an unresolved technical question. Safari's support for the identity API that this extension uses to sign in to Google is inconsistent between sources, and it would have to be tested on real hardware rather than researched. Until someone can do that, claiming Safari support would be a guess.

Chrome, Edge, Brave, Opera and Vivaldi all work on macOS, so the extension is usable on a Mac today, just not in Safari.

There is no server, no account and no analytics. The only network requests go to three Google addresses, to read your own mail. Message contents are held in memory only while the patterns run over them and are never written to disk or logged.

The scope requested is gmail.readonly, which Google enforces: the extension cannot send, delete or change anything, whatever its code says. The source is public, unminified and readable exactly as shipped, so none of this has to be taken on trust. Full detail is in the privacy policy.

Google's Web application client type requires a client secret at the token endpoint even when PKCE is used, and Firefox forces that client type because its redirect address is an HTTPS URL. The secret therefore ships inside the package, where anyone who unpacks it can read it.

The authorisation flow uses PKCE with SHA-256, so an intercepted authorisation code cannot be exchanged for a token without the verifier, which never leaves the extension. Somebody with the secret could impersonate this application on a Google consent screen; they could not read anyone's mail, use anyone's tokens or bypass consent. This is documented rather than hidden, in SECURITY.md.