File
SMF·ROBOFORM
Received on
31.07.2026
Reviewed on
28.09.2026
Exhibits annexed
3
Questions
4

SMF·ROBOFORM

Can a prompt replace RoboForm?

Security & passwords — passwords, privacy and private networking

Not yet Verdict recorded on 28.09.2026 · Verified on 31.07.2026
Price
$2.49/moSource: roboform.com · Checked on July 31, 2026
Per year
$29.88
Build time
One sitting
Votes
0 votes
YesAlmostNot yet (checked)

Exhibit tracking slip

Exhibit A The prompt
Exhibit B What you lose
Exhibit C Why people still pay: security assurance, infrastructure, and trust
Exhibit Q Questions

Verdict

Storing passwords is not what RoboForm is for. It is a form filler, and its value is an identity — name, addresses, cards, custom fields — that lands correctly in checkout forms nobody standardised. A personal build can hold those identities properly and export them in a shape a browser's own autofill can use, which is a genuinely useful afternoon. What it cannot do is the compatibility work: RoboForm has been learning what real websites' forms look like since before autocomplete attributes existed.

Exhibit B — What you lose

Exhibit A — The prompt

Received on31.07.2026
Build a local encrypted store for structured identities, designed to hand off to the browser's own autofill rather than replace it.

Vault: a desktop application. Derive the key from the master password with Argon2id using a per-vault salt, with the parameters in the header so they can be raised later. Encrypt with an authenticated cipher from a maintained library; never assemble primitives by hand. Auto-lock on a timer and on sleep.

Identities, which are the point of this build. An identity is a named profile — "personal", "work", "the company" — holding typed fields grouped properly:

- Person: given name, family name, middle name, preferred name, title, date of birth, gender.
- Contact: several email addresses and phone numbers, each labelled.
- Addresses: several, each labelled, with the fields real forms ask for — line 1, line 2, city, region or state, postal code, country — plus a note on which country's format it follows, since address shape is the thing form fillers most often get wrong.
- Payment cards: label, cardholder name, number, expiry, and a billing address reference. Never store a CVV.
- Custom fields: arbitrary key-value pairs per identity, for the tax numbers, membership ids and account references that every real form eventually asks for and no standard covers.

Validation on entry: postal codes checked against the country's pattern, card numbers by the Luhn check, dates as dates. An identity with a typo in it fills a hundred forms wrongly.

Browser handoff, rather than an extension: export an identity in the formats browsers themselves consume — a CSV in the layout Chrome's address and payment import expects, and the equivalent for Firefox — so the browser's own autofill does the actual filling. Document the import path for each. This is the honest architecture for a personal build: writing an extension that competes with native autofill is a large project with a permanent maintenance cost, and the native implementations are now good.

Also build: passwords and TOTP secrets alongside identities, since a form filler without credentials is half a tool; import from RoboForm, 1Password, Bitwarden and CSV; and export both encrypted and plain with a warning on the plain path.

Field-mapping notes: per-site notes where the user records what a specific awkward site expects. Not automation — a place to write down that a particular checkout wants the house number in line 2, so next year's confusion is already answered.

Display a persistent notice that this build has had no independent security review.

Out of scope: a browser extension, mobile apps, sync of any kind, and automatic form detection or submission.

Opening prefills the prompt — press enter to run it.

Exhibit B — What you lose

  • B.1 the browser extension and twenty years of site-specific form handling
  • B.2 sync between machines and mobile devices
  • B.3 independent security audits and a recovery path
  • B.4 matching the right identity to a site automatically

Prior art

Exhibit C — Why people still pay: security assurance, infrastructure, and trust

Because form filling either works on the site you are on or it is worthless, and per-site compatibility is a long tail nobody rebuilds. Two and a half dollars a month is cheap for that.

Questions

Can I import my RoboForm data?

Yes. RoboForm exports logins and identities as CSV, and both map onto this schema, though custom identity fields come across as unstructured pairs and need tidying. Do the export before cancelling — it is not available afterwards.

Why hand off to the browser instead of writing an extension?

Because native autofill in Chrome and Firefox is now good, and an extension that competes with it is a permanent maintenance commitment against sites that change constantly. Exporting into the browser's own store gets you filling that works everywhere the browser works, for a fraction of the effort.

What does it cost to run?

Nothing. A local application over an encrypted file, no server, no keys, no subscription — against a few dollars a month. The money argument is clear; the compatibility argument is not.

What is the one thing that does not survive the rebuild?

Filling the awkward sites. Native autofill handles well-marked forms and fails on the badly built checkout that asks for your address in four unlabelled boxes — which is exactly where a dedicated form filler earns its subscription.

Receipt

Already built this yourself?