Non-rectangular "Copy", "Cut", and "Crop to selection" do not destroy pixels, but rather make them alpha 0

[f.m.]

I can't be certain if you would qualify this as a bug, but it was very unexpected and alarming behavior for me.

 

I just noticed today (in Paint.NET 5.1 on Windows 10) that if I "crop to selection" for an irregularly-shaped selection, the outer pixels that are removed are not deleted (e.g. set to transparent black like when you Clear Selection or use the Eraser), but are instead kept intact and set to alpha 0.

 

For example, I take an image:

I create a funny-shaped selection:

And then I crop to selection (Ctrl-Shift-X):

This gives the impression to the user that it has destroyed the pixels from the image, like they would be if you had pressed Erase Selection (Del).

 

However, the pixels have not been destroyed, but have merely been made transparent:

If you were to save this as a file (e.g. PNG) or copy and paste it into another program, the transparent data in the outer section is retained and can be easily recovered. This seems like it could result in a privacy/security issue, since I think many people would assume that the cropped pixels had been destroyed. I decided to test in 5.0.13 to see if this was a regression, but the issue is present there as well.

 

However, that led me to another issue that was not present in 5.0.13 which I found to be even more startling. I discovered that in 5.1 that this affects copying and pasting (into other applications) as well.

 

For example, first I start with a regular image and I make a silly selection:

I copy and paste this raw clipboard data into a chat application that supports transparency, Discord.

Everything's well and good because the other user only received the cropped pixels, right?:

Nope! They can actually save the image and fully recover them:

TLDR:

I think there was an unintended regression between 5.0 and 5.1 that causes outside-of-selection pixels to not be properly destroyed when copying and pasting.

It led me to the realization that outside-of-selection pixels are not and possibly have never been fully destroyed when using "crop to selection", which is a little scary.

[Rick Brewster]

I don't remember if this is intentional, but I'm not sure it's desirable. Let me look into it ...

[f.m.]

I'm rereading my post now, and I should clarify that the second set of instructions refers to a standard copy/cut and paste operation. Just the lasso tool followed by Ctrl-C. No "crop to selection" was involved in that one, which was why it was particularly spooky to see.

 

The clipboard looked and behaved as if only contained the T-shaped data, which is what I would have expected from a copy and paste operation, and why it would have felt safe to paste and send on Discord. It was only when saving the file from Discord, or pasting into an application like MSPaint or Irfanview that it became apparent that the data was still intact.

 

Paint.NET itself seems to correct for this issue automatically within itself, for what it's worth. When the same exact T-shaped clipboard data (containing the transparent data) was pasted back into a new layer or image in Paint.NET, it destroyed the transparent data during the paste operation.

[Rick Brewster]

The underlying issue is that the alpha channel of the pixels is being multiplied by the alpha value from the selection's mask bitmap. This works great except that it still leaves transparent pixels with their color information. I'm adding a second step to these code paths so that any pixels with A=0 also get B=G=R=0 set as well. I agree that this is a potential privacy issue.