How to Stop a Chrome Extension Saving Passwords

Some of the worst reviews of form history tools are not about features. They are about a card number that got stored when the browser prompt said never, or a password that turned up in a history window nobody else could see.

Both complaints are fair. The deeper problem is that almost nobody checks, because there is no obvious way to check. There is. It takes about a minute.

Check 1: read the permissions

Open chrome://extensions and click the extension. Read the permissions section line by line.

For a tool that records what you type, the minimum sensible set is storage, plus something for scheduled cleanup, plus a way to talk to the tab you are looking at. Anything beyond that deserves a reason.

The one to watch is host permissions reading Read and change all your data on all websites. Sometimes that is legitimate, because a tool that works on every site needs it. But it is also the permission that lets an extension read anything on any page, including a banking session, so it is not a permission to grant lightly. Form ReDraft deliberately requests none: its content script reaches pages through the standard content script match patterns instead.

Check 2: look at what is actually stored

This is the check that settles the argument. Steps:

1. Open chrome://extensions, turn on developer mode and note the extension identifier.
2. Open any page, press F12 and go to the Application tab.
3. Expand Extension Storage and choose the extension.
4. Look through the stored entries. Values are readable in plain text unless the tool encrypts them.

Do this after typing a password, a card number and a one-time code into a test form. If any of them appear, the tool is unsafe and you should uninstall it.

Two things to notice while you are there. A tool that stores values in plain text has nothing to hide and nothing to protect, and you should know that before you type anything sensitive on a machine you care about. A tool that encrypts is better, though the key has to be readable by the extension, so encryption protects against casual exposure in backups and disk artefacts rather than against malware.

Check 3: does it refuse the field, or just miss it?

There is a meaningful difference between a tool that refuses password fields and one that happens not to have seen them yet.

Test it on a form with a range of sensitive inputs: a real password field, a card field marked with autocomplete="cc-number", a one-time code field, and a plain text input whose name is something like security_code. Type into each one, then inspect the storage again.

A robust tool refuses all of them, including the plain text input with a suspicious name. Matching on the field type alone is not enough, because sites disguise sensitive fields constantly. A custom CSS or component library will happily render a password box as type="text" with the styling done in CSS.

This is why good filters look at the field identifier, name, class, label and placeholder as well as the type, and why they match whole words after splitting camel case. A naive substring check on the word "pin" would block a field called shipping, which is a false positive you will notice immediately, and would still miss pinCode if it were not careful in the other direction.

Check 4: can the protection be turned off?

Look for a setting along the lines of include password fields, or record everything.

If it exists, the protection is not real. Settings get changed, by you or by someone using your computer, and often by a restore from backup that turns everything back on. Credential refusal should be unconditional, because it is not a preference, it is the boundary of what the tool is for.

The same reasoning applies to secrets that appear inside ordinary text. A long paragraph that happens to contain an API key should have the key removed and keep the sentence. A tool that either saves the whole paragraph or drops it entirely has made a choice you would not have made.

And a fifth thing worth checking

Does the tool make network requests at all? For an extension whose entire job is to remember what you type, the answer should be no, and you can confirm it in seconds.

Search the source for fetch, XMLHttpRequest, WebSocket and sendBeacon. Then check the manifest for any host permission pointing at a domain you do not recognise. An open source extension lets you do this properly, which is a legitimate reason to prefer it over a closed one.

What a good answer looks like

Put together, the standard worth holding an extension to is short:

• It refuses password, hidden, card and one-time code fields, unconditionally.
• It matches on identifiers and labels, not only on the field type.
• It scrubs secrets out of ordinary text rather than storing them.
• It stores values on your own device, encrypted.
• It makes no network requests and holds no account.
• It lets you pause it on a single site and delete everything.

Form ReDraft is built to that standard, and the privacy policy and documentation state exactly what it does and does not collect, including the limits of its encryption.

FAQ

Related Articles