Husk 0.1.5 — Auto-update from Settings

Husk

A privacy-first browser written in Rust for Windows. Encrypts your profile
at rest, spoofs your fingerprint, blocks ads and trackers at the DNS layer,
and shreds itself when you close it.

Website: husk.run
Contact: contact@husk.run · Security: security@husk.run
Crypto source (auditable): github.com/runhusk/husk-crypto

---

Why this repo

Husk's source lives on a private NAS — only the trust-critical crypto
modules are open source (see husk-crypto).
This repo exists to host the public binary releases: portable zips,
installers, and SHA-256 checksums, all served via GitHub Releases.

Why a separate repo:

• Encryption / decryption code is auditable, the rest stays closed
• GitHub Releases give every download a stable, immutable URL
• Each release ships a SHA-256 the user can verify locally before running

Download

Always grab the latest release at:

→ github.com/runhusk/husk/releases/latest

The website's "Download" button redirects there.

Updating Husk

From v0.1.5 onward, Husk can update itself. Open
Settings → About inside Husk, click Check for updates, and if a
newer version is available, click Download & install. Husk pulls
the new husk.exe from the GitHub Release, swaps the running binary
in place, and asks you to restart. Your HuskData/ folder (bookmarks,
profiles, vault entries, history) is preserved.

• The check only fires when you click the button — Husk does not
  auto-poll, does not run a background updater, does not phone
  home on launch.
• The downloaded husk.exe is the exact asset published in this repo,
  not relayed through any third-party update server.
• If you'd rather update by hand (or you're on v0.1.4 or older), the
  standalone husk.exe is still on the download page — drop it next
  to your existing HuskData/.

Verify the binary before running

Husk is a privacy tool — you should verify any privacy-sensitive binary
you download. After downloading the zip, open PowerShell in the folder
and run:

Get-FileHash .\Husk-Portable-0.1.5.zip -Algorithm SHA256

Compare the output to the SHA-256 listed next to the asset on the release
page. If they don't match, do not run the file — open an issue or
email security@husk.run.

What's in the portable build

A single husk.exe (~6 MB) plus a husk.portable marker file. Drop both
in any folder, run the .exe, and everything Husk writes (profiles, history,
bookmarks, vault, WebView cache) lives in a HuskData/ directory next to
the binary. USB-stick friendly, no installer, no registry write, no trace
on the host machine.

Bug reports

• General: contact@husk.run
• Security disclosure: security@husk.run (responsible disclosure credited
  in the changelog unless you opt out)

Issues on this repo are open for binary-related questions (download fails,
SHA-256 mismatches, install issues). For browser features / behaviour, email
contact@husk.run — the source lives elsewhere so we can't accept code PRs
here.

Husk v0.1.4 — URL-bar Paste fix + in-place update path

Husk v0.1.4 — URL-bar Paste fix + in-place update path

Small patch release. Two user-visible improvements:

1. Right-click → Paste / Paste and go in the URL bar now work.
2. The download page exposes a standalone husk.exe so existing users
   can update in place without re-extracting the full zip.

Downloads

File	Size	SHA-256
Husk-Portable-0.1.4.zip	1.8 MB	ef4bdd4f272403620c1d91ccce60ce022470eeb33aa9beff726e0126436e7d98
husk.exe (standalone, for in-place update)	4.0 MB	c6fe5c521ae9143184d688d820fc242578ec6420a7eb2815766106cb5d32b8c5

Verify before running

Get-FileHash .\Husk-Portable-0.1.4.zip -Algorithm SHA256

Match the output against the hash above. If it differs — do not run.

What's new

URL-bar Paste / Paste-and-go fix

Right-click in the URL bar → Paste or Paste and go had been
silently failing since the menu was rewritten as a Win32 popup. Root
cause: when the popup callback fires, Chromium has lost its "recent
user activation" signal — both document.execCommand('paste') and
navigator.clipboard.readText() get gated by the permission system and
return nothing. The keyboard shortcut Ctrl+V still worked (because that
IS a fresh user gesture), but the menu items did not.

v0.1.4 reads the clipboard on the Rust side when the user picks
Paste / Paste-and-go, where no user-activation gate applies, and ships
the text into the URL bar directly via the existing chrome IPC channel.
Cut, Copy and Select all keep using document.execCommand — they
write to the clipboard, which WebView2 still allows in any context.

In-place update path on the download page

The download page now offers two clearly-labelled paths:

