but are you sure GIMP isn't affected?

@@NoNameAtAll2 yup it is. Source: trust me bro

😂😂😂

@@NoNameAtAll2 I've used gimp to crop screenshots on desktop and the filesizes genuinely do get a lot smaller once cropped

@@NoNameAtAll2 yes

Reencoding image files is a neat one-stop solution to ensure that they are (technologically) safe to consume.

Funny part is that about 20 years ago i had a website for images online, and I had a problem with people hiding rar files inside their pictures, so I implemented the re-encoding part that is needed. So my service fixed this issue 20 years ago, to be fair it died maybe 2 years later but still!

​@@gunnargu Yeah, in 2006 I had an issue with users uploading files that were not images and also started re-encoding on upload before saving. It was an event website for a one-time event, so it was only around a couple years, too!

The only gotcha is if the image reencoder itself has security vulnerabilities that an attacker could exploit by uploading a maliciously crafted file.

@@majorgnu well actually that's not that big of a deal except if that vulnerability allows somehow to alter how the reencoding of all future images will be done.

Yes, Sean did a good job.

Yep, as soon as I saw that I instantly understood the concept 👍

I was gonna comment this too. Very cool!

I was big into steganography as a kid, we might have "interacted" in the past.

Similar with botched censorship of PDF files, where people try to draw black boxes but the original text is still under there. Some high profile information has leaked out this way....

​@@AySz88 yeah I did have a redacted legal agreement sent to me where they'd just drawn black boxes everywhere... I just deleted the boxes 🤣🤣🤣

@@ChrisLee-yr7tz what did they say?

Let's be serious, most of the time it's being used by OF egirls promoting their stuff.

@@keepyoursins Maybe he was not supposed to make that comment and he was being watched, and will never come back with an answer for us. I really hope he is okay.

I don't know. Should have left him in the background.

At least for me, there's some instances when recovering the history would have been a fantastic idea. But I can see that it could be radically abused too.

It’s a great idea but there’s needs be a way to save for sharing.

Or in pre-SP2 Windows XP there was a "feature" to send system pop-ups via the network. They looked weird, but it was enough to scare someone.

@@4.0.4 the Messenger service was new for Windows NT!

​@@andrewahern3730 Yeah its called exporting to pdf. Word docs aren't technically supposed to be shared as final documents, they're more like source code or photoshop project files.

I have a pixel phone and have noticed that when I crop a screenshot, the filesize actually jumps from something like 500kb to 1.4mb (just used an example from my phone)

Because people seldom look at the file size. They just crop and immediately send the image. And depending on how the service they're using is set up, the extra data may or may not get properly truncated. Imgur for example will recompress the png if it thinks the pixel area vs file size is out of a plausible range.

