v0.1.9

Everything here came out of one report from a real Windows desktop: a mobile HTTP proxy, saved as socks5 because a proxy line does not say which it is. Nothing worked and nothing said why — the check hung, the profile opened onto pages that never loaded, and the log had one line in it. The proxy was fine the whole time.

Same Chromium 153.0.8010.37 core as 0.1.2 through 0.1.8 — the core files here are byte-identical to theirs (same SHA-256, in SHA256SUMS) and are attached again so this page stands on its own. A core installed from 0.1.6, 0.1.7 or 0.1.8 is the same file: install only the application.

Two downloads, and you need both

File	What it is
fury-0.1.9-windows-x64-setup.exe	The application, Windows. Not signed — SmartScreen: More info → Run anyway.
fury-core-0.1.9-windows-x64.tar.xz	The browser, Windows. 146 MB. Unchanged since 0.1.6.
fury-0.1.9-macos-arm64.dmg	The application, macOS on Apple Silicon. Signed and notarised.
fury-core-0.1.9-macos-arm64.tar.xz	The browser, macOS on Apple Silicon. 107 MB. Unchanged since 0.1.6.

A proxy of the wrong kind no longer hangs

The relay had no timeout. Not on reaching the proxy, not on the handshake. An HTTP proxy sent a SOCKS5 greeting sits waiting for a request line that will never come, and every tab in the profile waited with it — no error page, no line in the log, nothing to act on. The step-by-step diagnosis had its own bound, so the one place an operator actually meets a broken proxy was the one place that never gave up.

Ten seconds to connect now, eight for the far end to answer its own protocol's greeting. Silence after a connection is read as evidence about what the far end is, not as "unreachable".

"The proxy refused your password" was a lie. A SOCKS5 version byte that was not 5 came back as an authentication failure, which sent people to their provider to reset a password that had never been wrong. It is its own error now and it names what it saw — an answer in HTTP, a hang-up, silence. A real refusal still reads as one, with a test to keep it that way.

The check finds the right protocol for you. A provider hands out host:port:user:pass, which says nothing about SOCKS5 or HTTP, so the form has to guess and is wrong about half the time — invisibly, because being wrong looks exactly like a dead proxy. On a failure the agent now tries the other family with one dial, and the form offers a button: switch to http and check again.

Refusals arrive in the language the window is in. The mechanism existed — errors carrying a code get translated — and the agent never sent one. It does now, and the refusal to launch a profile with no proxy is the first to use it.

A profile may be told to open with no proxy

Asked for, and off by default. The refusal is a good rule — everything the browser does goes through the relay, and without an upstream it goes out from this machine — but it was absolute, and that made the application useless for work with no account to protect: reading documentation, checking a fingerprint against a detector, filling a profile in before its proxy has been bought.

It is a permission on one profile, not a setting. A throwaway profile and a warmed account must not share a switch. Every profile that exists today keeps the refusal.

The relay still stands in the middle — blocklists, the start page, and the refusal to reach this machine's own services all live there. The kill-switch is untouched: a proxy that fails still never becomes a direct connection. A direct connection happens only where there was no proxy to begin with and the profile was told it may.

A team profile cannot have it: that one opens on a colleague's machine, where "this machine" is theirs.

Said out loud in three places, because a profile leaving from your own address is the one thing in the list nobody should find out about by accident — the checkbox carries the warning, the row reads Без прокси · с этой машины, and the start page names the exit as no proxy — this machine's own address.

Verified

• The reported proxy, measured both ways: over HTTP, 200 in 1.2 s through the relay; addressed as SOCKS5, silence — 8.3 s and a named reason, where before it was forever.
• The check, through the agent's own IPC against that same proxy: ok: false with suggested_kind: "http".
• The no-proxy refusal over IPC, with and without the permission: refused with err.noProxy, then past the gate. Through the relay in that mode, the exit check answered with this machine's own address.
• cargo test --workspace: 356 tests, including four new ones on the handshakes — HTTP answering a SOCKS5 greeting, a SOCKS proxy sent an HTTP request, silence, and a real password refusal still reading as one.
• The core is 0.1.6's binary: core sha256 in REPORT.md is unchanged.

Not verified

