Legal — WordLock

Privacy

This site does not collect anything. There is no account system, no analytics, no cookies, and no tracking of any kind. Passwords are generated in your browser and are never transmitted.

The only data stored is kept by your own browser, in localStorage, on your device:

Your generator preferences — length, character types, separators, capitalization and similar settings.
The tab you last had open.
Recently generated passwords, each stored with the strength figure it was generated at — encrypted at rest (AES-GCM) with a key that is generated in your browser, marked non-extractable, and kept in IndexedDB on your device. Honesty about what that buys: it shields the history from casual inspection and from anything that reads localStorage off your disk, but it cannot protect against someone with full control of your browser profile, because your browser must be able to use the key to show you the history — so such an attacker can too. If your browser cannot encrypt, history is kept in memory only and never written to disk. Note that each of the seven generators keeps its own separate list, and the History control sets the limit per generator rather than overall — so at the default of 10 you may have up to 70 passwords stored across all of them. Setting History to Off erases every generator's list, not just the one you are looking at, and stops anything further being kept.

If you create a vault, it is by default stored the same way — on your device, in your browser — but encrypted with a passphrase only you know, using 1,000,000 rounds of PBKDF2. That key is never written anywhere and exists only while the vault is unlocked, so a copy of your browser profile yields ciphertext rather than passwords. There is no account and no server, so there is nothing for us to reset: if you forget the passphrase, we cannot open the vault and neither can anyone else.

You may instead choose to keep the vault as a single encrypted file in a folder you pick, which is the one case where vault data leaves this device — and it leaves by your instruction, through your software, to a company you already have a relationship with. If that folder is synchronised by Dropbox, OneDrive, iCloud Drive or anything similar, then that provider receives the file, and what they hold is governed by their terms rather than these. Two things are worth being precise about:

What they can see. The file is the same sealed ciphertext the browser was holding — AES-256-GCM under a key derived from your passphrase. A provider learns that a file changed, roughly how large it is, and when. They cannot read an entry, a label, or a count of them. Neither can we, and we do not receive the file at all.
This site is still not the one sending it. The page writes a file to a folder on your computer. Your own sync client, which you installed and configured, uploads it. WordLock makes no network request to your provider and holds no credentials for them — the statement below that this site makes no third-party requests remains true in folder mode.

You may also generate a recovery key — sixteen random words, shown once, which the vault stores your master key encrypted under. It is a second key that you hold, not a back door that we do: it is generated in your browser, never transmitted, and we never see it. If you lose both the passphrase and the recovery key, the vault stays closed, and that is still the design rather than a shortcoming.

One honest exception, because it is a real trade rather than a detail. The Vault lock setting decides how long the vault may stay unlocked as you move between pages. While that window is open, the vault key is kept in browser storage, encrypted under a second key that the browser can use without asking — the same protection level as the history list above. That stops casual inspection and anything reading the database off your disk, but not somebody in control of your browser profile. When the window expires the held key is deleted and the vault is worth only the passphrase again. Setting Vault lock to “Every page” switches this off entirely: nothing is held, the key is never even made exportable, and you are asked for the passphrase on each page.

Files you export leave all of this behind. An encrypted backup is still encrypted and is safe to keep wherever you like — it is worth exactly what its passphrase is worth. The plain-text JSON and CSV exports are not: they contain your passwords in the clear, readable by anything that can read your downloads folder, and no longer covered by anything described on this page. They exist only so you can move to a different tool rather than being stuck here, they are named PLAINTEXT so you cannot mistake one for a backup, and they should be deleted the moment the move is done. Nothing is uploaded when you export; the file is written by your browser and goes wherever you put it.

What we cannot scrub from memory, and why. A careful password manager overwrites secrets in memory the moment it has finished with them, so that a crash dump, a swap file, or a hibernation image does not quietly preserve them. We do that where the browser allows it: the vault key is a non-extractable CryptoKey, meaning its bytes are never handed to our code at all and are released when the vault locks. Your passphrase is different. It arrives as an ordinary JavaScript string from a text field, and strings in JavaScript are immutable — there is no way for any page, ours included, to overwrite one. It stays in memory until the browser's garbage collector happens to reclaim it, on no schedule we control. We hold it for as briefly as we can and never write it anywhere, but a page in a browser cannot promise more than that, and any web password manager telling you otherwise is describing an intention rather than a guarantee.

