I’ve seen even this fail once, although it was unusual circumstances. Black box on what turned out to be slightly off-black text using a PDF highlighting tool. Not the ideal way to do it. When printed and scanned you could just barely read it if you had a monitor with a bad viewing angle or adjusted the contrast. A paralegal caught it before it went out.
My organization built a similar tool that can find bad redactions caused when people just use a black rectangle on top of text in PDFs: https://free.law/projects/x-ray
Yes, it's been that way long before PDFs. Simply knowing the potential words, often names, that could appear in a document, gives those with the redacted documents a chance at determining what has been hidden based on size. This might be part of the reason why when declassifying documents, the redactions end up being more of a sentence than is needed. The extra buffer of hidden words gives some additional protection to what needs to be redacted.
A malicious "redacting" algorithm submitted to the underhanded C contest used a similar idea, just on lower level.
PNG allows ASCII numbers, so flipping all digits to 0 creates a pixel which is graphically "masked" but leaks information about the original pixel: "000" means the value was larger than 99.
This reminds me of one of my proudest moments in high school.
For a test in German class (my worst class), the teacher had just used tippex to remove some words and put them next to the text, and we had to fill them back in. I grabbed my ruler and measured all the sizes. There was 1 very long word, many medium sizes and a few smaller ones, but with this information and the context of the text for the first and last time I was able to get my first and last 10/10 in this class.
Nope. That's called rebroadcast. It's also used to try to "launder" photo manipulations, like compositing. I helped work on some algorithms which could pick up artifacts even after rebroadcast.
I would absolutely not trust pdf not to leak metadata. Although now you risk metadata leak from the printer or scanner, which may or may not affect your threat model.
When a coworker asked me for my recommended method of creating and publicly sharing redacted copies of documents which (in their unredacted forms) contained PII for children, I told them to do this, in no uncertain terms.
> Am I the only one who redacts info, prints it out, then scans it back in?
if you have the source document, redacting from the source (by actually removing and replacing with an appropriate placeholder, not obscuring, the content) and regenerate the static (e.g., PDF) version.
If you are working from print, I think scan and redact by digital replacement (not overlay or otherwise obscure) would be sufficient. Redact->print->scan probably helps somewhat (especially if the scan is low quality) if you are using a bad redaction method to start with, but why do that?
Not if there is a rasterization step in the process. That's essentially what printing and scanning achieves, rasterization, and we can do that without the printer and scanner.
Of course, the artifacts introduced by printing and scanning (especially with contrast turned way up) gives it an air of legitimacy, although these can also be simulated.
If you print to paper and scan you are mostly safe, but if you do a software print to a pdf document you might use a tool that saves the actual content as invisible text or the whole word document as an attachment to the pdf. I would print and scan physically if it was something important. Or just edit the word document to remove the stuff and then print and scan to avoid saving the edit history since I don't know if that will be saved somewhere.
Usually I'm in full control of the software myself so I just output X instead of the secret data.
Wanting to redact information is not a subset of PDF knowledge. Understanding how PDFs work is not a prerequisite of desire to redact information. Lots of people have only the most basic rudimentary understand of how PDFs work, how Adobe works, and the limits or capabilities.
A lot of people don't even know you can print to a file instead of paper. Not sure why you're surprised about that, after all the standard method for all formats is "save as" or "export" and it's reasonable to assume those two options include all possible ways to save a file. It's a UI quirk that goes against user expectations.
Recently discovered a manual forr some home appliance with a clear Word comment along with username, seems like slipped in when the manual was translated.
On MacOS, preview makes a clear distinction between 'drawing on' and 'redacting' PDFs.
It is an important part of UX that shooting yourself in the foot should _not_ be the default.
The bottom line is that when you need to redact text, use black bars covering the whole text. Never use anything else.
That actually may not be enough if you're applying the black bar to compressed image data like JPEG because compression artifacts surrounding the black bar can be leaking information about the covert data.
Might be interesting to test how plausible that is. How likely is it that a human doesn’t see the artifacts but they are leading enough info to reconstruct the underlying data.
I think it's more likely the JPEG blocks which straddle the box edges simply don't cover any meaningful part of the text. 12 pt font at 96 DPI is 16 pixels tall, meaning 50% of the vertical height of a line simply wouldn't fall into the blocks straddling the edges of a line-height box. You'd get ascenders and descenders but not much else. Tops of numbers or all-caps I think is best case.
Though, web images now are being served in higher resolutions (200+ DPI) for "retina" displays, and scanned images are generally 300 DPI, in which case you'd be lucky even to get ascenders and descenders.
I'd be curious to give it a try though. If Facebook memes are any indication, many humans are totally oblivious to near-unreadable levels of artifacting.
Not necessarily good enough. In principle you need to either get the raw original, or black out every macroblock that ever contained any sensitive information.
Saving to PNG doesn't necessarily change anything (though see below) -- the issue is the artifacts that are already present.
JPEG breaks an image into 8x8 pixel blocks. Each of those blocks then has its information content reduced, so that it can be described in fewer bytes. (I.e., information is thrown away -- making JPEG "lossy", and producing visible artifacts.) This has the necessary side-effect that, when reconstituted, this 8×8 block now contains redundant information (if not, then the compression of that block was not lossy). This finally implies that at least some certain pixels of that block can be (at least partially) inferred from other pixels. That is, if lost, they can be recreated.
(It's helpful to understand also that JPEG does not encode each block on its own, but additionally factors out block commonalities into a central "dictionary".)
For the above to be useful to infer text hidden by a black box, requires:
(a) that the edges of the black box are not aligned to the 8×8 grid;
(b) that the relevant portions of text to be recovered lie near the edges of the black box (i.e., within the 8x8 blocks which straddle the edges); and
(c) that these blocks originally contained data of sufficient complexity, and/or deviating sufficiently from the rest of the image content, that the encoder decided to throw away sufficient information in these blocks to leave significant artifacts.
Finally, if the redacted image was re-encoded as a JPEG (or other lossy format), the re-encoding process must not have thrown away too much information in these blocks, else the redundant information will have been obscured and rendered all but useless for reconstituting the redacted information.
So, an easy way to avoid having redacted information extracted in this manner is simply, to ensure that your black boxes extend at least 8 pixels beyond the redacted text in each direction. (And also, to force the JPEG encoder not to re-use the dictionary from the original image, as information about the statistical distribution of block data could theoretically be extracted from that. Round-tripping through PNG is one way to force this additional safety measure.)
This still isn't 100% information-theoretic secure -- there's still residual information in artifacts elsewhere in the image about what patterns the original image's dictionary contained (which could be extracted with e.g. principal component analysis), which, when combined with a prior statistical distribution of the expected uncompressed content of the image, could leak some information about the portions which were redacted -- but I suspect the amount of information available via this channel to be vanishingly small.
I want random-text-overlay-pixelation (or some lookalike) as a feature instead of plain-text-pixelation. Giant black boxes everywhere is quite the distraction, whereas blur/pixelation is not, so just make the underlying data random.
Ideally the user wouldn't have to do anything. Whatever your editing tool is would have some "text blur" mode which functions and looks like normal blur but the end result is blurred garbage.
I think as far as culture goes it would be simpler to promote the idea that black bars are the only way to do it, than that you need to make sure you're using a special software that knows how to securely pixelate text.
It is a cool idea though, and text-shaped pixelation is much more satisfying than random noise. (And if someone's cheeky enough to decode it, they will be very disappointed ;)
I do this on my website with paywalled information. It respects upper/lowercasing and spacing but randomises each character. Anyone can disable the CSS blur but the data is still obfuscated.
This reminds me of Manning liveBook's obfuscation strategy [0]. It scrambles the letters to keep the majority of the specific details obfuscated while somewhat revealing the gist (word length, acronyms, anagrams, code segments) presumably to encourage sales and discourage piracy.
Potentially leaking names by giving out number of letters in name and surname? Just wondering. If so, consider killing or randomizing spaces and letter count.
My employer makes a tool that does this! It's a screenshot tool we had been using internally for years that we released last year. It takes a sample of the colors in the image and uses them for random-looking obfuscation. So it's obvious that the data is hidden, but there's no pattern or way to un-blur that data. It doesn't work as well on low-contrast images, but we find it quite useful for hiding sensitive data. Some examples:
I think it's kinda hard to see on the wikipedia example what has been redacted. I just do "Obfuscate" in Greenshot with pixel size 16. Call me when this algorithm reverses this https://i.imgur.com/NYf0Dpe.png! :D
Its curious that in tv/film people's identity is censored by blur/pixelation/black bars on eyes and, documents are always censored by black bars. I dont recall seeing pixelation used for text, then why do we mostly go for pixelation in the first place when wanting to omit info on screen.
I wonder if a better (albeit slightly more involved) process to make blurred out sensitive inputs for shared content would be to: 1) add a block over the text, but use the same color as the form in put 2) add similar looking, but fake text on top of the block 3) apply the blur/pixelation.
This way you keep the nicer aesthetics but you get the benefits of using the black box approach.
Probably overkill for many cases, but when I create any sort of content I like to keep it looking fresh.
To prevent some of the issues with blurring or compression leaking sensitive info, one simple workaround I’ve used is to just put black boxes over the text as usual in any program and then take a screenshot and save it out from there. No accidental history or compression leaking.
Tbh I think there needs to be some dedicated tool for censoring images. Even with this method there is a small chance that it isn’t 100% opaque. I have seen several images where you can pull them in to gimp and adjust the color levels until even the slightest color difference becomes blown out and you can read the censored text.
One thing that still leaks is the exact spacing between words adjacent to the black boxes. This is a particular concern one only one or two words are blacked out -- for example a name. With a known font (with known character widths and kerning tables) and a known text engine applying those kerning rules, there's often very few combinations of letters that give the exact pixel (or subpixel) width blank space.
Yes, but being able to rule out "Firstname Lastname" can itself be interesting. Depending on context, the space of names is not all people, but can be very restricted.
I usually convert PDF to raster and draw over. White or light gray box overlay will save ink/toner for everyone and is just as opaque as a black box.
I still do pixelize with huge pixel size when information is not that important. I think it better conveys that there was something there, and redacted areas look more organic.
Redaction can be needed for a document, but redaction can also be needed for a video (car's license plate, credit card number, etc.). As far as I know, there's no video editing software that recommends black bars and, for example, the official Adobe documentation at https://helpx.adobe.com/premiere-pro/using/masking-tracking.... seems to recommend their Masking and Mask Tracking features.
Black bars may look very ugly in a video. Still, are video editing products recommending a process that has a high risk of leaking sensitive data? There might be reasons that attacking redaction in a video is harder than attacking redaction in a PDF. However, maybe it's actually easier in some cases, e.g., with several similar frames, the attack could take advantage of averaging across frames.
Unfortunately I don't see anything at https://hackerone.com/adobe that could get someone a bug bounty for researching this.
That should work, given than the result doesn't have any actual input from the original data (except width of the text) and completely opaque over the actual text.
I imagine that would be the same as a black fill, just in a different color with noise.
I've used the original image data as a fill, but scaled down, so you get a mosaic effect. Then I randomise the tiles in that mosaic and then I blur. The result is that it seems like the original data was redacted but in reality the original data has been scrambled to such an extent that it can no longer be retrieved.
Tangentially related but I immediately recognized the person in the video in the article as "AltF4" who has done a lot of work in the Super Smash Bros. Melee scene. He has worked on slippi[1], created a Python API library for the game[2], and coded a bot[3] to demonstrate the library which professional players find very difficult to beat based on its inhuman reaction times (as you'd expect).
I've always wondered what some of these Melee players do as a real job and I guess in this case I found out by accident (in hindsight, the name of the company is in his Github bio, which I had never checked before).
AltF4, Dan Salvato, Fizzi, and UnclePunch are all absolute legends. All of the things they've done to improve Melee are staggering. Amazing work by all of them.
> [The challenge image] has a curious bit of coloring in it. What gives? Shouldn’t it just be black and white since the text is black?
> I’m actually not 100% sure why this happens (and sometimes doesn’t), but it’s an artifact of the rasterization process when text is rendered to screen.
This is a brilliant technique called subpixel rendering.[0] A "typical" computer screen's pixels are split into three columns of red, green and blue, instead of lighting up as a solid square. Using color fringing at non-pixel-aligned edges of characters can effectively triple the perceived horizontal resolution.
Wrong assumptions about the pixel layout will show up very badly, as shown in [1].
HiDPI displays (also mobile, not just 4K) get no real benefit from this and usually have a more complex subpixel layout anyway. I remember seeing old iPads usually showing awful fringes as subpixel rendering was enabled without considering the actual orientation of the display.
It still does - for fonts. It's called "ClearType Text Tuner" and it's part of Windows. It allows you to select one of several different subpixel rendering types to pick one that looks best on your screen.
Irritatingly, some windows applications implement their own subpixel rendering. As somebody on a 1440p BGR panel, those applications become extremely obvious to me as the aliasing is exactly backwards to what it should be. One irritating example is the web version of MS Word, as it doesn’t use the browser font rendering and instead implements it’s own (in canvas I think?) - giving all text eye-straining fringes on my display. Google Docs has the good sense to stick to black-and-white anti-aliasing at least.
You should try the Dark Reader plugin that reverse all the colors and make the subpixel rendering of the web version of MS Word become BGR subpixel rendering. I know it because the text looked weird on my RGB display with the plugin on.
Most of these issues exist on other platforms as well. Try running a QT or GTK app in Mac, or an opposing widget kit app on Gnome or KDE.
Things have certainly gotten better (similar to HiDPI support, multi-monitor, etc) as developers have standardized or learned the tools, but an individual app can choose to do it’s own bespoke rendering on any platform.
Fair, it's not a windows issue. I only use windows, so I've only experienced it on windows and I didn't want to overstate - but obviously that was poor wording on my part.
I was about to get a monitor that was too good to be true for the price. Turns out it was BGR. At the time, I didn't know what that meant. But the reviews said it was not good, so I avoided it.
I appreciate that reviewer every time I think about it.
I'm the developer behind Redact.Photo [0], instead of blurring or pixelating the image, I've added an additional step to improve data security. See "how it works" section on the page.
1. Image is scaled down to create a mosaic effect
2. Pixels are moved around a random offset of x and y axis
3. Blurring is applied
Adding black bars over information will always be better but this does result in more smooth redaction that I think cannot be undone because of the randomisation step.
I tried it out. It still leaves a lot of the original information in the redact. Is it enough to reverse? I can't say it definitely is, but I would not be willing to risk something important with it.
I'm not sure what you tested with, but it might "seem" that the original information is there?
Only the original color data remains, but the detail is gone and each pixel position behind the redacted area is randomised/mixed. This randomisation step also overwrites pixel information so there is data loss as well. Because it's then blurred it looks like the info is blurred only. But if you'd be able to reverse the blur you'd end up with pixel noise. I find it hard to believe that that noise could be reverted.
Quick note: when giving examples of variable width and monospace fonts, the both look variable width. No monospace font is displayed (mobile Safari iOS 15.3.1)
Wouldn't an algorithm just like this one also be able to work on really blurry (i.e. far away zommed in) photos too? Especially with a huge corpus of trained content?
167 comments
[ 2.5 ms ] story [ 235 ms ] threadI have seen many a doc with history still included because they were using illustrator or something similar
I took down a ton of poorly redacted black boxes while modding /r/facepalm
In retrospect, a bot could do the job pretty well
Very fun project. Lots of problems out there.
PNG allows ASCII numbers, so flipping all digits to 0 creates a pixel which is graphically "masked" but leaks information about the original pixel: "000" means the value was larger than 99.
http://underhanded-c.org/_page_id_17.html
http://netpbm.sourceforge.net/doc/ppm.html
For a test in German class (my worst class), the teacher had just used tippex to remove some words and put them next to the text, and we had to fill them back in. I grabbed my ruler and measured all the sizes. There was 1 very long word, many medium sizes and a few smaller ones, but with this information and the context of the text for the first and last time I was able to get my first and last 10/10 in this class.
For some reason I just never trust the PDF tool (or human error on my end) actually redacting the info, even if I were to do a print to PDF.
I would absolutely not trust pdf not to leak metadata. Although now you risk metadata leak from the printer or scanner, which may or may not affect your threat model.
if you have the source document, redacting from the source (by actually removing and replacing with an appropriate placeholder, not obscuring, the content) and regenerate the static (e.g., PDF) version.
If you are working from print, I think scan and redact by digital replacement (not overlay or otherwise obscure) would be sufficient. Redact->print->scan probably helps somewhat (especially if the scan is low quality) if you are using a bad redaction method to start with, but why do that?
Of course, the artifacts introduced by printing and scanning (especially with contrast turned way up) gives it an air of legitimacy, although these can also be simulated.
Usually I'm in full control of the software myself so I just output X instead of the secret data.
This degrades quality and wastes paper and toner. There are software tools to convert PDF to raster graphics.
Recently discovered a manual forr some home appliance with a clear Word comment along with username, seems like slipped in when the manual was translated.
Though, web images now are being served in higher resolutions (200+ DPI) for "retina" displays, and scanned images are generally 300 DPI, in which case you'd be lucky even to get ascenders and descenders.
I'd be curious to give it a try though. If Facebook memes are any indication, many humans are totally oblivious to near-unreadable levels of artifacting.
JPEG breaks an image into 8x8 pixel blocks. Each of those blocks then has its information content reduced, so that it can be described in fewer bytes. (I.e., information is thrown away -- making JPEG "lossy", and producing visible artifacts.) This has the necessary side-effect that, when reconstituted, this 8×8 block now contains redundant information (if not, then the compression of that block was not lossy). This finally implies that at least some certain pixels of that block can be (at least partially) inferred from other pixels. That is, if lost, they can be recreated.
(It's helpful to understand also that JPEG does not encode each block on its own, but additionally factors out block commonalities into a central "dictionary".)
For the above to be useful to infer text hidden by a black box, requires:
(a) that the edges of the black box are not aligned to the 8×8 grid;
(b) that the relevant portions of text to be recovered lie near the edges of the black box (i.e., within the 8x8 blocks which straddle the edges); and
(c) that these blocks originally contained data of sufficient complexity, and/or deviating sufficiently from the rest of the image content, that the encoder decided to throw away sufficient information in these blocks to leave significant artifacts.
Finally, if the redacted image was re-encoded as a JPEG (or other lossy format), the re-encoding process must not have thrown away too much information in these blocks, else the redundant information will have been obscured and rendered all but useless for reconstituting the redacted information.
So, an easy way to avoid having redacted information extracted in this manner is simply, to ensure that your black boxes extend at least 8 pixels beyond the redacted text in each direction. (And also, to force the JPEG encoder not to re-use the dictionary from the original image, as information about the statistical distribution of block data could theoretically be extracted from that. Round-tripping through PNG is one way to force this additional safety measure.)
This still isn't 100% information-theoretic secure -- there's still residual information in artifacts elsewhere in the image about what patterns the original image's dictionary contained (which could be extracted with e.g. principal component analysis), which, when combined with a prior statistical distribution of the expected uncompressed content of the image, could leak some information about the portions which were redacted -- but I suspect the amount of information available via this channel to be vanishingly small.
It is a cool idea though, and text-shaped pixelation is much more satisfying than random noise. (And if someone's cheeky enough to decode it, they will be very disappointed ;)
Opaque gray boxes then?
https://imgur.com/a/NY6xKie
[0] Ex. https://livebook.manning.com/book/programming-the-ti-83-plus...
frog: https://cdn.zappy.app/f97505ba92625a0e949aebcfa4220852.png
wikipedia: https://cdn.zappy.app/3b7d5cf750066633e40aeddda926f95f.png
It's not really targeted at the HN crowd (requires an account, etc), but the app is "Zappy" if folks are interested.
- https://zapier.com/zappy
This way you keep the nicer aesthetics but you get the benefits of using the black box approach.
Probably overkill for many cases, but when I create any sort of content I like to keep it looking fresh.
https://it.slashdot.org/story/07/01/07/1352242/blurring-imag...
which was republished in 2014 in Gizmodo:
https://gizmodo.com/why-you-should-never-use-pixelation-to-h...
See also related HN comments:
https://news.ycombinator.com/item?id=8078747
It’s just too easy to mess this stuff up.
Or just summarise the content yourself and hope there are no event/story/narrative based watermarks present.
I still do pixelize with huge pixel size when information is not that important. I think it better conveys that there was something there, and redacted areas look more organic.
I would not be so sure about cutting the area, don't forget to print it (to PDF) instead saving it.
Black bars may look very ugly in a video. Still, are video editing products recommending a process that has a high risk of leaking sensitive data? There might be reasons that attacking redaction in a video is harder than attacking redaction in a PDF. However, maybe it's actually easier in some cases, e.g., with several similar frames, the attack could take advantage of averaging across frames.
Unfortunately I don't see anything at https://hackerone.com/adobe that could get someone a bug bounty for researching this.
A tool where you can choose the background color and the text color. The pixalation tool then overlays the blur effect with random characters.
I've used the original image data as a fill, but scaled down, so you get a mosaic effect. Then I randomise the tiles in that mosaic and then I blur. The result is that it seems like the original data was redacted but in reality the original data has been scrambled to such an extent that it can no longer be retrieved.
I've always wondered what some of these Melee players do as a real job and I guess in this case I found out by accident (in hindsight, the name of the company is in his Github bio, which I had never checked before).
1. https://slippi.gg/about
2. https://github.com/altf4/libmelee
3. https://www.youtube.com/watch?v=Gb3v6uPuKic
> I’m actually not 100% sure why this happens (and sometimes doesn’t), but it’s an artifact of the rasterization process when text is rendered to screen.
This is a brilliant technique called subpixel rendering.[0] A "typical" computer screen's pixels are split into three columns of red, green and blue, instead of lighting up as a solid square. Using color fringing at non-pixel-aligned edges of characters can effectively triple the perceived horizontal resolution.
Wrong assumptions about the pixel layout will show up very badly, as shown in [1]. HiDPI displays (also mobile, not just 4K) get no real benefit from this and usually have a more complex subpixel layout anyway. I remember seeing old iPads usually showing awful fringes as subpixel rendering was enabled without considering the actual orientation of the display.
[0] https://en.m.wikipedia.org/wiki/Subpixel_rendering
[1] http://www.lagom.nl/lcd-test/subpixel.php
It also switched it off globally when the "magnifying glass" tool was active.
Most of these issues exist on other platforms as well. Try running a QT or GTK app in Mac, or an opposing widget kit app on Gnome or KDE.
Things have certainly gotten better (similar to HiDPI support, multi-monitor, etc) as developers have standardized or learned the tools, but an individual app can choose to do it’s own bespoke rendering on any platform.
I appreciate that reviewer every time I think about it.
1. Image is scaled down to create a mosaic effect
2. Pixels are moved around a random offset of x and y axis
3. Blurring is applied
Adding black bars over information will always be better but this does result in more smooth redaction that I think cannot be undone because of the randomisation step.
[0] https://redact.photo
Only the original color data remains, but the detail is gone and each pixel position behind the redacted area is randomised/mixed. This randomisation step also overwrites pixel information so there is data loss as well. Because it's then blurred it looks like the info is blurred only. But if you'd be able to reverse the blur you'd end up with pixel noise. I find it hard to believe that that noise could be reverted.
Quick note: when giving examples of variable width and monospace fonts, the both look variable width. No monospace font is displayed (mobile Safari iOS 15.3.1)