The new interface — the switch-protocol button and the no-proxy checkbox — was type-checked and exercised through the agent, not clicked through in the shipped window. The release gate in docs/07 still has criteria needing external services that have not been run for this build. Treat this as a pre-release, which is what it is marked as.

macOS

Signed and notarised: application and disk image each carry a Developer ID signature and a stapled ticket. Open the DMG, drag, open.

Checksums for every file are in SHA256SUMS. REPORT.md is the measurement report for the core.

v0.1.8

Two fixes found on a real Windows desktop within an hour of 0.1.7, one of which made the application look broken while it was working. Same Chromium 153.0.8010.37 core as 0.1.6 and 0.1.7 — the core files here are byte-identical to theirs (same SHA-256, in SHA256SUMS) and are attached again so this page stands on its own. A core installed from 0.1.6 or 0.1.7 is the same file: install only the application.

Two downloads, and you need both

File	What it is
fury-0.1.8-windows-x64-setup.exe	The application, Windows. Not signed — SmartScreen: More info → Run anyway.
fury-core-0.1.8-windows-x64.tar.xz	The browser, Windows. 146 MB. Unchanged since 0.1.6.
fury-0.1.8-macos-arm64.dmg	The application, macOS on Apple Silicon. Signed and notarised.
fury-core-0.1.8-macos-arm64.tar.xz	The browser, macOS on Apple Silicon. 107 MB. Unchanged since 0.1.6. Signed and notarised.

Install the core with the button the application offers, or fury-agent install-core <path>. docs/15 has the steps.

What changed

The browser the agent installed did not exist as far as the agent was concerned. Press "Download the browser", watch it reach 146 of 146 MB, and the bar goes back to saying the browser is not installed — with no error, because nothing had failed. Reproduced through the same two calls the button makes: the download finished, the install succeeded, chrome.exe was on disk, and the same agent went on answering "core": null. The path was read once when the agent started and kept in a field, so an agent that installed a core could not see it.

The bar was the mildest of three. A profile would have refused to launch with "no core binary found" over a browser that is there, and the download button guards on the same answer — so the next press fetched the same 146 MB, installed it again, and changed nothing again. Only restarting the agent broke that, and the application never restarts it: it connects to whatever is already listening. The lookup now happens per call.

The agent keeps a log. The application has to start it with its output on null — otherwise Windows draws a console window over the application — so until now every line it wrote went nowhere, on exactly the machines where things go wrong. Both of today's failures arrived as a screenshot and a sentence, and nothing else could be asked for.

It is %APPDATA%\Fury\logs\agent.log on Windows and ~/Library/Application Support/Fury/logs/agent.log on macOS, at info — "downloading the core", "the profile closed" — capped at 4 MB with one previous file kept. The About screen shows the path.

This is a record of when this machine ran profiles, which for this product is worth stating plainly rather than burying. It never leaves the machine: nothing in the agent sends it anywhere. It lives in the data directory, which is owner-only and already holds the profile database. Delete it whenever you like and a new one starts; FURY_LOG=off turns it off altogether.

Verified

• The whole in-app path on Windows, driven through the agent's own IPC: download, install, and then status naming the installed chrome.exe — the answer that was NULL before this build.
• cargo test for the agent: 150, run four times over, including a core installed after a lookup had said there was none, and the log's rotation at its cap.
• The core is 0.1.6's binary: core sha256 in REPORT.md is unchanged.

Not verified

The About screen's new line was type-checked and not clicked through in the shipped window. The release gate in docs/07 still has criteria needing external services that have not been run for this build. Treat this as a pre-release, which is what it is marked as.

macOS

Signed and notarised: application, core and disk image each carry a Developer ID signature and a stapled ticket. Open the DMG, drag, open.

Checksums for every file are in SHA256SUMS. REPORT.md is the measurement report for the core.

v0.1.7

The 0.1.6 fix release: on Windows the core would not install if the machine's tar could not read .xz. Same Chromium 153.0.8010.37 core as 0.1.6 — the core files here are byte-identical to it (same SHA-256, listed in SHA256SUMS) and are attached again so this page is complete on its own. If you are on 0.1.6 and your core is installed, you do not need the core again — install only the application.

Two downloads, and you need both

