Option to obfuscate mosaics to avoid retrieving redacted text from mosaics

[AlexFolland]

Feature Description

Considering that Unredacter can currently retrieve redacted text from mosaics, I propose a feature which obfuscates mosaics to allow using the mosaic tool without Unredacter being able to retrieve it.

How to obfuscate the mosaic is an implementation detail, but I have a couple of suggestions for what to do:

• Change the colors of the mosaic pixels to a random nearby color for each color channel within a percentage range, like 20% of the total range of colors.
  • For example, if one of the mosaic pixels is RGB (144, 144, 144), it could be randomly changed to RGB (153, 134, 146).
    • Applying this randomization to each large mosaic pixel would throw off Unredacter's guessing.
• Split the mosaic into sections and randomly mirror, flip, and shuffle the sections.

[kurayami07734]

I would like to work on this

Also wouldn't it be better to black out the redacted portions?

[AlexFolland]

I would like to work on this

Thank you! I'm excited.

Also wouldn't it be better to black out the redacted portions?

It wouldn't look as close to the original image as an obfuscated mosaic. Overwriting the text with a solid color would make the screenshot look less cool or even make its context more difficult to understand than using an obfuscated mosaic. People are used to the look of mosaic redaction.

Also, new users who don't know about Unredacter and similar tools don't know that they shouldn't use mosaic redacting right now if they want to hide their text.

[mmahmoudian]

I agree, blacking out is already possible with the rectangle tool. This proposal is to shuffle the pixels so that they are not "depixelified" (I don't think that is a real word but it is fun 😊)

Anyways, @kurayami07734 shall I assign it to you?

[AlexFolland]

This proposal is to shuffle the pixels so that they are not "depixelified" (I don't think that is a real word but it is fun 😊)

That's part of my suggestion. The other part is to randomize the colors a bit, and I think that would be valuable as well, and easier to implement.

That being said, how to implement the obfuscation is not for me to say. My proposal is just that there is mosaic obfuscation available.

[mmahmoudian]

@AlexFolland
Either approach would help, but I guess shuffling would have a greater impact. I'm no security researcher, so this is my gut feeling 🤓

@kurayami07734 what do you think? What is your design choice?

[kurayami07734]

I try will both and see which is better

[kurayami07734]

I agree, blacking out is already possible with the rectangle tool. This proposal is to shuffle the pixels so that they are not "depixelified" (I don't think that is a real word but it is fun 😊)

Anyways, @kurayami07734 shall I assign it to you?

Yeah sure

[AlexFolland]

I try will both and see which is better

Why choose one or the other instead of both? I was thinking they would work together, and if you're implementing both, I see no reason to turn one off.

[kurayami07734]

I'm new to qt, I require some assistance

How would I, manipulate the selected section?

[mmahmoudian]

@kurayami07734 I'm not a Qt dev, perhaps seasoned devs (tagged below) can point you to the right direction.

@veracioux @panpuchkov @Martin-Eckleben

[Martin-Eckleben]

Hi everyone 👋

@kurayami07734 Sorry but out of the box I have no good knowledge about it either.
I´d have to research myself.
My best guess is there surely is some kind of Image Buffer / Data Array that you can manipulate.
Find the code which does the mosaic / blur / pixelation first and play around with it.

[jrpie]

I'd argue that a tool to securely remove information should not use any of the information it is supposed to hide as input.
Whatever pixelation/blur-like algorithm we might come up with, there might still be some leakage of statistical information that could be used to recover the input (especially when trying to hide information from a screenshot, where the surrounding text can be used to perfectly determine font and position of the secret text).

I understand that some people don't like the look of large black boxes and thus use pixelation. As opposed to using a box in the color of the background, pixelation also makes it clear that "something was hidden here", which I think also is a desirable feature in many context ("put your password into this field" is very different from "leave this empty").

I'd suggest to fill the area to be hidden with something calculated based only on the values of the pixels on the very fringe of that area. (Note that we can't use all of the outside as a user might want to hide information from several areas and a secret from the area hidden last might otherwise be recovered from areas hidden earlier). Using those values one could emulate a pixelation-like or blur-like effect (maybe adding some noise to convey the sense of something being hidden there).

Don't use the secret as an input at all. It's the only way to be sure.

[AlexFolland]

The point of using the content of the hidden area is to allow redaction to look like it's from the source image. Otherwise we'd just use a solid color. The whole point of this endeavor is to be able to portray that there was text there that's being hidden instead of just nothing or a solid block there.

Don't use the secret as an input at all. It's the only way to be sure.

I disagree. All we need is redaction which sufficiently defeats tools like Unredacter, and that can definitely be guaranteed with sufficient obfuscation.

That being said, your suggestion of omitting parts which aren't on the fringe of the source area is another good suggestion, which does not happen to be implemented in PR #3368. For now though, having #3368 would be much better than having nothing as is the case currently, and the security can be further improved while the implementation is usable rather than waiting for improvements before merging.

[jrpie]

The whole point of this endeavor is to be able to portray that there was text there that's being hidden instead of just nothing or a solid block there.

Yes, definitely. Hence my suggestion to construct something that looks like that while not actually depending on the secret we want to hide. Of course there is no perfect solution to that, but since users view this as a security feature, security should be prioritized over visual appearance imo.

All we need is redaction which sufficiently defeats tools like Unredacter, and that can definitely be guaranteed with sufficient obfuscation.

I think we should also keep in mind that there might be something like an Unredacter 2.0 taylored specifically to the algorithm used by flameshot. Pixelation being reversible is already a catastrophic failure in the sense that once a screenshot is shared publicly it is public permanently. It doesn't suffice to update the pixelation algorithm of the screenshot tool whenever a new flaw is detected, since the screenshots "protected" by the previous version are already out in public at that point.
A tool that users view as a security measure should actually be secure.

For now though, having #3368 would be much better than having nothing as is the case currently

I totally agree that something needs to be done asap. I'd view this as a security issue and think it should be treated as such. Imo the most responsible thing to do would be to remove pixelation entirely asap and maybe add a replacement tool later, once something is ready. However judging by the reaction of the maintainers to other similar issues, they don't seem to want to do that.
The second best immediate mitigation would be to at least warn the user about the feature not being secure (say through a pop-up the first time they use it) ~> maybe I should open a separate issue for that. EDIT: just opened #3763

I don't think it is a good idea to develop a replacement as quickly as possible, accepting the possibility of the new algorithm being insecure again.

and the security can be further improved while the implementation is usable rather than waiting for improvements before merging.

I disagree (see the above argument).

[AlexFolland]

Randomly (with a secret seed like system uptime) redistributing large averaged pixels which have each been altered in brightness by random limited absolute differences might suffice to defeat any current and future unredaction effort while maintaining a typical redaction aesthetic.

[jrpie]

with a secret seed like system uptime

That is not a good seed (see comment on the PR)

redistributing large averaged pixels

"Large" depends a lot the contents of the screenshot, e.g. font size. This is another problem. Since pixelation looks a lot more secure that in actually is, users might not judge the required size accurately.

might suffice to defeat any current and future unredaction effort

Yes, it might suffice. But how do you prove that it does suffice?

[jrpie]

I built a small prototype of the "sample from the edge and add random noise"-approach. Doesn't look too bad imo. What do you think?

[AlexFolland]

Oh, this looks great to me! Thanks for doing it! Will you open a pull request with it?

[jrpie]

Yes, I'll open a PR, but the code still needs quite a lot of cleanup before I can do that ^^