• New install → the same Husk-Portable-0.1.4.zip as before.
• Already have Husk? → just the standalone husk.exe (4 MB).
  Close Husk, drop the new binary next to your existing HuskData/
  folder, overwriting the old one. Bookmarks, vault entries,
  profiles, history and cookies all live in HuskData/ — not in the
  executable — so a binary swap is the whole upgrade.

Everything else

Unchanged from v0.1.3 — same OAuth popup handling, same vault, same
DoH stack, same boss key, same crypto source at
husk-crypto.

Upgrade path

• From v0.1.x portable: download husk.exe from the new
  "Already have Husk?" link, replace the file inside your folder,
  re-launch. HuskData/ is untouched.
• From the zip: re-extract on top of your current folder; the zip
  doesn't bundle HuskData/, so your data is preserved either way.

Known limitations carried over

• Taskbar pin AUMID identity is still consolidated by Windows Shell
  in development setups where multiple husk.exe binaries live on
  the same machine.
• macOS + Linux still v0.2 targets.

---

If Husk is useful to you, support keeps it free, ad-free and
account-free: husk.run/donate.

Husk v0.1.3 — Real popup windows + Firebase Auth fix

Big OAuth-flow release. Three connected fixes that together make "Sign in with X" feel right: popups behave like popups, vault stops hijacking the sidebar, and Firebase / postMessage-based auth actually delivers the token back to the parent page.

Downloads

File	Size	SHA-256
Husk-Portable-0.1.3.zip	1.8 MB	f2ff59527e958cacf7cad6c16f5467befdc695d9d8a273ab73733a5aefdd295d
husk.exe (raw, for inspection)	4.0 MB	b496c017c3b2fd2be4a87d37202b3ae9f5a65c53f3da107ef7a6315d1d84f69b

Verify before running

Get-FileHash .\Husk-Portable-0.1.3.zip -Algorithm SHA256

Match the output against the hash above. If it differs — do not run.

What's new

OAuth popups open as real popup windows

"Sign in with Google / Microsoft / GitHub / Apple" used to land in a new TAB inside the current window. The login form was there, the auth completed, the tab closed (since v0.1.1) — but the visual experience was wrong: an OAuth flow is supposed to feel like a transient dialog, not "your browser is now hosting two tabs."

v0.1.3 routes window.open(url, _, "width=X,height=Y,...") — the universal popup pattern — to a new Husk window sized to the requested dimensions (with a sane 320×240 minimum), inheriting the parent tab's mode (Normal / Private / Paranoia). When the auth flow calls window.close(), the whole popup window disappears and you're back on the parent page.

Implementation: native add_NewWindowRequested hook reads WindowFeatures.HasSize / HasPosition. With a hint, popup window. Without, fall through to the v0.1.0 behaviour (new tab). Middle-click and target="_blank" on regular links still open as tabs.

Firebase Auth + postMessage-based OAuth now work

The headline fix. Earlier Husk versions would open the OAuth popup, let the user authenticate, then close the popup — but the parent site wouldn't actually log in. The cause: the popup and the parent were two separate WebView2 instances with no window.opener relationship between them, so the popup's window.opener.postMessage(token) call (the standard Firebase Auth delivery mechanism, used by tens of thousands of SaaS sites) sent its token into the void.

v0.1.3 fixes this by using WebView2's deferral pattern around NewWindowRequested: we take a deferral, build the Husk-side popup WebView, then hand WebView2 our controller via args.put_NewWindow(...) and complete the deferral. WebView2 then navigates our controller to the popup URL with window.opener correctly wired to the parent. postMessage works the way the page expects, the token arrives, the parent logs in.

Tested against Firebase Auth (e.g. promptbase.com), Google direct OAuth, GitHub OAuth, Microsoft OAuth.

Vault save prompt no longer auto-opens the sidebar