File	What it is
fury-0.1.7-windows-x64-setup.exe	The application, Windows. Not signed — SmartScreen: More info → Run anyway.
fury-core-0.1.7-windows-x64.tar.xz	The browser, Windows. 146 MB. Unchanged since 0.1.6.
fury-0.1.7-macos-arm64.dmg	The application, macOS on Apple Silicon. Signed and notarised.
fury-core-0.1.7-macos-arm64.tar.xz	The browser, macOS on Apple Silicon. 107 MB. Unchanged since 0.1.6. Signed and notarised.

Install the core with fury-agent install-core <path>, or press the button the application offers. docs/15 has the steps. A core installed from 0.1.6 is the same file — if you already have one, install only the application.

What changed

The Windows core installs on any machine, whatever its tar is. Reported the day 0.1.6 went out:

tar.exe: Error opening archive: Can't initialize filter;
unable to run program "xz -d -qq"

Windows ships bsdtar, and whether that bsdtar reads .xz depends on the build: one with liblzma decodes it, one without tries to run an xz program that an ordinary Windows machine does not have. Measured on two machines on 22.09.2026 — the build box answers bsdtar 3.8.1 ... liblzma/5.4.3 and unpacked the 0.1.6 core; a user's Windows 11 refused the same file with the line above. This is also what the identical report against 0.1.3 was, on 21.09, when the archive was suspected and the machine was blamed. Both were fine.

The agent decodes the .xz itself now and hands tar a plain .tar, which every build of it can read. Pure Rust, streamed: 7.1 seconds on the 139 MB Windows core, against 1 second for a multi-threaded system xz — worth six seconds once, per install, not to put a C toolchain between the agent and a Windows build. .tar.gz and .zip stay tar's job.

Everything else is 0.1.6, including the core and its 0902 patch. Its notes describe what is in the browser itself.

Verified

• The fixed agent, built on the Windows box, installed the core with PATH cut to C:\Windows\System32 — nowhere for an external xz to come from: installed 153.0.8010.37.
• The same two steps on the real macOS core with PATH=/usr/bin:/bin: Fury.app, its executable bit and all five framework symlinks intact.
• cargo test for the agent: 148, including a new one that builds a .tar.xz and unpacks it with no xz reachable.
• The core is 0.1.6's binary: core sha256 in REPORT.md is unchanged.

Not verified

The Windows core was not run through verify-windows.ps1 for this build; the change is in the browser's own UI code, shared between platforms, and the macOS verification covers it. The release gate in docs/07 still has criteria needing external services that have not been run. Treat this as a pre-release, which is what it is marked as.

macOS

Signed and notarised: application, core and disk image each carry a Developer ID signature and a stapled ticket. Open the DMG, drag, open.

Checksums for every file are in SHA256SUMS.

0.1.6

Superseded by v0.1.7. On Windows this build cannot install the core if the machine's tar was built without liblzma: it answers Can't initialize filter; unable to run program "xz -d -qq" on an archive that is perfectly good. 0.1.7 decodes the .xz itself and is otherwise this release, on the same core, byte for byte. The application will not offer that update from in here — it compares version numbers, and 0.1.6 has nothing newer to compare against.

A new core, for the first time since 0.1.2: Chromium 153.0.8010.37 with patch 0902, which removes the "Google API keys are missing" bar that sat in the first window of every profile. Agent and application follow the version number; nothing else in them changed since 0.1.5. Windows and macOS.

Two downloads, and you need both

File	What it is
fury-0.1.6-windows-x64-setup.exe	The application, Windows. Not signed — SmartScreen: More info → Run anyway.
fury-core-0.1.6-windows-x64.tar.xz	The browser, Windows. 146 MB. New.
fury-0.1.6-macos-arm64.dmg	The application, macOS on Apple Silicon. Signed and notarised.
fury-core-0.1.6-macos-arm64.tar.xz	The browser, macOS on Apple Silicon. 107 MB. New. Signed and notarised.

Install the core with fury-agent install-core <path>, or press the button the application offers. docs/15 has the steps. This time the core has to be reinstalled: it is the thing that changed.

What changed

The "Google API keys are missing" bar is gone. Chromium shows it in the first window of any build without Google's keys — which this build is on purpose — in the profile's UI language, saying "Chromium" to an operator whose browser is supposed to say Chrome. Reported by a Windows tester as Google API-Schlüssel fehlen above a German profile. Patch 0902 removes the one call that shows it; the obsolete-OS warning and the bad-flags prompt, which real Chrome shows under the same conditions, stay.

