Evidence at a glance
A Concrete Sharing Problem Became a Browser Tool
On September 29, 2026, Simon Willison introduced Photo Scrubber, an experimental tool for local face blurring and photo metadata handling. The project began with a concrete situation rather than an abstract product brief: he had photographed protesters and did not want to share identifiable faces of strangers. He asked GPT-6 Astra to help build a tool that could detect faces automatically and blur them.
That starting point makes the problem practical. People publishing photos may understand that unrelated individuals should not be exposed, yet still lack a lightweight redaction workflow. If every image has to be sent to a remote image service, the privacy process itself can create another exposure surface. Photo Scrubber attempts to reduce that step to a browser interaction, with the transformation taking place before the original image leaves the device.
The relevant change is therefore not that a model can understand a photograph. In the supplied material, GPT-6 Astra primarily helped construct the tool, while detection and blurring at runtime are handled by a separate vision stack. The deployment boundary is determined by whether the original must be uploaded and where the code that handles sensitive data actually runs.
GPT Builds the Tool; Vision Components Execute It
Photo Scrubber uses Google’s MediaPipe C++ library, compiled to WebAssembly through @mediapipe/tasks-vision. At runtime, it uses the BlazeFace face-detection model and automatically applies a blur after detecting faces. The architecture separates construction from use: GPT-6 Astra helps generate the tool code, while MediaPipe, WebAssembly, and BlazeFace process the image.
This division is more precise than saying that “AI protects privacy for the user.” The code-generating model affects whether the page, integration logic, and library calls are assembled correctly. Whether the image is uploaded and whether inference runs locally are determined by the browser-side execution path. Even without assuming that the code-generating model is reliable, engineers can inspect the resources loaded by the page, the location of processing, and whether any request sends the original image to a backend.
For engineering teams, this turns a privacy promise into a concrete architecture question. A remote service usually requires trust in a provider’s policies for logs, retention, and training use. Local processing at least makes “does the original leave the device?” a boundary that can be audited. The supplied material does not include an independent test of network behavior, so the design should be described as an auditable direction rather than proof of absolute no-upload behavior.
WASM Changes Deployment, Not Detection Reliability
Compiling MediaPipe’s C++ library to WebAssembly creates a path for an engineering-heavy vision capability to run in the browser. A team does not need to deploy a dedicated image backend for this lightweight operation, and users do not need to install a full desktop client. The model and inference logic can load with the page and process the image on the user’s device. That is the technical foundation of Photo Scrubber as an experiment.
The value of this path is that it reduces the number of components that must be trusted. The original does not need to enter an application server before processing, and the transformed result can be generated locally. For ordinary photographs, lower-risk social publishing, or internal demonstrations, this may be easier to deploy than a complete media-redaction service. It also gives teams with existing C++ vision components another route into browser-based deployment.
Local execution addresses only part of the transfer and storage risk. The material provides no miss rate for BlazeFace in crowded scenes, under occlusion, in backlighting, with distant faces, or when people overlap. It also provides no measurements for local processing speed or browser compatibility. An obvious error can tell a user to stop, while a missed face may leave the user believing that the photograph is safe to publish.
That is where automated redaction is most easily misunderstood. A tool completing one blur operation does not mean that it identified every object that requires protection. If an engineering team places such a component in a publishing workflow, it
“Metadata Removal” Must Become Testable
Photo Scrubber’s title also claims that it can remove photo metadata. The supplied description explicitly explains face detection and blurring, but it does not list which fields are actually removed. It also does not explain whether the export process covers different image formats, how it handles re-encoded files, or whether every export path prevents original information from returning.
Metadata cleaning cannot be treated as only a button label. Location, capture time, and device information can all become privacy clues, while file formats, browser export behavior, and re-saving can affect whether those fields remain. Without a field inventory, input and output samples, and a defined coverage boundary, “metadata removal” cannot be treated as a validated security capability.
This does not reduce the value of the local architecture. It changes the standard by which the product should be judged. Photo Scrubber demonstrates how an idea for sensitive-data handling can quickly become a working browser experiment, but it does not provide enough evidence to establish a complete anonymization system. The title’s functional claim must be broken down through code review and targeted testing rather than accepted because the tool exists.
Face Blurring Is Not Anonymization
Even if face detection and metadata cleaning work as intended, a photograph may still identify people through other clues. Posture, clothing, backgrounds, buildings, and location can all narrow the identity set. At a protest or a small event, someone familiar with the local context may identify a person without seeing the face at all.
Photo Scrubber should therefore be placed in a lower-risk, reviewable stage rather than used as an automatic publishing gate. For images involving protests, news events, children, or a credible risk of real-world harm, human reviewers still need to decide which subjects require redaction, which backgrounds should be cropped, and whether the image should be published at all. Automatic blurring can reduce repetitive work, but it cannot make the contextual decision for the publisher.
For engineering leaders, the actionable conclusion is to split the system into separate questions. First verify that the original stays local. Then measure missed and false detections in the target scenes. Next verify exported metadata field by field. Finally include re-identification risk in the human publishing policy. Only when these boundaries are explicit does no-upload processing become a governance measure that can be relied upon rather than merely an architectural advantage.
The reusable pattern shown by Photo Scrubber is to let a generative model rapidly assemble interfaces and glue code while a mature local vision runtime handles sensitive content. This can lower deployment friction and reduce the chance that originals enter a third-party service. Its co