When you submitted a login form, Husk would offer to save the credentials to your vault. In v0.1.1 this was an in-place toast at the top of the chrome IF the vault was already unlocked — but if the vault was locked (or you hadn't set one up yet), the sidebar would automatically expand to show the unlock prompt. On a banking, mail, or work-tool login that you didn't want to save, the sidebar expansion felt like Husk was reaching into a private surface uninvited.

v0.1.3 keeps the offer as a thin horizontal toast in all states. The toast wording adapts ("Save", "Vault is locked — Open vault", "Set up your Husk vault to save this"). The sidebar opens only if you explicitly click "Save" or "Open vault" on the toast — or if it was already open at the time of the form submit.

OAuth credentials are never offered for save

Related: credentials entered into an OAuth popup window are not offered for save in your vault at all. The credential belongs to Google / Microsoft / etc., not the parent site, so saving it would be confusing at best and dangerous at worst.

Everything else

Unchanged from v0.1.1 — same Argon2id + ChaCha20-Poly1305 vault, same DoH proxy, same anti-fingerprint stack, same boss key, same crypto source at husk-crypto.

Upgrade path

Drop the new husk.exe into your existing portable folder, replacing the old one. Your HuskData/ directory stays untouched.

Known limitations carried over

• Taskbar pin AUMID identity is still consolidated by Windows Shell in development setups where multiple husk.exe binaries live on the same machine. Affects users running both a dev tree and the portable release — i.e. nobody who only downloaded the public binary. Investigation continues.
• macOS + Linux still v0.2 targets.

Coming next

• Chromeless OAuth popup option (currently popups carry the full Husk chrome — fine for security, but mainstream browsers go minimal)
• Mac and Linux work begins after this patch ships
• A --profile=<name> argument for users who want a non-default startup profile from a desktop shortcut

---

If Husk is useful to you, support keeps it free, ad-free and account-free: husk.run/donate.

Husk v0.1.2 — Popup windows + quieter vault prompt

Patch release on top of v0.1.1. Two UX fixes around the login flow: OAuth popups now behave like real popups, and the "save password to vault" prompt no longer hijacks the sidebar.

Downloads

File	Size	SHA-256
Husk-Portable-0.1.2.zip	1.8 MB	af98e0172bf0478ca799945666ea1a8101cde9bbb63289c11ce963af60b760e2
husk.exe (raw, for inspection)	4.0 MB	450de3bbf79f7b439795fe8a4217d70c6a8d65200dd7713d55a309e6e92c49b7

Verify before running

Get-FileHash .\Husk-Portable-0.1.2.zip -Algorithm SHA256

Match the output against the hash above. If it differs — do not run.

What's new

OAuth popups open as real popup windows

"Sign in with Google / Microsoft / GitHub / Apple" used to land in a new TAB inside the current window. The login form was there, the auth completed, the tab closed (since v0.1.1) — but the visual experience was wrong: an OAuth flow is supposed to feel like a transient dialog, not "your browser is now hosting two tabs."

v0.1.2 routes window.open(url, _, "width=X,height=Y,...") — the universal popup pattern — to a new Husk window sized to the requested dimensions (with a sane 320×240 minimum), inheriting the parent tab's mode (Normal / Private / Paranoia). When the auth flow calls window.close(), the whole popup window disappears and you're back on the parent page.

Implementation: native add_NewWindowRequested hook reads WindowFeatures.HasSize / HasPosition. With a hint, popup window. Without, fall through to the v0.1.0 behaviour (new tab). Middle-click and target="_blank" on regular links still open as tabs.

Vault save prompt no longer auto-opens the sidebar

When you submitted a login form, Husk would offer to save the credentials to your vault. In v0.1.1 this was an in-place toast at the top of the chrome IF the vault was already unlocked — but if the vault was locked (or you hadn't set one up yet), the sidebar would automatically expand to show the unlock prompt. On a banking, mail, or work-tool login that you didn't want to save, the sidebar expansion felt like Husk was reaching into a private surface uninvited.

v0.1.2 keeps the offer as a thin horizontal toast in all states. The toast wording adapts ("Save", "Vault is locked — Open vault", "Set up your Husk vault to save this"). The sidebar opens only if you explicitly click "Save" or "Open vault" on the toast — or if it was already open at the time of the form submit.

OAuth credentials are never offered for save

Related: credentials entered into an OAuth popup window are not offered for save in your vault at all. The credential belongs to Google / Microsoft / etc., not the parent site, so saving it would be confusing at best and dangerous at worst.

Everything else

Unchanged from v0.1.1 — same Argon2id + ChaCha20-Poly1305 vault, same DoH proxy, same anti-fingerprint stack, same boss key, same crypto source at husk-crypto.

Upgrade path

Drop the new husk.exe into your existing portable folder, replacing the old one. Your HuskData/ directory stays untouched.

Known limitations carried over

• Taskbar pin AUMID identity is still consolidated by Windows Shell in development setups where multiple husk.exe binaries live on the same machine. Affects users running both a dev tree and the portable release — i.e. nobody who only downloaded the public binary. Investigation continues.
• macOS + Linux still v0.2 targets.

Coming next

• Chromeless OAuth popup option (currently popups carry the full Husk chrome — fine for security, but mainstream browsers go minimal)
• Mac and Linux work begins after this patch ships
• A --profile=<name> argument for users who want a non-default startup profile from a desktop shortcut

---

If Husk is useful to you, support keeps it free, ad-free and account-free: husk.run/donate.

Husk v0.1.1 - OAuth popups + Shell identity

Patch release on top of v0.1.0. Fixes the most-reported issue from the first 24h (OAuth popups not closing themselves) plus a Windows Shell quirk around taskbar pinning.

Downloads

File	Size	SHA-256
Husk-Portable-0.1.1.zip	1.8 MB	b11a243a4ff72539351afe5f4776f12a5548c3408072b23d22df96baa01bd1c8
husk.exe (raw, for inspection)	4.0 MB	de66fab1c0a90885aaba8f36f69ceede8ddb0e0c6af44db3796cef9ea5929d01

Verify before running

Get-FileHash .\Husk-Portable-0.1.1.zip -Algorithm SHA256

Match the output against the hash above. If it differs — do not run.

What's fixed

OAuth popups now close themselves

Logging in via Sign in with Google / Microsoft / GitHub / Apple used to leave the popup tab orphaned with a "you can close this window now" message — because Husk spawns popups as tabs (not native windows), so WebView2 didn't fire its native WindowCloseRequested event when the auth callback page called window.close().

Fix: window.close() is now intercepted by the content-init script and routes to the existing tab-close IPC. The tab closes on auth completion as users expect. The native WindowCloseRequested hook is also installed as defence-in-depth.

Taskbar pin identity (AUMID per install location)

Two Husk binaries on the same machine — say the official installer and a portable copy — used to share the same Windows Shell identity (Husk.Profile.default). Result: pinning the portable could resolve to the installed binary, so clicking the pin launched the wrong one.

Fix: the AUMID now includes a stable hash of the executable's directory, so each install location has a distinct Shell identity. Pinning the portable in folder A no longer collides with the installed binary in folder B.

Known limitation: Windows aggressively caches existing pin records. If you previously pinned v0.1.0 and re-pin v0.1.1, you may need to unpin first, close all Husk processes, and re-pin from the running portable for the cache to update. Fresh users are unaffected.

Everything else

Unchanged from v0.1.0 — same Argon2id + ChaCha20-Poly1305 vault, same DoH proxy, same anti-fingerprint stack, same boss key, same crypto source at husk-crypto.

Upgrade path

Drop the new husk.exe into your existing portable folder, replacing the old one. Your HuskData/ directory stays untouched — profiles, bookmarks, vault, notebooks all carry over.

Or extract the fresh zip to a new folder, copy your old HuskData/ into it, and run from there.

Coming in v0.1.2

• OAuth popups will open as proper new windows (with the size the page requests) instead of tabs, matching mainstream browser behaviour
• Mac and Linux work begins after this patch ships
• More test coverage on the WebView2 → wry boundary

---

If Husk is useful to you, support keeps it free, ad-free and account-free: husk.run/donate.

Husk v0.1.0 - first public release

Privacy-first browser for Windows. Rust core wrapped around a battle-tested rendering engine. Encrypted profiles, anti-fingerprint, DoH, paranoia tabs, request interceptor, F9 boss key.

Downloads

File	Size	SHA-256
Husk-Portable-0.1.0.zip	1.8 MB	723c65ee3bf4780932611d172177bf531625ad43bbc82e5e91a30f2b35a1ebdb
husk.exe (raw, for inspection)	4.0 MB	8be30704e201c5d1e440b81ae10521ec5f3c367501921512bb24b8526d21214d

Verify before running

Get-FileHash .\Husk-Portable-0.1.0.zip -Algorithm SHA256

Match the output against the hash above. If it differs — do not run.

How to install

1. Download Husk-Portable-0.1.0.zip
2. Extract the zip anywhere (Desktop, a USB stick, wherever)
3. Double-click husk.exe

Done. The husk.portable marker that ships in the zip tells Husk to keep every byte (profiles, history, bookmarks, vault, WebView cache) in a HuskData/ folder next to the .exe. No installer, no registry write, no trace on the host machine.

Why portable-only at v0.1

We're shipping the portable build and nothing else, on purpose. A regular Windows installer writes to Program Files, the registry, the Start menu, and %APPDATA% — the exact set of breadcrumbs Husk exists to avoid. Portable IS the install model: extract, run, and when you're done, delete the folder. Nothing lingers.

If you want quick relaunch, right-click husk.exe → Pin to taskbar. That's the closest thing to a "Start menu entry" we offer, and it's something you control.

A traditional installer may ship in v0.2 as an optional extra for users who specifically want one. The portable build will remain the default and the recommended path.

Requires WebView2 Runtime, which ships with Windows 11 and Windows 10 21H1+. If your machine is older, install the Evergreen Runtime.

What's in this release

Privacy core

• Encrypted profiles — Argon2id + ChaCha20-Poly1305 with a phrase you pick. No recovery email, no backdoor. Bookmarks, history, cookies, vault, notes — sealed at rest. Crypto source open: husk-crypto
• Multi-profile — run as many as you want side by side, encrypted or not, each with its own everything
• Vault — credentials manager with optional duress slot: a second phrase opens a decoy vault for the moment someone insists you unlock
• Encrypted notebooks — markdown notes with per-notebook phrases, image embedding, image paste / drop / file picker
• Portable mode — extract the zip and Husk leaves no trace on the host

On the wire

• DNS-over-HTTPS — built-in DoH proxy, choose AdGuard, Cloudflare, Quad9, NextDNS, Mullvad or custom; strict mode refuses to load pages when the chosen endpoint is unreachable instead of silently leaking to the ISP
• Native adblock — EasyList + EasyPrivacy + cosmetic rules; cosmetic CSS injected via constructed stylesheets so the page can't detect Husk
• Anti-fingerprint — canvas / audio / fonts / user-agent spoofed; long-press the reload button to rotate the seed; persistent "compat mode" badge when an origin is whitelisted out of the spoof
• Cookie editor — per-site view / edit / wipe

Power tools

• Request interceptor — Burp Suite, but built in. Pause, edit and forward / drop any request or fetch/XHR response. Replay with one click. Pop-out into its own window. Sensitive headers (Cookie, Authorization, X-API-Key, etc.) redacted before they touch the chrome JS heap
• Screenshot tool — full page or rectangle selection, built-in editor with crops + arrows + redactions
• Boss key F9 — turns every Husk window across every running profile into a working calculator (title, audio and Alt-Tab included), via cross-process named events

Plausible deniability

• Fake vault — duress phrase opens a decoy vault, real one stays invisible
• Encrypted profile, no preview — locked profiles show no avatar / bookmark / history hint
• Delete requires the phrase — even wiping an encrypted profile asks for the phrase first
• Boss key persistence — F9 state survives across all running Husk processes

Security audit

Pre-launch audit covered every trust-critical surface. Findings + fixes shipped in this release:

• 2 Critical: panic-wipe IPC was reachable from any visited site (removed); encrypted profile lock left cleartext on disk via plain remove_dir_all (now overwrites with zeros then unlinks)
• 10 High fixes including: vault blobs padded to fixed 256 KiB so real / duress size delta isn't readable off disk; content tabs can no longer close / reload / boss-key each other; DoH strict mode + persistent UI indicator; history + bookmarks strip sensitive query parameters before persisting; husk-dns.log redacts hostnames and rotates
• 25+ defense-in-depth fixes: URL allow-list (vs block-list), search template validation, Notes image MIME whitelist (drops SVG), EncryptedBody kind discriminator, Zeroizing strings on lock / wipe, paranoia activity restricted to user events, ...

Full report (private to the project) — public summary available in the husk-crypto README. Found a hole the audit missed? Mail security@husk.run.

Honest limitations

• Engine is Chromium (WebView2 distribution). What we don't ship: Edge telemetry, sync, account integration. What's still Chromium: the rendering engine itself. The day a non-Chromium engine is embedding-ready, we switch.
• DoH hides DNS, not SNI — site hostnames are still visible to the network via TLS ClientHello SNI extension. ECH support depends on WebView2.
• SSD wear-leveling can move physical bytes outside our reach. Secure wipe + full-disk encryption (BitLocker / VeraCrypt) is the recommended combo against forensic recovery on SSDs.
• macOS + Linux: coming. The Rust core builds for both already; the ports need work on platform plumbing (boss-key, single-instance, taskbar integration).

Other platforms

• macOS: targeted for v0.2
• Linux: targeted for v0.2

---

First public binary. Privacy-as-a-default. No telemetry, no account, no ad-funded mode. Browse without breadcrumbs.