Writing the check for it found what the bar was doing to the page. In the first window, window.innerHeight said 613 while document.documentElement.clientHeight said 557: the bar is one of Chromium's newer browser-level infobars, laid over the web contents rather than resizing them, so the widget kept its height while the viewport inside it lost 56 px. Real Chrome, with no scrollbar, has those two numbers equal. Every first window of every profile carried that 56-pixel disagreement until the bar was dismissed. It does not now — core/verify/verify-0902.py measures it, in the tab the browser opened with, against --test-type as the reference and --no-sandbox as the control that the measurement still sees a bar when there is one.

The sign-up screen prefills srv.furybrowser.dev. The hosted server has a domain; until now the application offered 204-168-178-23.sslip.io, the machine's address written as a name. Both names answer with their own certificate, so a 0.1.5 install that saved the old one keeps working — nothing to retype.

Verified

• core/verify/run-all.py on the macOS core: 27 of 28 scripts pass, 0902 among them (4 of 4 claims). The one that does not, 0303, times out at the same step on the 0.1.4 core — its unlocked control run waits on an OS dialog behind the password export — so it predates this patch and is the harness's problem, not the browser's.
• fury-detect gate on a fresh capture from this core: 13 checks, 9 contexts. REPORT.md is that report and names the core's SHA-256.
• Windows core: built from the same tree and the same 28 patches on the build machine.

Not verified

The Windows core was not run through verify-windows.ps1 for this build; the change is in the browser's own UI code, shared between platforms, and the macOS verification covers it. The release gate in docs/07 still has criteria needing external services that have not been run. Treat this as a pre-release, which is what it is marked as.

macOS

Signed and notarised: application, core and disk image each carry a Developer ID signature and a stapled ticket. Open the DMG, drag, open.

Checksums for every file are in SHA256SUMS.

0.1.5

Agent and application, on the same Chromium 153.0.8010.37 core as 0.1.2 through 0.1.4 — the core files here are byte-identical to 0.1.4's (same SHA-256, listed in SHA256SUMS) and are attached again so this page is complete on its own. If you already have the core installed, install only the application. Windows and macOS.

Two downloads, and you need both

File	What it is
fury-0.1.5-windows-x64-setup.exe	The application, Windows. 8 MB. Not signed — SmartScreen: More info → Run anyway.
fury-core-0.1.5-windows-x64.tar.xz	The browser, Windows. 146 MB. Unchanged since 0.1.2.
fury-0.1.5-macos-arm64.dmg	The application, macOS on Apple Silicon. Signed and notarised.
fury-core-0.1.5-macos-arm64.tar.xz	The browser, macOS on Apple Silicon. Signed and notarised. Unchanged since 0.1.4's re-upload.

Install a core with fury-agent install-core <path>, or press the button the application offers. docs/15 has the steps.

What changed

A team profile with a proxy selected was refused for having none. Reported from a self-hosted server: "New profile" with a saved proxy chosen on the Proxy tab answered "A team profile needs a proxy"; the batch dialog created profiles fine, and editing any of them died the same way. The dialog has sent proxy_id since 02.08.2026; the team branch of the shell kept reading the old nested field, found nothing, and refused — so every team profile created or edited from the dialog had been refused since that day. Fixed, with a test per shape.

The grant editor shows all ten flags. On the Users screen a granted row has a "Permissions" button that opens the grant under it: see, open, edit, change fingerprint, change proxy, reveal secrets, export cookies, create, delete, grant to others. Each box saves as you tick it. Six of these could previously be set only with a request to the API, which the docs said out loud.

The probe measures a ninth context — a frame in another process. A cross-origin iframe gets a renderer process of its own, and that is where a checker embedded in somebody else's page asks from. The second origin costs no second server: localhost and 127.0.0.1 are different sites, both secure contexts, both this machine. Measured on real Chrome 153 and on this core through the relay: nine contexts, zero disagreements on both, and the foreign process reports the persona, not the host. REPORT.md is from that capture.

fury-agent launch opens the start page, as the application does, instead of chrome://newtab, and prints the address.

Verified

