Docs · Profiles

Encrypted profiles.

A Husk profile is the bag of state that makes a session a session: bookmarks, history, cookies, the vault, notebooks, settings. Encrypted profiles seal that bag at rest with a phrase only you know — no online account, no recovery email, no backdoor.

Crypto in one sentence

Argon2id derives a key from your phrase; ChaCha20-Poly1305 AEAD encrypts the profile blob; the source is published as husk-crypto for independent audit.

Argon2id parameters: m=64 MiB, t=3, p=1, 16-byte random salt per profile. Targeted for ≥250 ms key-derivation latency on a 2023 laptop. That's slow enough to make brute-forcing a weak phrase painful and fast enough that unlocking by hand still feels instant.

Creating a profile

  1. Click your avatar in the top-left chrome bar to open the profile picker.
  2. Choose New encrypted profile, give it a name, pick a phrase. Strong phrase = strong profile — length beats complexity.
  3. On first run after unlock, Husk creates a fresh WebView2 user-data directory inside an in-memory or scratch location so the underlying engine cache never lands on disk.

Locking and unlocking

When you lock a profile (avatar menu → Lock) three things happen, in order:

  1. All in-memory secrets — phrase, derived key, cleartext session data — are zeroed in place via Zeroizing wrappers.
  2. The materialized profile directory (WebView2 cache, credentials, decrypted vault) is securely wiped: each file overwritten with zeros, truncated, then unlinked. This is a deliberate choice over the standard remove_dir_all which would leave readable blocks on NTFS/FAT32 until reuse.
  3. The encrypted profile blob is re-sealed on disk. The avatar shows no name, no bookmark hint, no history preview — locked profiles are blank cells in the picker.
SSD wear-leveling. Secure wipe overwrites the logical blocks Husk owns, but a modern SSD's controller can hold physical copies elsewhere for hours or days. Combine Husk with full-disk encryption (BitLocker / VeraCrypt) if your threat model includes forensic recovery on the underlying storage.

No recovery, on purpose

There is no "forgot phrase" link. There is no recovery email. There is no backup keyfile auto-stored anywhere we control. If you lose the phrase, the profile is unrecoverable — and that's the point: the design refuses to give Husk (or anyone with the binary) the power to decrypt against your will.

Pick a phrase you can remember without writing down. If you must write it down, treat the paper the way you'd treat a house key.

Multiple profiles, side by side

Husk supports as many profiles as you want — encrypted or plain — running simultaneously, each in its own window. Tabs from profile A can't reach the storage of profile B; the WebView2 user-data folders are isolated per profile.

A typical setup:

  • Default (unencrypted) — daily browsing, nothing sensitive.
  • Work (encrypted) — corporate logins, internal tools.
  • Personal (encrypted) — banking, medical, anything you'd hate to lose.
  • Research (encrypted) — the profile you don't want associated with the others.

Deleting an encrypted profile

Deletion requires the phrase. Husk asks for it before wiping, for two reasons:

  • Prevents someone with brief access to your machine from silently destroying a profile.
  • Forces an explicit unlock-then-delete flow, which gives Husk the chance to securely wipe the cleartext before removing the blob.

What's still visible

Encrypted at rest does not mean invisible. A few things stay observable to someone with file-system access:

  • The number of profiles. Each encrypted profile is a separate blob; counting blobs reveals how many profiles you have.
  • Approximate activity timestamps. File modification times on the encrypted blobs change when the profile is unlocked and used.
  • Existence of Husk itself. The husk.exe binary on disk is observable, as is the HuskData/ folder.

The vault's duress slot is the tool for the case where "do you have an encrypted profile?" gets asked under coercion.

← Install & verify Vault & duress slot →