I wondered that as well, but as they mentioned this wasn't always the case, at some point the default read/write mode on these systems changed. Additionally, it's become more and more common for file details to be hidden by default. For example, if I open up a folder of images on my pc I see a bunch of thumbnails with names. Things like file extensions, file size, date created, date modified, etc just aren't shown in most default views. We usually don't even look at file sizes unless we actually run out of space, or we are sending or downloading a file, and even then if the file is large enough for us to look at it, we probably compress it anyways (also, even if we do look at the file size before we send it, we probably didn't look at the size before we cropped it). So for the most part I can see how this has gone largely unnoticed. Though I do admit that it's a bit odd that there hasn't been at least a few odd ducks out there that display full file details or checked and saw this at some point.

This is a side effect of not caring about bloat anymore. Why would you? Low on storage? Just buy the next size up. Plus it is not trivial to see the size while it is on the phone, we stopped exposing all that stuff in the UIs.

@@AlexTaradov pixel is Android, and in Android it's pretty trivial to see file sizes. Idk about Apple products though

A failure to meet a non functional requirement... interesting to think about

@@joxfon I think it is functional, even ignoring the case were you crop an image because you need it smaller for whatever reason (if that case was more prevalent, we would have caught this waaaaay sooner... abandoning floppy disks as storage was a mistake XD) If you want to crop out sensitive data you want that sensitive data to be gone. Sending it if it's on the lower part of the image is just a mistake I guess technically it would depend on the strict definition "crop should show a smaller version of the original" vs "crop should remove part of the original", but even with the first definition I'd say the removal of the unwanted data could be assumed

Mhmm, experienced Google devs just failed to notice that the file size got bigger after cropping.

Yeah. It's not a bug in PNG, but it's definitely a bug in the Pixel's image editor (and Windows snipping tool and possibly many more image tools) that has remained hidden because of the way PNG works (and is meant to)

@@jhonbus PNG supporting extra data is a _feature,_ like it is in PDF, so yes it is a bug in the lazy or shortsighted software, but not the PNG format, just as you state. Though... to call it a bug at all seems... less than accurate. Its a flaw in the design or practice of the software, but a bug is generally a behavior of code that isn't isn't working as it was written to. The file I/O is working as written, just... not as intended... and that's not a bug, its a programmer error... But, that's just a programmer being pedantic about it, I admit.

Do you also say "technically, *any* hat is a sombrero"?

​@@Nicoder6884 bro, you're on the nerd channel. We're all like that here.

counterpoint: words in English mean what they mean in English, etymology notwithstanding. ("Nebulous" in English means confusingly ill-defined, not literally cloudy, for instance.)

@@ShinoSarna I'm just trying to figure out to what extent they are self-consistent.

Usage is the final arbiter my friend - apocalypse's meaning has changed

DIVA! lol.. it was a sweet bit of humour thrown in.

Yes, the files contain "pointless" data.

Correct.

On a badly written OS, yes.

Yeah I'm just annoyed because all those images I cropped to save space are the same size as the originals. I was excited about the crop feature mainly for that reason.

You got "Alex Jones'ed"?

@@f.f.s.d.o.a.7294 well that would better fit the opposite of what he describes, wouldn't it?

The kind of people who would even think to check exif, to see whether something is copyrighted or not, are the kind of people who wouldn't attempt to steal a Facebook image in the first place. If you're in the US, the image is copyrighted the instant you create it, whether you put a notice there or not. Anybody trying to be ethical would know this, without needing exif to tell them. Also the damage caused by accidentally sharing private info like your precise location, far out strips the damage caused by somebody reposting your photo or meme without permission. Both legally and ethically it's a no-brainer.

I guess you could just write it down on the post text manually, or for location and time, there are features on the post itself

​@@creedolala6918Well you would have a user interface that presents useful information to people so that they don't need to know the technicalities of what EXIF even is. I mean it's not like we expect somebody scrolling past an image to know what JPEG or gif are. The interface just presents it appropriately.

This is by design. When you crop or edit an image on iOS, it preserves the original. However, the original image is never sent when the image leaves the photos app. IIRC, there are multiple stored files with one being the original. But it’s impossible to accidentally send the original file somewhere without going into photos and uncropping it.

Zip files store their directory metadata at the end of the file and encodes the locations of file entries as relative offsets, so you can append a zip file to a png without any modifications and the result is both a valid png and a valid zip.

​@@remuladgryta I remember hearing about this like 10-15 years ago. Somebody made a png containing text explaining all this. I think the zip file contained source code for some kind of cryptography that was in the process of being banned. In context back then, really clever. In hindsight, kinda terrifying given what else could be shoved in the zip. Like a zip bomb, or something self executing (IIRC, several languages can be packed as self executing zips, including Java)

@@remuladgryta that was the one, yup... been so long

@@ttthttpd more than 20 when I heard about it, since it was before the international standard. and yeah for the time very hairy

That's a separate problem, though, on a different level of abstraction. The biggest issue with the acropalypse is what happens when you send the file to someone else. In that case, filesystem padding obviously won't get included. I haven't looked into the MS Word thing, but it sounds similar to the PDF problem.

@@lassipulkkinen273 It depends on the application. If the app reads and sends the entire "file on disk" size then the problem exists for all files. If the app reads and sends only the "actual file size", then extraneous data is included resulting from the application that created the file. Also, any file type that relies on an internal "end of file" marker will be vulnerable to the problem.

@@Obscurai I don't know what to tell you. It doesn't sound like you're familiar with how processes actually access files on actual operating systems. How would a process end up reading past the end of the file? Also, you might have forgotten what you were saying mid-sentence.

@@lassipulkkinen273 I don't know what to tell you either. It seems you are unfamiliar with the multiple methods of how files are accessed in actual operating systems. Depending on the API used, a file can be accessed at many levels one of which could include all the data that includes all the allocated space. My experience is with MS operating systems since I was a developer at MS for 10 years. What did I forget mid-sentence? Can you be more vague?

@Stephen Louie On Unix-like systems, which I'm familiar with, it would be necessary to read directly from the block device. Nothing anyone could do by accident. I guess there could be some obscure API providing another way, but I've never seen anything like that being used ever. Honestly, I wouldn't have expected Windows to be different in this regard. I'm curious as to what these "multiple APIs" are. What is the benefit of such a leaky filesystem abstraction? Could you be more vague? > What did I forget mid-sentence? I was referring to the sentence "If the app reads and sends only the 'actual file size', then extraneous data is included resulting from the application that created the file." However, I appear to be the one who made the mistake here. I must've missed the "resulting from the application ..." part. edit: Also, the reason I assumed you didn't know what you were talking about was that it genuinely sounded like you'd read somewhere how files have an "actual size" and a "size on disk", and naively assumed programs had a choice between the two when reading. Sorry about that.

The correct way to store extra data in a PNG file is with a custom chunk type. The PNG spec states that the IEND chunk must appear LAST.

also the IEND block isn't just 4 characters, its actually an 8 byte binary identifier that happens to have IEND readable in the middle of it, however the actual identifier has a very specific set of bytes in a specific order, and its very VERY unlikely to ever show up at random in a file in the same way your exact IPv6 address is extremely unlikely to show up at random in a file unless it somehow was put there to represent your IPv6 address, and it can't show up in a PNG file (that was generated to spec anyway) at random, because the file format specification does specify that no matter how the file is generated, that particular string must not appear as a result of any of the stages of file generation, and there are specific checks to be done to split compressed segments apart if it somehow does, so that they don't end up in the file... However... the PNG specification... is like a thousand pages or more long... and most people don't actually support the full format... most people write quick and dirty code to make a file that can successfully be read as a PNG, without actually meeting the standard. I've run into myriad problems with software because program A and B each use their own variation of PNG, but program C only knows how to read program A's version and its own C version.... because there are a thousand different ways a PNG file can be made, and most software only supports stuff that's on the first page of the spec. Those other versions are important though, because they have certain features and better compression that other versions don't support, even though they're supposed to all be supported. PNG foundation has its own library that handles every version and method of PNG, but for various reasons, most people choose to use a 3rd party PNG library or roll their own instead.

This. There's no good reason to put data after IEND, just create a custom chunk type for whatever you want to embed. So to check if a file may contain accidental secrets, parse the chunk structure and check if the first IEND you encounter is actually at the end of the file. The spec says that IEND must appear LAST. (their emphasis)

Yes, that was my thought as well. Maybe he was thinking of just scanning files looking for "IEND" in the file, and that you would have to decode the entire image which would be a waste of CPU time and memory. But looking at the PNG structure you should be able to follow the chunks until you get the first IEND chunk and truncate anything after that.

And that's how you sussed out the fatties.