mikebrandon/here-telemetry-rnd
1
0
Fork 0
Code Issues Pull requests Projects Releases 10 Packages Wiki Activity Actions
10 releases 10 tags
  • v0.2.5 c251e4ded4

    v0.2.5 — meant to be found, not downloaded Stable

    mikebrandon released this 2026-09-19 00:55:38 +00:00 | 0 commits to main since this release

    Do not download this one. It exists to be found.

    The one link in the update chain that has never run is the handover: an elevated installer
    replacing the supervisor's own executable, while Windows refuses to overwrite a running binary.
    Everything up to Command::new(installer).arg("/S") has tests; that line has only ever been read.

    0.2.4 was meant to be the release an install found and applied to itself, and it was installed by
    hand instead — so the handover is exactly as untested as before. An install on the newest build
    cannot be asked to replace itself, which is why this exists.

    Nothing shipped changes from 0.2.4. Deliberate, and the same reason 0.2.1 carried an identical
    payload: if something breaks, it is the handover and not what was handed over.

    To use it as intended: launch the console as administrator, wait about fifteen seconds for the
    uploader's check, and press Install and restart in the indicator at the bottom left. Elevated
    matters — the supervisor assumes it inherits elevation from a capture run, and in this path there
    is no capture run to inherit it from.

    Signed, and proven before publishing:

    bundle: signed, and accepted by the key this build trusts
  trusted comment: timestamp:1789779272	file:here capture_0.2.5_x64-setup.exe

    SHA-256 a208a5d1af007c34f0df4c2033eec4c09a0d4e2992cc0d5b6ad4bdce44281531

    Where this came from. This repository is a distribution point, not the source. These bytes were
    built from HERE/Capture at c27cd14.

    Downloads
  • v0.2.4 c251e4ded4

    v0.2.4 — can an install replace itself? Stable

    mikebrandon released this 2026-09-19 00:32:17 +00:00 | 0 commits to main since this release

    The release that asks whether an install can replace itself.

    What it fixes

    Processes that outlived the window that started them. The console starts a gate in reader mode
    and an uploader in cleanup-only mode; neither has a window or a tray. Closing the console stopped
    them, but killing it did not — and killing a running app is what an installer does. Two invisible
    processes kept running and kept the install directory locked, with Task Manager as the way out.
    This was hit twice, both times by somebody installing a release.

    They now leave through the pipe that is already there: the console holds their stdin open and never
    writes to it after a greeting byte, so when the console dies the operating system closes the write
    end and the read returns end-of-file. No polling, no process id to be reused, no platform code. The
    capturing tree is deliberately unaffected — the floating indicator and its tray are the off switch,
    and pulling a recording out from under somebody who closed a window would be the opposite of what
    this promises.

    The greeting byte is not decoration: a stdin that is not a pipe reads end-of-file immediately,
    which is indistinguishable from a dead parent, and the first version of this exited the moment it
    started.

    What it is for

    The one link in the update chain that has never run is the handover — an elevated installer
    replacing the supervisor's own executable while Windows refuses to overwrite a running binary.
    0.2.3 can find a release, verify it, stage it, offer it, and ask for it without capture running.
    This is the thing for it to find.

    Signed, and proven before publishing:

    bundle: signed, and accepted by the key this build trusts
  trusted comment: timestamp:1789777893	file:here capture_0.2.4_x64-setup.exe

    SHA-256 457925d592205b301003d4a508de85fe43008e05669c2f9590c3d76cff0ae46f

    Where this came from. This repository is a distribution point, not the source. These bytes were
    built from HERE/Capture at dfdfc5f.

    Downloads
  • v0.2.3 c251e4ded4

    v0.2.3 — six defects an install found Stable

    mikebrandon released this 2026-09-18 23:16:34 +00:00 | 0 commits to main since this release

    Six defects in the update path, every one found by installing a release and using it, none by
    the 1,077 tests that pass.

    What was wrong

    The update button could not appear. The check feeding the only update control ran once on
    mount and never again, and the uploader stages seconds after that. The only way to see the
    button was to already have a staged update from an earlier session.

    Applying required capture to be running. The supervisor applies updates and existed only while
    capture ran, so installing a fix meant starting to record yourself.

    The button said "Download". By the time it appears the installer is already fetched and
    verified, so the press applies it — and it claimed not to stop capture and never said it was
    irreversible.

    A successful update jammed the next one. Nothing removed the staged artifact and the reader
    refuses to choose between two, so the second update any install was ever offered turned the
    surface off permanently. Every install reaches that state, and a successful first update is what
    causes it.

    An install on the newest build was told it had nowhere to look. Current existed in the code
    and was never constructed: an artifact is only staged when it is newer, so being up to date and
    never having looked were the same empty directory. The uploader now records what the feed named.

    A successful update reported itself as a failed check. The artifact an update was applied from
    stays behind and names the running version, which reads as "0.2.3 is not newer than the running
    0.2.3" — rendered everywhere as a failure, permanently, for everything having worked.

    Also

    Insights no longer promises that a day's capture "appears tomorrow": digests are written by the
    retention sweep, and a gate in reader mode asks for no sweeps, so nothing is summarised while
    capture is off.

    Signed, and proven before publishing:

    bundle: signed, and accepted by the key this build trusts
  trusted comment: timestamp:1789773345	file:here capture_0.2.3_x64-setup.exe

    SHA-256 b7b411e5c4f1020cf9364c02bc50aeed0e348a268b20cf6e0bf345d31d855c5a

    Where this came from. This repository is a distribution point, not the source. These bytes were
    built from HERE/Capture at 3007721.

    Downloads
  • v0.2.2 c251e4ded4

    v0.2.2 — an update surface that tells the truth Stable

    mikebrandon released this 2026-09-18 21:54:12 +00:00 | 0 commits to main since this release

    The first build whose update surface tells the truth. Everything below was found by pressing the
    buttons on a real install of 0.2.0, not by a test.

    Three ways the update button was broken

    It could not appear. The check that feeds the only update control in the app ran once, on
    mount, and never again — and App never unmounts. The console starts the uploader, the uploader
    looks for a release when it starts, and it finds one moments after the UI has already asked.
    Measured: the window rendered at 00:13:37, an update to 0.2.1 was staged and verified at
    00:13:51, and no update control existed until the app was restarted. The only way to see the
    button was to already have a staged update from an earlier session — which is what happens to
    somebody launching the app twice while testing, and to nobody else.

    Applying one required capture to be running. The supervisor is the only thing that can apply
    an update, and it did so only from inside a loop that exists while capture runs. With capture off,
    pressing the button wrote a request file and the screen said the update "will be applied by the
    service" when no service was there to read it. The obvious instruction — start capture first — is
    the part that was not acceptable: it asks somebody to begin recording themselves in order to
    install a fix.

    The button said "Download". There is no download step. By the time it appears the installer is
    already fetched and verified, so the press applies it — the one irreversible action in this
    product — and it declared that it did not stop capture and never mentioned that it cannot be
    undone.

    What changed

    The update surface polls instead of asking once. The console starts a supervisor for this alone
    (--apply-update, no roles started, same verification against the compiled-in key) when none is
    running, and takes the request back if it cannot. Platforms that cannot apply an update now handle
    the flag rather than falling through to the normal path and starting capture. The button says
    Install and restart and carries both warnings, pinned by a rendering test.

    Also: a stale collector now says it is from an earlier build instead of failing as an empty
    result, and bundle signs and verifies what it packages.

    Signed, and proven before publishing:

    bundle: signed, and accepted by the key this build trusts
  trusted comment: timestamp:1789768400	file:here capture_0.2.2_x64-setup.exe

    SHA-256 28022669cef9e7dc096493276e9f0e39c1c9b2a66c15b80de4dd63ba64c79f0e

    Where this came from. This repository is a distribution point, not the source. The tag above is
    where the release was filed; it is not the tree that produced the installer. These bytes were built
    from HERE/Capture at d92c850.

    Downloads
  • v0.2.1 c251e4ded4

    v0.2.1 — can an install replace itself? Stable

    mikebrandon released this 2026-09-18 21:09:04 +00:00 | 0 commits to main since this release

    The release that exists to answer one question: can an install replace itself?

    Nothing shipped changes from 0.2.0. The commits between them are a build tool, a test and
    documentation, and that is deliberate — the one link in the update chain that has never run is the
    handover, an elevated installer replacing the supervisor's own executable while Windows refuses to
    overwrite a running binary. Everything up to Command::new(installer).arg("/S") has tests; that
    line has only ever been read. An identical payload is the right payload for the experiment: if
    something breaks, it is the handover and not what was handed over.

    0.1.0 could not have been the other half of this. It was packaged at 19:09 and a forge release
    only became readable as a feed at 21:46, so an install of it has nothing it can point at.

    Signed, and proven before publishing — by cargo xtask bundle, which now signs what it packages
    and then verifies that signature against the key compiled into the binaries it just built:

    bundle: signed, and accepted by the key this build trusts
  trusted comment: timestamp:1789765700	file:here capture_0.2.1_x64-setup.exe

    SHA-256 1e7cd131f4399831df1cc6151ff7ce3b08e7f798d484bd7c51ad407045c1238e

    Where this came from. This repository is a distribution point, not the source. The tag above is
    where the release was filed; it is not the tree that produced the installer. These bytes were built
    from HERE/Capture at 131e5c8 ("Release 0.2.1, to find out whether an install can replace
    itself").

    That distinction is the point of the signature. Nothing here has to be trusted — not the tag, not
    the repository, not the feed that pointed at it.

    Downloads
  • v0.2.0 c251e4ded4

    v0.2.0 — signed Windows installer, and updates that can reach it Stable

    mikebrandon released this 2026-09-18 20:07:59 +00:00 | 0 commits to main since this release

    The first release this project can actually update from.

    Windows installer, signed. Verified against the key compiled into the client:

    verify-release: accepted by the key this build trusts
  trusted comment: timestamp:1789758066	file:here capture_0.2.0_x64-setup.exe

    SHA-256 4044b091d9b3073857279ff4617dbb9b10db6ed4e9d5548adab3410c249a21a4

    Updates now work from a public repository. The client reads either a purpose-built
    {version, artifact, signature} feed or a forge release like this one — so an install can be
    updated without a server to deploy, a certificate to issue or a proxy to configure.

    To point an install at this:

    HERE_UPDATE_FEED=https://everything.hereandmore.com/api/v1/repos/mikebrandon/here-telemetry-rnd/releases/latest

    Nothing installs itself. The client verifies the signature against a key built into its own
    binary, reads the version back out of that signature rather than trusting this page, and waits
    for somebody to press Update.

    Since 0.1.0

    • Display recording ships — pick a window, see what would be captured, decide.
    • The app can be reset to a genuine first run, identity and all.
    • It asks once whether to look for updates, and says what version it is and what is newer.

    Where this came from. This repository is a distribution point, not the source. The tag above is
    where the release was filed; it is not the tree that produced the installer. These bytes were built
    from HERE/Capture at d19f666 ("Release 0.2.0").

    That distinction is the point of the signature. Nothing here has to be trusted — not the tag, not
    the repository, not the feed that pointed at it. The client verifies the artifact against a public
    key compiled into its own binary and reads the version back out of the signature's trusted comment,
    so the most a feed can decide is what to look at.

    Downloads
  • v0.1.3 c99a11de8f

    v0.1.3 — both clients, and the first Windows binary Stable

    mikebrandon released this 2026-09-04 11:30:52 +00:00 | 51 commits to main since this release

    Both clients are now green on their own machines. This is the first release with a Windows
    binary in it     — and the reason it is v0.1.3 rather than an asset added to v0.1.2 is worth
    saying plainly, because it is the same kind of finding this product exists to surface.

    v0.1.2 cannot produce a Windows build. Its crates/here-indicator/src/windows.rs still
    imports Card and build_banner from the modules they were moved out of, so the Windows half
    of that tree does not compile. The macOS work was written on a Mac, which cannot compile
    anything depending on here-store (SQLite is built from C and wants the Windows SDK headers),
    said so in its handoff, and named the two files it could not check. Both faults were in those
    two files. v0.1.2's note promising a Windows attachment was written in good faith; the
    attachment belongs here instead.

    What is in this release
    here-capture-windows-x64.zip twelve binaries in one folder, the layout the console and supervisor both expect
    macOS not rebuilt for this tag — see below

    v0.1.2's here-capture-macos-universal.zip is still the current macOS build. This tag differs
    from it, on the macOS side, only by lint fixes to shared files. Rather than attach a bundle
    built from a different commit and label it as this one, there is no macOS asset here: the next
    release cut from a Mac will carry one.

    Windows

    Unzip it and run here-console.exe. It is not signed at all — not ad hoc, not EV — so
    SmartScreen will object, and modules.signature_ok records false rather than pretending
    otherwise. An EV certificate is the only fix and there isn't one yet.

    Nothing is captured until you switch a signal on. The Start button applies the firewall rules
    that deny every collector a network path, which needs administrator rights; a collector that
    could not be blocked is not started at all.

    Since v0.1.2

    • The Windows half compiles and lints. Four errors from the module move, then sixty clippy
      findings in crates that had never been linted — the Win32 modules, the collectors' Windows
      bodies, the supervisor, the five spikes.
    • The console stopped reporting running collectors as stopped. tasklist's default table
      truncates the image-name column at 25 characters, so here-collector-input-metrics.exe came
      back as here-collector-input-metr and a contains check on the full name said no. Three of
      these binaries are long enough to hit it, and that answer is what the console prints directly
      under the Start button — so it would have reported a partial failure with all seven collectors
      running. Telling somebody their capture is broken when it is working is the same class of lie
      as the reverse, and this client is built to prevent both.
    • A test suite that never cleaned up after itself. Nothing that opened a store on disk ever
      deleted it: 641 directories and 392 MB had collected in %TEMP%. Both fixtures now remove the
      directory on drop, and keep it — with the path printed — when the test failed, because then it
      is the evidence.

    453 tests pass on Windows (367 Rust, 86 TypeScript), clippy included, plus the end-to-end
    suite that drives a real gate process over real named pipes. macOS runs 444 via
    scripts/verify.sh. All seven signals have been exercised against a real desktop on both
    platforms; the release binaries here were smoke-tested as a running stack, not only as a build.

    Not built, and named so it is not mistaken for done

    • No code signing on either platform, and no installer.
    • The browser extension is unpacked; it loads through Developer mode.
    • Nothing server-side. That belongs to the platform team, and
      docs/PLATFORM-INTEGRATION.md is their handoff.
    • Linux has the transport and the paths and nothing else.
    Downloads
  • v0.1.2 0a360eb7ee

    v0.1.2 — the macOS client, complete Stable

    mikebrandon released this 2026-09-04 10:27:15 +00:00 | 59 commits to main since this release

    The macOS client is complete: every signal, and every part of the indicator except a click.

    What is in this release

    • here-capture-macos-universal.zip — one bundle for Apple Silicon and Intel (via Rosetta), signed ad hoc. Gatekeeper will refuse it after a download: right-click and choose Open, or xattr -d com.apple.quarantine "/Applications/here capture.app".
    • The Windows build is not here, and cannot be: this tree's crates/here-indicator/src/windows.rs still imports Card and build_banner from the modules they were moved out of, so the Windows half of it does not compile. That was found by running scripts/verify.ps1 on a Windows machine, which is what this note originally asked for. The Windows binary is on v0.1.3, whose macOS half is unchanged from this one apart from lint fixes.

    Since v0.1.1

    • The hover flyout. Resting the pointer on a chip opens a panel beside the pill with that signal's last six records — a time, the gate's verdict as a shape, one line of summary, and never a payload. The pill still takes no clicks: the pointer is observed by polling NSEvent.mouseLocation rather than captured, so a panel sitting in the corner of somebody's screen all day never swallows a click meant for the window underneath.
    • A banner bug that only existed on macOS. build_banner lived in the Windows body, so the Mac pill built its own from health.paused — and the load-bearing case, Zoom — not captured, appeared on one platform and not the other. Absence made observable is the one thing a contributor cannot check for themselves. The pill's words are now shared, with twelve tests they never had.

    Everything since v0.1.0

    • Capture cards, the captured-window outline, and the hover flyout on macOS.
    • A console bug: if p.scope == "all" had two identical branches, so any pause marked every signal paused — while a content-only pause leaves input metrics counting keystrokes.
    • The uploader was silently dead on macOS: its own copy of data_dir() fell back to ".", so it read an empty store beside the binary, decided capture had stopped, and exited cleanly twenty times until the supervisor's restart ceiling left it down.
    • Clippy is a gate now in both verify scripts. Neither ran it before.
    • A universal, ad-hoc-signed bundle, with the script's header stating precisely what that signature does and does not buy.

    444 tests pass on macOS, clippy included. The Windows-only packages and the end-to-end suite are checked by scripts/verify.ps1 on a Windows machine.

    The one deliberate difference from Windows: the Mac pill never takes a click, so the capture card's two controls (seen, quiet this) live in the menu bar rather than on the card.

    Downloads
  • v0.1.1 05633e860c

    v0.1.1 — the macOS client, at parity Stable

    mikebrandon released this 2026-09-04 10:02:29 +00:00 | 61 commits to main since this release

    Superseded by v0.1.2, which adds the hover flyout and fixes a banner bug that only existed on macOS. This build works; that one is the current one.

    Every signal now has a macOS body and each was exercised against a real desktop.

    What is in this release

    • here-capture-macos-universal.zip — one bundle for Apple Silicon and Intel (via Rosetta), signed ad hoc.

    Since v0.1.0

    • Capture cards on macOS, and the captured-window outline.
    • A console bug: if p.scope == "all" had two identical branches, so any pause marked every signal paused.
    • The uploader was silently dead on macOS: its own copy of data_dir() fell back to ".".
    • Clippy is a gate now, in both verify scripts.
    • A universal, ad-hoc-signed bundle.
    Downloads
  • v0.1.0 34c5d3e0ed

    v0.1.0 — the Windows client, and macOS Pre-release

    mikebrandon released this 2026-09-04 08:16:15 +00:00 | 67 commits to main since this release

    Work-session telemetry that captures on a contributor's own machine, gates every byte locally,
    and shows the person what it took.

    This is the first release, and it carries two clients: the Windows one, which is the reference,
    and a macOS port of all seven signals.

    What is in the box

    Nothing server-side. That belongs to the platform team and docs/PLATFORM-INTEGRATION.md is
    their handoff.
    here-capture-macos-arm64.zip here capture.app — Apple Silicon, twelve binaries in one bundle
    Windows to follow, from a Windows machine

    macOS

    Unzip it, put it in /Applications, open it. It is not signed, so Gatekeeper will refuse
    it after a download — right-click and choose Open, or:

    xattr -d com.apple.quarantine "/Applications/here capture.app"

    It will ask for nothing until you switch a signal on, and three signals need a permission
    that only you can grant     — Screen Recording, Accessibility and Input Monitoring, in System
    Settings › Privacy & Security. Until they are granted the Capture screen lists exactly which
    signals are refused and which setting each one needs, rather than switching them on to produce
    nothing.

    Apple Silicon only. An Intel or universal build is a one-line change to
    scripts/bundle-macos.sh if anybody needs one.

    What each platform enforces, and where they differ

    Two claims are weaker on macOS than on Windows, and the client says so on its own first screen
    rather than leaving it in a document:

    • Network denial is not enforced. On Windows every collector is blocked by a firewall rule
      before it starts, and one that could not be blocked is not started at all. macOS has no
      per-process rule, so "a collector cannot leak" rests on a reviewed binary with no network
      code. Weaker, and stated as weaker.
    • The store's key is a file only its owner can read, rather than wrapped by DPAPI. The
      Keychain is the right API and cannot be used until the client is signed: an item's access list
      is per-binary, this client is four processes, and a second unsigned binary reading an item the
      first created blocks on a modal dialog.

    Not built, and named so it is not mistaken for done

    • No code signing on either platform. SmartScreen and Gatekeeper will both object, and
      modules.signature_ok records false rather than pretending.
    • No installer.
    • The browser extension is unpacked; it loads through Developer mode and registers with
      scripts/install-extension.sh or .ps1.
    • The macOS pill is read-only — it says what is being captured and offers no way to act on it.
    • Linux has the transport and the paths and nothing else.

    HANDOFF.md is where to pick any of that up.

    Downloads