Photoshoot

Themes change the app’s entire chrome and filters change what the GPU does to every pixel. Both are things a user should be able to download from a stranger and try, and both are the classic route to arbitrary execution. A theme that can set a CSS value can smuggle url(javascript:), @import or a script tag; a filter that can supply shader text can rewrite the pipeline. The desktop app is an Electron process, so a mistake here is not a defaced page; it is a foothold.

A theme manifest may set only the 59 whitelisted CSS custom properties: 39 colour, 9 length, 5 shadow, 2 font and 4 texture. Each is matched against a per-kind regular expression, then screened against 24 forbidden substrings including javascript:, expression(, @import, <script, url(, http://, file:, blob:, backslash escapes, braces and semicolons. Texture tokens can never be set from a manifest string at all; they come only from bytes the importer has already verified by magic number. A filter is 11 numbers, each hard-clamped to a fixed minimum, maximum and default, plus an optional lookup table. Every value is validated twice: once by the importer, and again by the renderer immediately before it reaches the CSSOM or a GL uniform.

• Ship only built-in themes and filters, and drop the community format entirely
• Accept CSS text from a manifest and sanitize it on the way in
• Accept GLSL snippets and validate the source before compiling it
• Reduce both formats to whitelisted, typed values with no free text anywhere

Community themes can only do what the whitelist anticipated. Anything genuinely new needs a new token, a new regular expression and a new release, so the format cannot be extended by the people using it. That is the price of it being data.

44 adversarial assertions run over the filter validator: out-of-range values, NaN, Infinity, wrong types, unknown keys, injected strings, junk manifests, and the renderer’s re-clamp of a store that was edited on disk. They run on every push and pull request in CI. The invariant is written into the shader file so it survives the next reader: no part of a manifest ever becomes shader source, JavaScript, CSS or HTML.

Imported filters need to look different from one another: brightness, contrast, temperature, hue rotation, film grain, a colour lookup table. The obvious implementation generates shader source per filter, which puts untrusted data on the path to the GPU compiler and adds a compile stall the first time each one is selected.

All imported filters resolve to a single program: the effect id is mapped with `const key = id.startsWith('custom:') ? 'customfilter' : id`, so every custom filter shares one compiled shader. The difference between two filters is three vec4 uniforms and an optional LUT texture. The shader runs brightness, contrast, saturation, temperature, tint, gamma, fade, a hue rotation about the (1,1,1) axis, a 64-level lookup table with blue-channel interpolation, vignette and grain, in that fixed order.

• Generate GLSL per filter from the manifest and compile on first use
• Precompile one program per known filter shape and switch between them
• Compile one fixed program and drive every filter entirely from uniforms

Every imported filter pays for every stage whether it uses it or not, and a filter can only ever be a point inside that fixed parameter space. Generated shaders would be cheaper per filter and unbounded in what they could express; this trades expressiveness for a surface area of eleven range checks.

gamma is clamped to a floor of 0.2 so the shader’s 1/gamma can never divide by zero, and that floor is asserted directly in the suite. A lookup table must be a real 512×512 PNG, checked by magic bytes and by the width and height read out of the IHDR chunk at byte offsets 16 and 20, never by file extension. Non-square images, truncated files, oversized files and a JPEG wearing a .png name are all covered.

The failure users actually saw was a completely black, blank preview viewfinder despite the camera hardware LED being lit and permissions granted. Why an ordinary successful build did not establish that the camera worked: TypeScript compilation, packaging, and even navigator.mediaDevices.getUserMedia resolving were green; the promise resolved and tracks were active. But the camera <video> element was deliberately mounted one pixel wide at opacity 0 because frames flow directly into a WebGL texture rather than through DOM painting. On certain Windows GPU and driver combinations, requestVideoFrameCallback declined to fire for an element in that off-screen state, meaning zero frames ever reached the WebGL texture.

How the behaviour was reproduced and corrected: reproduced by testing across windowed and off-screen configurations on Windows with GPU acceleration toggled; the render loop was decoupled from rVFC to always tick on requestAnimationFrame at display refresh, uploading whatever current video frame exists, with a Canvas2D capture fallback when WebGL2 is absent. The reasoning is recorded as an eight-line comment at the scheduling call so the optimisation is not naively reintroduced.

• Mount the video visibly and hide it behind the canvas so rVFC has a painted element
• Keep rVFC and add a watchdog that restarts the loop when no frame arrives
• Drive the loop on requestAnimationFrame and stop depending on rVFC entirely

On a camera running below display refresh, the same frame is uploaded more than once and that GPU work is redundant. Predictable liveness across hardware was worth more than avoiding repeated uploads.

What the regression check now observes: Playwright and Electron integration tests now feed a synthetic video stream and read back raw RGBA pixels directly from the WebGL canvas, failing unless non-black rendered pixels appear. Which checks remain outstanding: physical hardware camera coverage across varied external USB webcams, live verification against a production OBS Studio 28+ install (currently validated against an OBS WebSocket mock), and Windows binary code-signing.

Background replacement means deciding, per pixel and per frame, what is the person and what is the room. The modern answer is a segmentation model, which would have meant a second on-device model to download and a second inference budget on top of the face mesh. The naive alternative, reading pixels back from the GPU at full resolution and differencing them on the CPU, stalls the pipeline every frame.

The user captures a reference frame of the empty scene at 192 px wide. Each frame is differenced against it with a sum-of-channels threshold derived from a user tolerance setting; this is the only CPU pixel loop in the application, deliberately confined to that resolution. The resulting low-resolution alpha mask is upscaled by the GPU during destination-in compositing, which softens the matte edge with no separate feather pass. The composited canvas is then fed back into the GL pipeline as the source, so effects and mirroring still apply on top.

• Add a second MediaPipe model for selfie segmentation
• Difference every frame against a reference at full resolution on the CPU
• Difference against a low-resolution reference and let the compositor do the upscaling

It asks the user to step out of frame once, and it degrades if the camera or the lighting moves. A segmentation model would need neither. It also means the six backdrops had to be drawable rather than photographable: they are generated procedurally with Canvas2D and cached per size, so no image assets ship.

The cost is bounded by construction: the loop is fixed at a 192 px sample regardless of camera resolution, and the upscale is the compositor’s work, not the CPU’s. There is no benchmark in the repository, so I quote no frame rate.

The desktop app has Node, IPC, a filesystem and a main process. The browser has none of those and cannot be given them. Keeping two builds in step usually degrades one of two ways: a shared core with two thin apps around it that quietly drift apart, or platform checks sprinkled through the renderer that multiply with every feature.

The renderer only ever calls PhotoshootBridge, a typed interface declared in src/shared/ipc-contract.ts alongside its IPC channel names. preload.ts implements it over contextBridge and ipcRenderer; src/web/shim.ts implements the same interface over IndexedDB, localStorage and a download anchor. src/shared/ imports neither Node nor the DOM, so it bundles unchanged into the main process, the preload, the renderer and the web shim. The web build bundles src/renderer/main.ts verbatim and only swaps the script tags and sets data-platform="web".

• Two codebases kept in step by hand
• One codebase with `if (isElectron)` branches inside the renderer
• A bridge interface the renderer talks to, implemented once per runtime

The interface is the lowest common denominator of the two runtimes, so capabilities that only make sense on the desktop (revealing a file in its folder, for example) still have to exist in the browser and do the nearest native equivalent. Adding one feature means touching the contract, both implementations and the preload bridge: four files for one capability.

`tsc --noEmit` runs clean with strict mode on, and CI runs it on both Ubuntu and Windows; that is what actually enforces that both implementations satisfy the interface. The camera tests then exercise both runtimes from the same renderer source: one Playwright suite drives the web build in Chromium, and a second launches the packaged Electron app and checks it renders from app://photoshoot.

The renderer handles a live camera feed and visual data imported from strangers. It is sandboxed with Node integration disabled, context isolation enabled and a strict Content Security Policy. The preload exposes only the typed bridge. Navigation and new windows are guarded, and media is processed locally. Software update traffic belongs to the main process: installer builds can download updates from GitHub and install them on restart; portable builds provide a release-page notice. This network traffic is separate from camera processing.

Because 'unsafe-inline' is absent, nothing can inject a style tag, so themes had to be applied through the CSSOM instead of by writing CSS. Disabling dev tools in production means a user-reported rendering bug has to be reproduced locally before it can be looked at.

MediaPipe’s FaceLandmarker fetches its WASM runtime and its model file at startup. Chromium blocks fetch() of file:// resources but allows it for a standard scheme, so a file:// app cannot load an on-device model without reaching for the network, which would defeat the entire point of the product. A real origin also gives 'self' in the CSP something to resolve to. The scheme is registered as standard, secure, supportFetchAPI and stream, and its handler rejects anything resolving outside dist/. The reason is written into the code above the constant, not left in a commit message.

A scheme handler is code I own and have to keep correct. A path-containment mistake in it would be a file-read primitive, which is why it is one of the places isInside() is applied.

The entire app is one quad with a different fragment shader on it. A scene-graph library would have added a dependency, a bundle and an abstraction whose value (meshes, cameras, lighting, material systems) is entirely unused here. CSS filter functions cannot express the seven pointer-driven warps or the face-tracked distortions, and a Canvas2D pixel loop cannot run them at display refresh. Writing the shaders directly is also what made the single fixed custom-filter program possible, which is the thing that makes untrusted filters safe.

Everything a library would have handled is mine: compilation, linking, VAO setup, uniform plumbing and context loss. Programs are compiled lazily and cached per effect id; webglcontextlost and webglcontextrestored handlers clear and rebuild every program and re-upload every LUT texture; a shader that fails to compile falls back to the pass-through effect once and raises a toast rather than crashing the app. Where WebGL2 is missing entirely, a basic camera mode still takes photos and video without effects.

The interface is a viewfinder, a control bar, a 3×3 effects grid and a few sheets. Reconciliation buys nothing when the thing changing sixty times a second is a GPU texture. esbuild produces the main, preload and renderer bundles from one script with no plugin system to learn, and type checking is deliberately a separate command: esbuild does none, so a type error can never stop the app from building and running while I am debugging something unrelated.

There is no component framework, so interface code and shared state need explicit ownership as the app grows. Rendering the camera feed stays separate from updating controls.

Every bundle and stylesheet is emitted with an eight-character content hash and Cache-Control: public, max-age=31536000, immutable, while the HTML and the /, /app and /app/ routes revalidate on every load. A push therefore reaches users on their next page load without anyone clearing a cache, and a stale HTML document can never pair with a mismatched bundle, because the document names the exact files it needs. There is no backend to version alongside it.

Every deploy writes new filenames, so the hosting bucket accumulates the old ones. Deploys are also still a manual `npm run deploy` from my machine; CI builds and tests but does not deploy.