• cargo test for the agent (147), the detect suite (13) and the shell's new tests (3); tsc clean.
• The core is the 0.1.4 binary: core sha256 in REPORT.md is unchanged, and the gate is PASS on today's capture, 13 checks, 9 contexts.

Not verified

The grant editor was type-checked and not clicked through in the shipped window. The release gate in docs/07 still has criteria needing external services that have not been run for this build. Treat this as a pre-release, which is what it is marked as.

macOS

Signed and notarised, as 0.1.4's re-upload was: the application, the core and the disk image each carry a Developer ID signature and a stapled ticket. Gatekeeper's verdict on a machine that has never seen them: accepted, source=Notarized Developer ID. Open the DMG, drag Fury to Applications, open it.

Checksums for every file are in SHA256SUMS. REPORT.md is the measurement report for the core.

0.1.4

Agent and application, on the same Chromium 153.0.8010.37 core as 0.1.2 and 0.1.3. The Windows core is byte-identical to the one on those pages (same SHA-256, in SHA256SUMS). The macOS core is the same code, now signed with a Developer ID and notarised by Apple — and so is the macOS application. If you already have the core installed on Windows, install only the application; on macOS take both.

Two downloads, and you need both

File	What it is
fury-0.1.4-windows-x64-setup.exe	The application, Windows. 8 MB.
fury-core-0.1.4-windows-x64.tar.xz	The browser, Windows. 146 MB. Unchanged since 0.1.2.
fury-0.1.4-macos-arm64.dmg	The application, macOS on Apple Silicon. 11 MB. Signed and notarised.
fury-core-0.1.4-macos-arm64.tar.xz	The browser, macOS on Apple Silicon. 123 MB. Same build as 0.1.2, signed and notarised.

Install a core with fury-agent install-core <path>, or press the button the application offers. docs/15 has the steps.

What changed

A fix release, from one user's afternoon on Windows.

The core install says what went wrong. It used to say tar could not unpack <file> and nothing else, which sent people to re-download a file that was fine. The message now carries tar's own words, its exit status and the file's size; on Windows the install runs System32\tar.exe by path rather than whichever tar is first on PATH (Git for Windows puts a GNU tar there, and GNU tar reads C:\Users\… as a host name); a download whose length differs from what the server promised is refused before tar sees it; and the downloaded file is kept on failure so it can be looked at.

A proxy pasted as one line. ip:port:login:pass, login:pass@ip:port or socks5://… pasted into the address field of the proxy form — or of the profile dialog — spreads into host, port, user and password, through the same parser the "paste a list" screen uses. On paste only; a line the parser does not recognise is pasted as before.

The team-profile proxy rule is said before the button. A profile on a team server has to have a proxy, because launching one without would send a colleague's traffic from their own address. The dialog now says so under the proxy fields and keeps Create off until there is one — instead of an English error after the click on a Russian interface.

The Users screen's four-step how-to no longer wraps one word per line.

Verified

• cargo test for the agent; cargo check of the agent on the Windows build machine; tsc clean.
• The 0.1.3 Windows core archive, downloaded from this page onto the build machine, unpacks with Windows' own tar.exe — so the archive was never the problem, and the new message is what will say what is.

Not verified

The proxy paste and the profile-dialog change were checked with the type checker and over the IPC command, not clicked through in the shipped window. The release gate in docs/07 still has criteria needing external services that have not been run for this build. Treat this as a pre-release, which is what it is marked as.

macOS

Signed and notarised, for the first time. Both the application and the core carry a Developer ID signature with a stapled notarisation ticket. Gatekeeper's verdict on both, on a machine that has never seen them: accepted, source=Notarized Developer ID. Open the DMG, drag Fury to Applications, open it — no right-click, no xattr, no Privacy & Security detour. The application installs the core through its own button.

The core's REPORT.md names the signed binary's SHA-256; the capture it reports on was taken from the same build before signing. Signing adds a signature to each binary and changes nothing the page sees.

Checksums for every file are in SHA256SUMS.

0.1.3

Agent, application and team server, on the same Chromium 153.0.8010.37 core as 0.1.2 — the core files here are byte-identical to 0.1.2's (same SHA-256, listed in SHA256SUMS) and are attached again so this page is complete on its own. If you have the 0.1.2 core installed, install only the application. Windows and macOS.