Clearing your browser's site data erases all of it. None of it is ever sent anywhere. If you turn on Clear clipboard in the settings gear, a copied password is also wiped from your clipboard after the delay you choose.

Why we say “no cookies”, and what that does and doesn't mean

The distinction is worth being precise about, because “no cookies” is easy to use as a dodge.

It does mean something real. A cookie is attached automatically to every request your browser makes to a site — every page load, every asset. Had this site set one, its contents would travel to the server constantly whether that was useful or not. localStorage behaves differently: it is readable only by code running on this page, and nothing in it reaches a server unless code deliberately sends it. This site contains no such code. That is a structural difference, not a promise we are asking you to take on trust.

It is not a loophole. localStorage is still data kept on your device, and the rules that people think of as “cookie law” are written to cover any storage on a user's device, not the word cookie. So the honest position is not “we avoided cookies, therefore nothing applies” — it is that everything stored here is functional: settings you chose, the tab you were last on, and a history you can switch off. There is no identifier, no profile, no third party, and nothing that could be used to recognize you later or anywhere else.

Which is why this page lists what is stored rather than simply asserting that the site is private. You can also check it yourself: open your browser's developer tools and look under localStorage for this domain. The entries are namespaced by generator — you will see keys such as simple.history, words.history and global.activeTab, one set per generator you have used. There is no identifier among them, and nothing beyond the categories listed above.

The site makes no third-party requests. Vue and the icon font are served from this domain rather than a CDN, so no outside party observes your visit. Links to other sites are ordinary links and are only followed if you click them.

The site is hosted on Render, which — like any web host — may keep standard server logs. That is outside this project's control and is governed by Render's own policies.

License

The source code is released under the MIT License, Copyright © 2019 Ray Tetzloff. The full text is in the LICENSE file in the repository. In short: you may use, copy, modify and distribute it, including commercially, provided the copyright notice and license text are retained.

Disclaimer

This software is provided "as is", without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and non-infringement. In no event shall the author be liable for any claim, damages or other liability arising from the use of this software.

Practically: while passwords are generated using the browser's cryptographic random number generator, no guarantee is made about the security of any particular password, about the security of the device or browser you run this on, or about how you subsequently store and use what you generate.

Third-party components

Copies of these are vendored into the repository so the site can be served without external requests.

Material Design Icons 7.4.47: The icon font, published by the Pictogrammers group under the Pictogrammers Free License — icons and fonts under Apache 2.0, code under MIT. This is the community icon set, which is a distinct project from Google's Material Icons. Full text: vendor/mdi/LICENSE.
Orchard Street Long List 0.4.3: The 17,576-word list behind the Words generator, by Sam Schlinkert, derived from English Wikipedia and Google Books frequency data. Licensed under CC BY-SA 4.0. That license applies to the word list file itself — it is kept as a separate file for exactly this reason. The rest of this project remains under the MIT license above. It replaced the EFF Long Wordlist, which is still an excellent list and is what you want if you are rolling physical dice.
imsky/wordlists: Topical word lists by Ivan Malopinsky, MIT licence, used to grow the categorised lists behind Passphrase, Wireless and Mad Lib.
English word lists by part of speech: Public domain (Unlicense), by verachell. The adverb list is the source of most of the Manner adverbs.
SecLists — “500 worst passwords”: MIT licence, by Daniel Miessler, Jason Haddix and contributors; compiled originally by Mark Burnett from leaked-credential analysis. Used only to recognise a passphrase that appears on it, so the vault can refuse the few hundred passwords an attacker tries first. The list is shipped with the site and consulted on your device — your passphrase is never sent anywhere to be checked, and the check works offline.

The categorized word lists used by the Passphrase, Wireless and Mad Lib generators were written for this project, and have since been grown from the two permissively licensed sources named above — MIT and public domain. They remain under the MIT license, and they are deliberately kept separate from the Orchard Street list so that its share-alike terms do not reach them.

Questions about any of the above can be raised as an issue on GitHub.