[nkrisc]

I wonder if using certain kinds of inks could cause slight differences in reflectivity over the redacted text, leaving artifacts that could be used to reconstruct the text in scanned documents? Seems like applying strips of opaque tape over the redacted text might be the most certain method, though maybe overkill after all.

[3eb7988a1663]

This was sort-of the winning solution to an underhanded C contest to redact an image. Hazily remembered, but the winner used a trick where already black pixels got redacted to one color black and already white pixels got to an ever so slightly different black. Reversing the image would then make it trivial to read the original black-on-white text.

[moefh]

I remember that one: the two blacks were not slightly different, they were both exactly black but written in different ways.

The image was in PPM format, which stores the color components of the pixels as ASCII text (so a white pixel is stored as "255 255 255" and a black one is "0 0 0"). To redact the image, the code replaced every digit of the numbers with '0', so white became "000 000 000" and black stayed as "0 0 0". Both are black and indistinguishable if you're viewing the image, but you can tell them apart by looking at the file text.

Sadly the UCC homepage seems to have vanished, but I found this account from the author: http://notanumber.net/archives/54/underhanded-c-the-leaky-re...

[mjevans]

Not 100% sure offhand, but I _think_ the the final step in my process chain (repack everything into a PDF) would have converted the input image formats and thus defeated that type of input. As it was, they were effectively 'redacted' using MSpaint to clobber over the rasterized data, so I was more concerned with minimizing the file size.

[3eb7988a1663]

Ah right. Had to be sneaky enough to escape being outright flagged. A not-quite-black would have failed the test.