Two downloads, and you need both

File	What it is
fury-0.1.3-windows-x64-setup.exe	The application, Windows. 8 MB.
fury-core-0.1.3-windows-x64.tar.xz	The browser, Windows. 146 MB. Unchanged from 0.1.2.
fury-0.1.3-macos-arm64.dmg	The application, macOS on Apple Silicon. 11 MB.
fury-core-0.1.3-macos-arm64.tar.xz	The browser, macOS on Apple Silicon. 103 MB. Unchanged from 0.1.2.

Install a core with fury-agent install-core <path>, or press the button the application offers. docs/15 has the steps.

What is new

A day of parity with the paid products and past it — every item below was measured before it was written down (docs/16 has the measurements, item by item).

Extensions. A section of their own: which profiles carry the wallet and which are missing it, a .crx into many profiles at once, and a catalogue — uBlock Origin Lite, Cookie-Editor, Authenticator, Bitwarden, Dark Reader, Google Translate — installed by Web Store id. The package is fetched through the proxy of the profile it goes into, so Google sees that profile's exit and never your machine, and the key inside the package must derive the id that was asked for. Any other extension by id or store link. The catalogue is a file in the repository; add to it by pull request.

Team security. Sign-in policy per organisation: a second factor (TOTP) off / on new devices / always, an address allowlist, owners exempt or not. A journal of who signed in from where and on what, with outcomes. Everyone's sessions, with "end this one". And a fresh code before the actions that cannot be undone — purging a profile, removing a member, changing the policy, ending sessions — good for ten minutes on the session that entered it.

The organisation's domain lists. Written by the owner, attached to a member through their access to a project: that member's launches in that project refuse what the list refuses, or — with @allow-only — open only what it names. The member's machine has no say.

Synchronised windows. Open a group of profiles, work in one, and every window in the group follows — clicks, wheel, typing (typing can be turned off to log twenty accounts in with twenty passwords). Each window gets its own motor profile so the movements do not match to the pixel.

Warming. Visit a list of sites in a batch of profiles, dwell, follow a link, close — so the cookie jar is not empty when the account first logs in. Your list; the default is offered, not imposed.

Adding your machine to the catalogue is a button — and now also a web page: open https://furyteamtop.github.io/fury-antidetect-browser/ in ordinary Chrome, press two buttons, drop the file into an issue form; a workflow converts it, checks it and opens the pull request under your name. Nothing is sent anywhere by itself, and the file carries no address: the hosted probe redacts it before download.

Rows that judge themselves. A persona that left the catalogue or a pinned timezone that disagrees with the proxy's exit disables Open with the reason; a first language unusual for the exit country, or three or more profiles behind one exit, is an amber mark. The proxy cell counts the profiles a site sees from the same exit.

Stages. "new", "warming", "ready", "banned" — or your own word — as a field beside the lock state, with a filter. Bulk proxy work: one proxy for the selection, or one unused proxy each; check every proxy at once; import profiles from CSV (English or Russian headings, proxies by name or by line). Saved templates for the batch dialog. Duplicate from the row. The proxy "could not connect" now says which of five steps failed. Editing a name no longer erases notes and start URLs. The table renders what is on screen: 3 000 profiles cost the same as 30.

Server

Migrations 0010–0013 apply on start. Nothing to do by hand; back up first as always.

Verified

• cargo test --workspace: agent 147, shared 87, server 45 (against a real PostgreSQL, row-level security included), all passing.
• Extension install measured with a test proxy: both CONNECTs went through it, none direct; the core launched with the extensions running under their store ids.
• Step-up, policy and journal walked end to end over HTTP against PostgreSQL.
• The table measured in a browser with 3 000 rows.

Not verified

The release gate in docs/07 still has criteria needing external services that have not been run for this build: CreepJS, reCAPTCHA scores, Cloudflare challenges. The dialogs added today were checked as components and over IPC, not clicked through in the shipped window. Treat this as a pre-release, which is what it is marked as.

macOS

Not notarised, and macOS will say so. No Developer ID yet; the bundle is sealed with an ad-hoc signature, so the message is the bypassable "unidentified developer", not "damaged". Right-click → Open, then allow it in System Settings → Privacy & Security, or:

xattr -dr com.apple.quarantine /Applications/Fury.app

