JPEG format normally compresses pictures in 8x8 blocks, and these blocks are aligned so the first one starts at top-left corner of the image. I think these leaks you’re talking about are limited to the inside of the 8x8 blocks.

So, if you want to redact a rectangle between pixels [ 12, 4 ] – [ 34, 18 ], redact [ 8, 0 ] – [ 40, 24 ] instead, this way the black rectangle will cover complete blocks.

I don’t think what you’re saying makes sense. If you covered all information, no information is left. The blocks are irrelevant since 100% of the information is gone. There’s no “history leak” in JPEG, which is basically what’s being asked.

The only issue I see is meta tags and embedded thumbnails, which some cameras do. Stripping EXIF is always required.

> If you covered all information, no information is left.

JPEG compression causes ringing artifacts that can extend out past the pixels you're trying to redact, up to the next block boundary. This is a problem if what you're trying to redact is already a JPEG, rather than a pristine uncompressed image.

> JPEG compression causes ringing artifacts that can extend out past the pixels you're trying to redact, up to the next block boundary.

This.

I made a response to the parent question that goes into the practical side of this in a bit more detail, but this is a much better one-sentence summary of /how/ the information leaks.

(Monochrome pictures in 8x8 blocks, 4:2:0-downsampled colour images in 16x16 blocks; 4:2:2 and non-downsampled 4:4:4 colour images are technically possible but I’ve never seen one.)

Is another low tech way simply print screening the redacted image + cropping? Naturally you will lose resolution if the OS/app is downsampling the image to render but could be good enough and a good hedge against the image format somehow encoding history. AFAIK, some law firms still redact, print, scan for this reason.

No? If it were to be visible it would be because your editing software failed to blend the layers together properly during compositing and rasterization. JPEG encoding comes after this.

I think they mean the original compression of the original text file (if in jpeg) would have crafted specific DCT coefficients that reach across to the secret text. When that is later decoded to pixels and re-encoded, new DCTs are burned into the image, but only on top of the previous.

That's not how it works. it is "on top" of the previous, sure, but the same way as if I add 8 to 2 and give you 10, you can't possibly get the original number is 2.

This is it.

Let’s say you’re covering a red pixel with a black pixel. There’s no way that red pixel will in any way “survive JPEG compression” because the compression happens on the raw pixel data; the raw pixel data no longer has a red pixel.

If the red pixel affected the encoding of nearby pixels in the compressed original, which you've now neglected to redact, then the data very well could persist.

That's not the point the other posts are making.

They're saying that before encoding the red dot could have been X pixels wide, and to the naked eye it would seem that after encoding it's still only X pixels wide... but due to compression artifacts it may now actually be affecting an area X+Y pixels wide. So only covering X pixels could leak Y pixels of information.

It honestly sounds a bit paranoid to me, but it's definitely possible.

> Let’s say you’re covering a red pixel with a black pixel. There’s no way that red pixel will in any way “survive JPEG compression” because the compression happens on the raw pixel data; the raw pixel data no longer has a red pixel.

This is trivially untrue for JPEG; JPEG often stores chroma info as 4:2:0, that is at a quarter the resolution of luminance info. In this common case, covering a single red pixel in the decoded form only removes a quarter of the chroma information from its presence (and this is easy to not notice if, for example, the other three pixels that share its chrominance are nearly black).

Except maybe your 2 was previously stored in the LossyNumber(TM) format which can only approximate integers, and it turned into 2.033. You add 8 to it, send it to me in a less lossy encoding, and I see 10.033. My knowledge of LossyNumber artifacts lets me know you started with 2!

Yes, but you know what the bare DCTs of the square box should be, so if they differ from that, it must be from the original image

No there is no information passing through if the opacity is 100%. I have seen people attempting to redact using the pen or paintbrush tool, however, and opacity is often not 100% when doing that.

I have also seen people try to redact by drawing a black block on a new layer in Photoshop, for example, and then exporting as PDF. They're unaware that the layers are being exported in the PDF and the block can be removed. Always flatten your document completely before export.

If it its text, then it leaks the length of the text that was redacted. Something to keep in mind. So you may want to actually move the remaining text spacing a bit one way or the other.

That's assuming you knew what the font type and font size was, though.

That’s trivial to get. Once we know the pixel word length and do some frequency analysis for estimates, along with an analysis of subtle compression artifacts that typically form in the white space surrounding various characters or combinations of characters, it’s game over for you, we will find the redacted content with reasonable certainty.

Which is why you should not redact individual words. But rather as large a block as possible.

This a very valid concern. Yes, indeed, the compression might leak out certain bits out to the neighboring pixels. Especially in this sequence: raw -> lossy (jpeg) -> redaction -> less lossy or lossess (png).

Whether that's enough to decode the redacted information will depend on how many pixels were redacted and other intricacies of JPEG.

This is not too dissimilar to compression oracle attacks, such as CRIME (https://en.wikipedia.org/wiki/CRIME), an infamous vulnerability in HTTPS.

Well it's sure smarter than some government agencies 5-10 years ago that thought they could redact things by drawing black boxes over them in a PDF editing application and saving it, blithely not knowing all they were doing was creating new "block of black area" vector overlays that could be easily removed.

It was before, I remember it made it to the news because of the documents regarding the death in Iraq of Nicola Calipari, that was early 2005, so some 17 years ago:

https://en.wikipedia.org/wiki/Rescue_of_Giuliana_Sgrena

https://en.wikipedia.org/wiki/Rescue_of_Giuliana_Sgrena#Rele...

Yes, information leaks this way, if you redact a previously-JPEG-compressed image with a non-block-aligned black rectangle.

Consider the following case: You have limited previously knowledge of the unredacted document; for example, you know that it was a pure black-and-white document that was compressed as a standard color JPEG (not too unusual). Suppose further that in the block extending from (16, 16) to (24, 24) (exclusive), you wish to redact the single pixel at 23, 23, presumedly as the upper left corner of a larger black bar. Finally, suppose that the post-redacted image is losslessly compressed; this simplifies the argument, but is not strictly necessary.

In the way we've phrased this problem, there are only two values for the original color of the redacted pixel; it was black, or white. The rest of the pixels in the block are known in their encoded form (unredacted), but also known in their pre-encoded form (pure black or pure white, while JPEG compression will put them somewhere into dark gray or light gray, respectively). With all known pixels set to their pre-encoded form, each possible value of the redacted pixel can be considered, using (known, deduced, or guessed) JPEG compression parameters to regenerate the compressed block. Whichever value of the redacted pixel leads to the observed encoded values of the unredacted pixels is the correct value of the redacted pixel.

(In practice, the problem might be less constrained; and you might have multiple but less than a block of pixels redacted; these make it harder to make use of the leaked information, but do not change that some information has indeed leaked.)

See also the 2008 underhanded c contest: http://underhanded-c.org/_page_id_17.html

Programs that appear to black out a section of image, but actually leak information.

Why are the top and bottom person referred to by name, but the middle person is "this dude"?

Random guess: the writer doesn't know how to pronounce that name correctly.

(Of course, you don't actually have to know how to pronounce something in order to write it! But if you decide what to write by saying it to yourself, you might find yourself instinctively reaching for some alternative turn of phrase.)