Security

This page says plainly what the extension does and does not protect, so you can decide what to trust it with. It is written for someone who will be handing it an AWS password.

The limitation, stated first

Your AWS password and TOTP secret are stored unencrypted on your own device. They live in the extension's local storage as plain text.

What that does protect against:

• Other websites. No web page can read another extension's storage. Chrome isolates it by origin.
• Other extensions. Same isolation. An extension cannot read this one's storage.
• The network. There is nothing to intercept. The data never leaves the machine — see the Privacy Policy.

What it does not protect against:

• Anything running as your OS user. A program on your account can read the file.
• Anyone holding your Chrome profile directory, or a backup, or a stolen unencrypted disk.
• You, via DevTools. Which is also how you can verify all of this for yourself.

Why it is not encrypted

Because the honest answer is better than encryption that only looks like protection.

The extension's entire purpose is to sign in at 09:00 with nobody present. Any key it can use unattended is a key it must be able to obtain without you — which means storing it on the same disk, in the same profile, reachable by exactly the same attacker who could have read the password directly. Encrypting under such a key moves the problem one file to the left and changes nothing about who can read your credentials.

That includes the option that looks strongest on paper: a non-extractable Web Crypto key kept in the browser's own database. The Web Crypto specification explicitly declines to guarantee that key material is not written to disk unencrypted, and Chrome gives such keys no operating-system keystore or hardware backing. Marking a key non-extractable constrains the JavaScript API; it does not protect storage.

Chrome's own password manager does better because it encrypts under a key held in the OS keychain. No extension API exposes that. The W3C WebExtensions secure-storage proposal exists precisely because there is no such API today — and it remains a proposal.

Shipping something that reviewers and users would read as “the credentials are encrypted” when the practical security is identical to plain text would be worse than this page.

What would actually fix it

Two designs genuinely protect credentials at rest. Both cost something:

• A passphrase you type. The key is derived from it and never stored. This is real protection, and it ends unattended scheduling — the entire feature.
• A native companion application talking to the OS keychain through Chrome's native messaging. This keeps scheduling, and requires shipping and signing a separate binary per platform.

Choosing between them is a product decision, not pending work. Until one lands, the storage layer is marked development-only in the source, and the extension states this where you type your password.

What to do in the meantime

• Use a dedicated IAM user with the least access that makes your work possible. Never a root account. Never an administrator.
• Enable full-disk encryption (FileVault, BitLocker). This is what makes a stolen laptop a non-event.
• Lock your screen. The threat model here is another process on your user account.
• Do not use an account whose compromise would matter more than the convenience is worth.

Design decisions you can verify

• Credentials are never written into profile metadata, never put into a scheduled alarm's name, never included in a saved run record, and never logged.
• Nothing is stored in Chrome's synced storage, so no secret is copied to your Google account or to your other devices.
• The diagnostic trail shown after a run records host and path only — never a query string, and never the value of anything it filled in — so it is safe to paste into a bug report.
• Multi-factor codes and QR images are processed on your device. Those modules make no network calls at all.
• The extension requests four permissions and access to two AWS hostnames. It does not request the tabs permission and cannot see your other tabs.
• The login flow verifies which AWS account the new session belongs to and fails rather than assuming. If you are signed into a different account, it stops instead of signing you out.

These are enforced by tests that read the source itself, so they survive future changes rather than depending on review.

Reporting something

If you find a security problem, please report it privately using the contact address on the Privacy Policy page. Never include a password, a TOTP code, a session cookie or a full AWS URL in a report.