Checksums for every file are in SHA256SUMS. REPORT.md is the measurement report for the core, unchanged from 0.1.2.

v0.1.2 — Chromium 153, and Widevine

The first release built on Chromium 153.0.8010.37, three milestones on from the 150 the previous ones carried. Windows and macOS.

docs/03 puts the tolerance at one milestone behind stable and says two or more is dead as an antidetect, because real users update: a profile claiming a version almost nobody runs is identifiable by the claim alone. The fork had been pinned since 30.07.2026.

Two downloads, and you need both

File	What it is
fury-0.1.2-windows-x64-setup.exe	The application, Windows. 8 MB.
fury-core-0.1.2-windows-x64.tar.xz	The browser, Windows. 146 MB.
fury-0.1.2-macos-arm64.dmg	The application, macOS on Apple Silicon. 10 MB.
fury-core-0.1.2-macos-arm64.tar.xz	The browser, macOS on Apple Silicon. 103 MB.

Install a core with fury-agent install-core <path>.

They ship apart because they change on different schedules and because writing a 146 MB browser into a signed application bundle breaks its signature. docs/15 has the install steps.

The installer is new, not the 0.1.1 one renamed. CHROME_MAJOR and CHROME_FULL_VERSION live in the agent, the agent is bundled into the installer, and the 0.1.1 one carries 150. Pairing the new core with the old installer would have every profile announce a version it is not.

Widevine

requestMediaKeySystemAccess("com.widevine.alpha") is answered, where before it was refused. Netflix, Spotify and Disney+ work in a profile; more to the point, a browser that refuses Widevine while claiming to be Chrome is identifiable in two lines of JavaScript.

The CDM still does not travel with us — not in the repository, not in this release, not in the installer. The agent copies the one your own Chrome is already licensed to have. A machine with no Chrome installed gets a browser without DRM.

Verified

• The 27-patch series applies in order to a pristine 153 tree, 27 of 27.
• verify-windows.ps1: 30 claims, all true — the persona reaches the browser as an inherited handle, no persona value appears in any process command line, the pipe refuses everyone but its owner.
• Against a reference dump of real Chrome 153 captured on the same machine: 0 differences of the kind that must not differ.
• cargo test --workspace: 313 passing.

Not verified

The release gate in docs/07 has twelve criteria and the ones needing external services have not been run for this build: CreepJS, reCAPTCHA scores, Cloudflare challenges, and the top-30 rendering pass. Treat this as a pre-release, which is what it is marked as.

macOS

Built on the same 153.0.8010.37 tree with the same 27 patches — every one applied without a macOS-specific change. Widevine answers here too, from the CDM the agent stages out of your own Chrome.

It is not notarised, and macOS will say so. There is no Developer ID behind this build yet, so a downloaded copy is refused by Gatekeeper as from an unidentified developer. This is the same situation as 0.1.0. To run it:

xattr -dr com.apple.quarantine /Applications/Fury.app

or right-click → Open, then allow it in System Settings → Privacy & Security. Measured on this build: refused while quarantined, runs once the attribute is gone. The core needs nothing — install-core strips the attribute itself.

The bundle is sealed with an ad-hoc signature before packaging, which the 0.1.0 image was not, so the message you get is the bypassable "unidentified developer" rather than the dead-end "damaged".

Checksums for every file are in SHA256SUMS.

v0.1.1 — the agent connection on Windows

A one-fix release for Windows. If Fury ran with administrator rights — which is
the ordinary state of a fresh virtual machine — the application refused the
agent it had just started itself:

Agent Connection failed: something other than this users agent is holding
the fury pipe

Reported by a user on 9 September and fixed the same day. Nothing else changed.

What was wrong

The agent and the application talk over a named pipe, and the application checks
who owns that pipe before trusting it. The check is not decoration: a pipe name
is machine-wide and guessable, so another account could otherwise create it
first and answer in the agent's place.

Windows takes an object's owner from the creating token's default owner when
the security descriptor does not name one, and for an elevated token that
default is BUILTIN\Administrators rather than the person. So the pipe came out
owned by a group, the check compared that group against the user, and refused —
consistently, on every machine where Fury runs elevated.

The descriptor now names its owner, which makes it the same however the process
was started. The application also accepts its own token's default owner, so an
older agent still running is not refused by an application that has just been
updated.

