5 ms·
Let’s say you redact with a pure black rectangle, on a JPEG. Is there enough information in the remaining compressed image to leak some information about what w
by quickthrower2 4y ago
Let’s say you redact with a pure black rectangle, on a JPEG. Is there enough information in the remaining compressed image to leak some information about what was redacted?
I ask because what was there would have affected the original compression algorithm. So there might be some signal left.
- MintPaw 4y agoNo? 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.
- cultureulterior 4y agoI 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.
- thrdbndndn 4y agoThat'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.
- cultureulterior 4y agoYes, 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
- laudecum 4y agoThis 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.
- ummonk 4y agoIf 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.
- BoorishBears 4y agoThat'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.
- addaon 4y ago> 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).
- laudecum 4y ago
- skupig 4y agoExcept 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!
- Const-me 4y agoJPEG 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.
- laudecum 4y agoI 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.
- wtallis 4y ago> 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.
- addaon 4y ago> 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.
- mananaysiempre 4y ago(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.)
- 4y ago
- IAmGraydon 4y agoNo 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.
- derekp7 4y agoIf 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.
- AdmiralAsshat 4y agoThat's assuming you knew what the font type and font size was, though.
- xwdv 4y agoThat’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.
- Akronymus 4y agoWhich is why you should not redact individual words. But rather as large a block as possible.
- NMawy 4y agoThis 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 https://en.wikipedia.org/wiki/CRIME), an infamous vulnerability in HTTPS.
- walrus01 4y agoWell 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.
- jaclaz 4y agoIt 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 https://en.wikipedia.org/wiki/Rescue_of_Giuliana_Sgrena#Release_of_classified_information_in_US_report https://en.wikipedia.org/wiki/Rescue_of_Giuliana_Sgrena#Rele...
- addaon 4y agoYes, 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.)
- Laremere 4y agoSee also the 2008 underhanded c contest: http://underhanded-c.org/_page_id_17.html http://underhanded-c.org/_page_id_17.html Programs that appear to black out a section of image, but actually leak information.
- stavros 4y agoWhy are the top and bottom person referred to by name, but the middle person is "this dude"?
- tom_ 4y agoRandom 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.)