ONEShot: A Blur You Can Undo Is Not a Redaction

Blur is an easy feature to add and a difficult one to get right, because the whole point is a negative claim: after you apply it, the thing underneath is not recoverable. Most of the work is in making that claim true rather than in making the effect look good.

Two well-documented failures on Android inform how we built it, and both are worth knowing about regardless of which app you use.

Failure one: the data is still in the file

In 2023 a vulnerability was disclosed in the screenshot markup tool shipped with several Android versions. Cropping or editing a screenshot and saving it wrote the new, smaller image into the *existing* file without truncating it. The file was opened for writing, the new content was written from the start, and whatever the old, larger image had occupied beyond that point was left in place.

The result was files whose visible content was the cropped version and whose trailing bytes were the tail of the original. Given the structure of a PNG, a substantial part of the original image could be reconstructed from what remained. It became known as aCropalypse, and it affected an enormous number of screenshots that people believed they had cropped.

The lesson is mechanical and it applies to every editor: never write an edited image over its own file. ONEShot writes the export to a new file. There is no in-place write anywhere in the app. The old behaviour is not something we mitigate; it is something the code cannot express.

The same class of failure appears in image metadata. An edited image can carry the dimensions, thumbnail, and location of the original in its EXIF data. A cropped photograph whose embedded thumbnail still shows the uncropped scene is a real thing that has happened to people. Exports are written with metadata built fresh rather than copied.

Failure two: the blur is reversible

The second failure is about the effect itself.

Blur and pixelation are lossy but not necessarily destructive of information. A pixelation with a small block size applied to text preserves a great deal of structure — enough that, for a constrained alphabet like digits, the original can often be recovered by brute force: render every candidate string, apply the same pixelation, and compare. This has been demonstrated repeatedly against redacted numbers in published documents.

Gaussian blur has the same weakness at small radii. A blur that visually smears text can be reversible when the radius is small relative to the character size, because most of the information is still present, just spread out.

What we do about it:

The blur radius scales with the region. A small area gets a proportionally strong blur rather than a fixed one. This removes the case where a user drags a tight box over a six-digit number and gets a blur that is defeated in an afternoon.

Blur has a floor. Below a certain strength relative to the region, the tool does not apply a weaker effect — it applies the floor. There is no configuration where ONEShot produces a decorative blur over a redaction.

For text, the app suggests a solid fill. Blur is the right tool for a face, a photograph, or a background. For a number, a name, an address, or a code, a solid block is unambiguous and irreversible in a way no blur is. When the selection looks like a text region, ONEShot offers the fill.

Flattening, and why it must happen before export

ONEShot's editor stores edits as operations applied to the original image rather than as modified pixels. That design is good for memory, quality, and adjustability — you can move a blur after placing it — and it means that during editing the original pixels are still present underneath.

That is exactly right while you are working and completely wrong once the image leaves.

Export flattens. The operations are applied to the full-resolution original, in order, producing a new bitmap in which the redacted region contains only the redacted pixels. That bitmap is encoded and written to a new file. What leaves the app is a rendered image, not a document with layers, and there is nothing underneath the blur because there is no underneath.

There is a subtlety here that took us a while to get right. The editor preview renders at display resolution and the export renders at source resolution, and a region that appears covered on a scaled preview can fall a pixel or two short at full size — enough to leave the top of a line of text visible. Redaction regions are therefore rendered with a margin, and the confirmation step before sharing shows a render of the actual export rather than the working preview.

Scan the periphery, not the middle

The technical guarantees only matter if the right region was selected, and the region people miss is never the one they were looking at.

Screenshots leak at the edges. The notification that arrived while you were capturing. The account name in the header. The contact list behind a dialog. A search suggestion containing an address. Somebody else's message partly visible at the boundary of the crop. The battery percentage and time, which are usually harmless and occasionally are not.

Check repeated details. A chat shows the same name in the header, in the message bubbles, and possibly in the notification. A shopping page shows the order number in the title and again in the body. Blurring one instance and missing the other is the most common redaction mistake we see, and it is exactly as bad as blurring nothing.

Zoom out and look again after redacting. A region that looked covered while you were zoomed in may not extend to the full line of text.

Consider cropping instead. Cropping removes; blurring covers. If the private content is at an edge, cutting it off is strictly stronger than obscuring it and takes the same amount of time.

Where blur is the wrong tool entirely

We would rather be clear about this than let the feature imply more than it delivers.

Blur is a visual editing tool suitable for everyday sharing. It is not a redaction process. For anything where the disclosure would be serious — financial records, medical information, legal documents, authentication codes, identity documents — the appropriate action is to remove the information rather than obscure it. Crop it out, or produce a version of the document that never contained it.

There is also nothing an editing tool can do about the copy. The moment an image is shared it exists on other devices, potentially backed up somewhere neither of you chose, potentially forwarded. The review has to happen before the share sheet opens, because that is the last point at which anything is reversible.

What this update actually contains

Blur and solid-fill redaction with automatic strength scaling, a region-aware suggestion between the two, a confirmation step that renders the real export, exports written to fresh files with fresh metadata, and no in-place writes anywhere.

Most of that is invisible. A redaction feature is one where the interesting engineering produces nothing you can see, which is the point.