Measured on Windows rather than reasoned about: the previous build produces
O:BA (S-1-5-32-544) and fails the new check, this one produces the user's own
SID and passes all 17 claims of tools/verify-windows.ps1.

That script is the other half of the fix. It asserted the pipe's permissions and
never its owner, so the one branch that can refuse a healthy agent had never run
on a real machine. It also inspected the first fury-* pipe it found rather
than the one it had just created, which on a build server with an old agent
running meant it had been checking a month-old process. Both are fixed, and it
now reports whether it is running elevated, because unelevated the owner check
cannot fail and a green run in the wrong window is what hid this.

Downloads

Windows (x64)	fury-0.1.1-windows-x64-setup.exe
macOS (Apple Silicon)	fury-0.1.0-macos-arm64.dmg — unchanged, see below

Nothing changed for macOS, so the disk image attached here is the 0.1.0 file
under its own name rather than renamed to a version it was not built as.

The browser core did not change either. The agent takes the newest core it finds
across recent releases, so an existing installation keeps the one it has. A
fresh install still needs the core from
v0.1.0:
fury-core-0.1.0-windows-x64.tar.xz or fury-core-0.1.0-macos-arm64.tar.xz.
docs/15 is the install in two downloads and one command.

SHA256SUMS covers both files here.

Still unsigned

Unchanged from 0.1.0: the macOS build is ad-hoc signed, so Gatekeeper refuses a
downloaded copy with "is damaged", which is about a missing signature rather
than a corrupt file, and Windows shows a SmartScreen warning for the same
reason. This remains a preview.

v0.1.0 — team mode, end to end

Team mode works end to end: invite a colleague, let them in with one button, send
a profile to the server, and they open it on their machine — through the
profile's own proxy, with its own session.

Tested on two real machines rather than in theory, which is how most of what is
fixed below was found.

Two downloads, not one

The application is 12 MB; the browser core is 100–138 MB and moves on its own
schedule. Shipping them together would mean a 134 MB download for a button that
moved. docs/15 is the install in two downloads and one
command.

macOS (Apple Silicon)	fury-0.1.0-macos-arm64.dmg + fury-core-0.1.0-macos-arm64.tar.xz
Windows (x64)	fury-0.1.0-windows-x64-setup.exe + fury-core-0.1.0-windows-x64.tar.xz

SHA256SUMS covers all four.

Nothing is signed yet

Enrolment in the Apple Developer Program is under way: the certificate is paid
for and the account is in Apple's verification, which is what a Developer ID and
notarisation wait on. The tooling exists already —
sign-core.sh,
sign-shell.sh, docs/17.

Until it lands, the macOS build is ad-hoc signed, so Gatekeeper refuses a
downloaded copy with "is damaged" — that message is about a missing
signature, not a corrupt file. Windows shows a SmartScreen warning for the same
reason. Building from source avoids both. This release is a preview.

The team path

• Sending a profile to the server had never worked. The fingerprint seed
  crossed as a number where the server wants sixteen hex characters, and the
  timezone crossed as null for a profile that follows its exit — so every upload
  since the endpoint existed died in the request parser as a 422 with no text.
  That is also why "send the whole folder" produced an empty folder.
• And the proxy travelled without its password, read from a listing that
  strips it on purpose, so the profile opened on a colleague's machine and every
  request died in the relay.
• One button to let somebody in. Handing over the organisation key and
  granting access were two presses in sequence, every time.
• The audit log answered 500 — it selected a column users have never had, so
  the screen had never once worked.
• A member with no key was shown a password box that could not help them.
  They now get a screen naming who has to act, which lets them through by itself
  when it happens.

Getting in and out

• "I have an invitation" is on the first screen, where an invited colleague
  actually lands.
• Sign in and sign out are in Settings → Team server, which is where people look
  for them.
• A password generator beside the two password fields, because that password
  cannot be reset by anyone and two empty boxes invite reuse.
• Sessions last a week of inactivity rather than twelve hours, which is the
  length of a night as well as of a working day.

Known and not fixed

Everything absent is listed at the bottom of the README, honestly.
The nearest ones: no automatic updates by design, no Linux, and a profile
carries its browser session — so sending one to the team sends the tabs it had
open.