Acropalypse Now - Computerphile
ฝัง
- เผยแพร่เมื่อ 27 มี.ค. 2023
- Researchers stumbled upon a simple but worrying bug. Cropped images from Pixel phones contained a great deal of the original image in the cropped file. Drs Steve Bagley & Mike Pound explain.
Mike's sources:
/ itssimontime
/ david3141593
www.da.vidbuchanan.co.uk/blog...
Proof of concept: acropalypse.app/
Waiting for someone to spot that I fixed my typo on the text messages illustration but didn't fix it on the original -Sean
/ computerphile
/ computer_phile
This video was filmed and edited by Sean Riley.
Computer Science at the University of Nottingham: bit.ly/nottscomputer
Computerphile is a sister project to Brady Haran's Numberphile. More at www.bradyharan.com
They called me mad when I used GIMP for cropping all my images!! Well now who's the crazy one?! Ahaha AHAHAHAHA
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
All you have to do is crop the image, take a screenshot of the cropped image, crop the screenshot, and then send the original cropped image because you couldn't remember which was which.
There's a very similar issue in biology. The mechanisms that reads genes can miss its equivalent of an iEnd, a stop codon, and keep on reading until it reaches another stop codon. Some viruses actually use this as a way of compressing their genome by having a protein whose full-length version and "cropped" version do different things.
6:31 in addition to removing metadata to protect the user privacy, another reason to re-encode images that are uploaded is to ensure that they are actually images, as well as constraining image sizes, protecting website itself from harm.
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.
I'm loving the editing on this one. The sequence at 3:20 is particularly cool
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!
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!
I was big into steganography as a kid, we might have "interacted" in the past.
It's almost as funny as when Microsoft thought it would be a good idea to save a Word document's edit history in its file. It was not.
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.
This is sort of reminiscent of the situation with people using social media-supported "stickers" to cover up information on pictures uploaded to those platforms. So you'd upload a picture to the site, and place a sticker over the bit you don't want to be visible, but it turns out those stickers were implemented as extra bits outside of the actual pixel data, so all the original pixel data is just there. Same with putting black boxes over text in a PDF editor or something. It really does play with the definition of "bug" in that something could totally be following the spec, but it's not reasonable to expect people to know those details of the spec and factor that in when doing normal things like editing a picture on their phone.
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.
Great dynamic in this video with Steve and Mike! Good format
I don't know. Should have left him in the background.
Ok but that text message conversation at 5:42 is actually kind of hilarious ngl
DIVA! lol.. it was a sweet bit of humour thrown in.
I wonder why this hasn‘t been found earlier since the cropped image has the same filesize?
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
Going to Nottingham for a masters in CompSci in September. This channel has always been on my recommendation list. Will be great to learn from you guys in real life.
I love the smell of exploits in the morning
As to the question: "Is this really a bug?": When the programmers wrote the code, they wrote it with the intention that the output file would be truncated (as that was the default), but now the program doesn't follow their this intention any more (as the default has changed). I.e. while the program generates a valid PNG file, it does not generate the PNG file the programmers intended for it to generate. And therefore, we can classify this as a bug.
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.
Props to the editor for the diagram at 3:25
I don't know if whoever came up with “acropalypse” is aware, but that name is absolutely perfect because it's the first correct usage of the word “apocalypse” I've seen in years!
The word “apocalypse” literally means “revelation,” it's only associated with catastrophic events because of the Bible where the revelation _coincides_ with the end of the world.
But here, it's correct, because something previously hidden is actually being revealed!
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
The banter from these two is gold.
Something similiar happened years ago, when a TV show host used a headshot from some artsy nudes, and the upload system didn't strip the EXIF data and people were able to extract the original image.
best video since a time. those 2 rock together
I suspect the switch of the crop/overwrite behaviour may have either come through accomodating SSDs or no longer worrying about accomodating HDDs. In the case of truncate and replace, either it was beneficial for HDDs because it made it more likely to find contiguous blocks (for read/write performance) and the code was deleted/changed to be simpler, or it resulted more blocks changing on SSDs and thus would wear down the drive faster and so was changed, but they forgot to truncate the data after the end.
Another possibility, unrelated to SSDs is that the library handling the image and/or cropping did so by mapping the file into memory, and simply manipulating it in-place there, forgetting to shrink the mapping at the end of the crop. This would save memory because at any time the OS can drop unchanged parts of the file from memory for free if it needs memory, and write the changed parts back to the file at the end or if it needs that memory too. Also, on load thanks to IEND, it would never need to page-in the data after the end of the image because it's never accessed so the large output file would not cause ram usage to increase.
I would still classify it as a bug, since the previous behaviour didn't result in extra large files and the change didn't replicate that.
I'd love to see more videos like this one where there are two experts discussing a topic in a conversational tone while presenting it to the camera. Probably depends on the people involved whether that kind of setup is going to work but at least in this case it worked great.
11:35 The chunk headers in PNG contains the data size for that chunk. Each chunk is
SIZE: 4 bytes,
TYPE: 4 bytes
DATA: (SIZE) bytes
CHECKSUM: 4 bytes.
So you'd just start at the beginning, check the first chunk, skip the data and the checksum, and you're now at chunk 2. Do the same for this and the remaining chunks. When you reach IEND, you can be sure it's the real one. Any data after this isn't part of the image.
So, a lesser aspect of this bug is that your cropped images are all unnecessarily large?
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.
Two of my favourite Computerphile presenters presenting together. Yay! 🎉
Thank you!
I love the play on words. One of my favorite films and a great piece here to educate us. I just did a few tests and made sure my file sizes dropped way down when I cropped with the software(s) I use with any regularity.
This collaboration between the professors is fantastic, more please!!
Actually I would like to have some EXIF data embedded into my photos on Facebook. For example the copyright notice and maybe keywords. Even my camera settings, because that helps other people take photos. It is a problem that Facebook decides to delete all that data without asking the creator. A lot of photos are shared and copied from Facebook and a copyright notice in the EXIF files could make it easier for other people to find the original creator and ask him for permission or even buy a license from him.
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.
Two of my favourite, these are the collabs we need!
I love listening to Mike and Robert
Screenshot-> Crop -> Screenshot-> Send
Wow, i was just reading few days ago an article about this exact problem.
You did such a great job on explaining in simple terms some of the more complicated details.
Loved this tag-team combo. Do more!!! Also, brilliant editing by the video editor.
"The default changed" And this is exactly why I am always explicit with my parameters when making certain types of function calls.
On some phones, you can adjust the crop and even increase the portion shown after the fact.. In that sense it is a "feature", but then it should have to be damn guaranteed to not include any extra bits when you send the image!
Also a side note, I do not know how many times people have told me that I am paranoid only to have the truth to be revealed years later. 😅 I think we need a word for that!
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?
Absolutely SMASHING breakdown. Well done. You know what else? In the 90's, I remember being concerned over the fact that data headers would merely "ignore" old data and NOT zero it out. Sure, it was "faster" back in the day, but obviously... it leads to HUGE issues.
Null data should be overwritten at the end of each 'X' hour period. Or, some systems should zero-out unused bit space upon EVERY instance a file is saved. Again, yes, this is "slow". But obviously... the alternative consequences are far, far more detrimental.
🐲✨🐲✨🐲✨
Nice to see you both again
Fascinating video! Superb explanation and great editing, too.
when you see steve and mike in the thumbnail you know somethings rumbling
You would think the crop tool would rewrite the entire file rather then appending starting from the end of the metadata. Even ancient image editing tools like paint do a full file rewrite when you save.
gotta miss this duo, best duo in computerphile
What goes round comes round.
I remember this from some 30 years ago.
The data on disk between files is often a remnant of previous files and potentially of interest - but normally totally meaningless without context.
I implemented a file access program that could skip to part way through a file and then give a plausible guess as to how the data should be presented - those were fun times.
The Carmageddon 2 reference is very much appreciated
I love the smell of non-re-encoded data in the morning.
That thumbnail is a masterpiece
Sounds like a feature to me. A joy to see.
Funny enough I've known about this bug for years, sometimes PNGs exported from photoshop will show masked data when used as a material map in 3ds max. It's distorted with blocks of colour and other artifacts in the "transparent" areas but enough to tell what was there. It's nice to finally have an answer for this bug. Cheers
That's so weird anyways. I didn't know any phones did that. For Samsung I know for example that it crops, makes an entirely new file called like "originalnamehereTEMP" to send that off through Share and loads of other phone just straight up save the full screenshot regardless and then you cropping it just makes another file.
The example editing is perfect
Funnily enough, when you mention the text document at 8:00, this is exactly how microsoft word worked (with I assume the same kind of end header) until 2003 when they realised what trouble having data you don't want inside a file could cause.
Superb video. Immensely entertaining and very knowledge-dense.
3:28 edition showing what is happening with file is a great adition, tks for that :)
Name a more iconic duo
I remember about 20 years ago, I downloaded a cropped image from the internet. In Windows I set it to show thumbnails. When I looked at the thumbnail I noticed it was the original uncropped image
These animations are amazing
How is it possible that this a new discovery, I’ve been dealing this “bug” for years because the iPhone X takes screenshots that are larger than discord’s file size limit and cropping them doesn’t do anything. There’s literally forums full of people asking why this is the case because it’s annoying, how did that somehow never make its way back to the people who make these systems if this is such a big problem??
I remember coming across this issue on Windows photo apps, Android photo apps, and iPad cloud based photo apps. It was nothing critical but the size of image file will either not change or blow up after cropping. It didn’t happen with all photo apps at any given time, but this has been going on for 10 years I think in some of the apps. Anyway, I usually check file size after cropping, after noticing this bug years ago, but only when I am sending it by email or backing up externally. Word to PDF exporter and some free PDF writer apps have a similar problem. In most cases, writing to a new file and deleting the original fixes the issue.
What a time to be alive
"maybe stand in the back and be a bit blurred"
A+
When the video starts and you see Steve and Mike sitting together, you know sh*t has happened.
This same cropping/redacting issue was happening in PDF files. When you redact a PDF file, the file is not actually modified permanently, and the redaction is "reversible"
Very interesting. Makes me want to learn more about file formats.
7:36 very cleverly timed ad break
Now I'm sort of glad that my phone only does the "save a new copy" as opposed to overwrite
guess we have a new winner of the "underhanded c contest"
Love your channel
The bug reminds me of the old photoshop exif thumbnail problems in the early 2000s. That whole mess drove home how important crossing a file re-encode barrier is for anything requiring redactions.
I particularly love exploits where the software works as intended, but the intended behaviour still leads to a bad outcome. The best example I can think of is using the visited pseudo-class to make visited or non-visited links transparent, and using mix-blend-mode to build a boolean truth table in CSS that results in 2^n letters being displayed on top of each other, with exactly one letter not being transparent. After rotation, translation, and overlay, this looks exactly like a captcha. The browser correctly blocks the malicious JS from probing the pixels of the captcha, which would leak whether each of the n websites are in your browsing history. But you don't need malicious JS, since when a human sees a captcha, the human solves the captcha, performing the attack for us. The JavaScript safeguards work properly, but if the human is tricked into copying a random-looking code into a text box, we don't care about finding a JS exploit or even if JS is entirely disabled. A bug-free browser can't prevent social engineering tricks like this, and it can't be fixed without breaking CSS/HTML5 compliance.
I might be losing my mind, but I swear a similar issue once existed (or maybe still exists?) with iOS-cropped images, but where it seemed to be done on purpose, perhaps with the original image appended wholly to the end of the cropped one, because you were able to go into the Photos app and uncrop images after-the-fact.
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.
This is absolutely a bug. When I take a screenshot, or any photo on my phone for that matter, and I crop it, when I then send the photo, I expect no other additional data besides the bytes relevant to the final photo to be sent. This is an utter breach of privacy, and I'm very surprised to see tech giants such as Microsoft and Google allow customer data breaches like this to happen so easily. If you send a 16 pixel by 16 pixel PNG image, and it's 3 megabytes in file size, absolutely a data breach has occurred.
once you send the photo online, it only sends the cropped part. you need access to the raw data on someone's hard drive to get access to uncrop the image. the file you upload can be much smaller than the original: and we havent somehow just used some sort of super magic compression method. its simply not there. maybe there was an issue on pixel where it was sending the full image for some reason, but it would be extremely obvious that this was happening based on the filesize alone. mass hysteria happening here
That's not bug in PNG format to be designed to allow additional information at the end of the file. Many file formats allow that and it's often to allow future and/or proprietary extensions of the format. That's bug in the phone software leaving information that was never intended to be left there. Saving new data over the old file and not cropping the result to appropriate length is sign of programmer's incompetence.
Wha't the most funny is, it doesn't even help anything with the phone's flash memory. Even in the best case it means worse wear of the flash memory than if the file was cropped.
The "text" files in MS Word format often have this same sort of issue. If you run the "strings" command on the file, you will see stuff that was not supposed to still be there.
This problem exists for all file types not just image files because of increasing file block sizes. The resolution to this problem is not only with the applications but also the operating systems. Specifically, the OS needs to perform secure deletes with blank data overwrites whenever possible - not just marking file blocks and clusters as available for use.
MS Word and Excel files had this problem in the past which exposed data previous from file iterations decades ago. This has yet to be sufficiently resolved.
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.
I thought this was gonna be about the movie apocalypse now.
11:48 - Sure, but the bug isn't that iend appears in the compression. The PNG file itself will contain the data necessary to detect how large the file *should* be, and if it's larger than it needs to be then you *should* be able to just truncate the file down to the proper size. Any data found *after* the proper iend shouldn't exist, so it can clearly be omitted from the file.
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.
Interesting topic and great job with the title ;)
This type of problem was actually known very early in the png life cycle... I remember a method for appending file data to a png that would allow you to read it as a png, but also to read it as only the appended data (I can't remember the second file format, but it had some variable length header and looked for a flag to find the readable part, similar to how mp3 tagging works)
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
I hate most of what the undertale fandom makes but this is plainly amazing, breaking straight through my negative bias.
In an app I wrote a while back trying to learn Swift, I created this exact same type of bug! It kept breaking my app every now and again. I eventually worked out it was related to when a settings file was updated, but it was intermittent. Then one day it hit me that maybe I was just saving the bits of the updated file, and when the new file was smaller than the old file I'd have leftover data because I never flushed out the extra bits at the end of the file. When I reviewed the documentation I realized I called the wrong file save function. 😂🤷🏻♂
You'd think, privacy issues aside, you'd want to truncate the file just to save file size, if you were going to upload or text the file. Though maybe that's why it only changed recently. Image files, even at full resolution are not considered large... at least for a phone's screenshot I guess. I think my phone still downsamples files taken by the camera before sending over text message...
Upvote if you paused and read the messages that got uncropped? Lol.
On the bright side, it's not that difficult to detect the presence of extra data past the end. No need for a deep understanding. Just parse it at a high level. Since each chunk specifies its size, you can skip that far, and then you should be at the next chunk (I'm simplifying slightly, but only very slightly). Repeat until you find the IEND chunk, and then see if its end is the end of the file.
I got laughed at for calling this general type of issue a security issue a decade ago, with one of Microsoft photo apps of the day.
The details were slightly different, but the original thumbnail was recoverable and had enough resolution to be useful/problematic.
"They say of the Acropalypse , where the Parthenon is..."
Apocalypse Now is one of the best anti war movies imho, good choice for the video title :)
So the golden rule is always specify every parameter, even if the value happens to be the current default.
The irony.
png is designed to reduced file sizes, such not to use unnecessary space, but you can add as much useless data to the end of the file making the file larger without using the data at all. (read the most waste of data you can have).
Like if you want to compress data, step 1 should be remove the unused data. Then step 2 could be compressing the remaining data.
Many years ago, I was on a dating site. Sometimes someone would send me a set of photos not in a .ZIP file, but as images in a Word document. Very often the person had used Word's image crop facilities, which do not remove any of the original image data, and you can simply go into each image's properties and uncrop back to the original.
And that's how you sussed out the fatties.
Love you sir❤❤❤
its also worth noting, if this doesn't get brought up, that PNG being able to contain extra data after the image ends is actually an intentional feature that was designed to support things like data embedding, such that you could store something like a 3D model or an image library archve, as a png file, and be able to preview the contents of it in a standard image reader, without needing any proprietary software or special formatting or complicated documentation... you just stuff a zip or tar file after the IEND block and have the picture be representative of that file's contents, and you can easily preview everything in your file explorer's thumbnail without even opening it...
It is a security problem, but its one that is really a fault of people writing software for being too lazy to handle correctly, in my opinion.
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.
My general treatment of images I took on a phone is to import them into a computer for cropping, if I'm going to crop it at all. I can use the GIMP to take a section to the clipboard, open a new file with the contents of the clip and go from there. It's then up to me what I do with the original image-either leave it or delete it. Either way, my cropped image shouldn't contain any extraneous data outside the cropping area. However, I'm aware you don't always want to get back to a computer for that to do the "heavy lifting". It's just the way I've always edited images.
Terrific. Have you considered doing a video on JPEG XL?
I mostly cropped in the hope of saving bytes... what a fool. I believe most services run optimizers on all our uploads otherwise they would lost precious disk space
Love the hair!!❤❤❤
I'm a bit paranoid, but I've always assumed that cropped photos had this problem.
It's hard to say it's a bug. Since the beginning this was often case of file systems. You delete file... in fact you only delete header of file (and even that not completely), data still sits on your disk and can be retrieved. Is it reasonable to assume, when you delete file, you actually don't delete it? I actually noticed similar behavior in word files. When I deleted half the file, I noted size didn't change... What happened, word was tracking all the changes in document within the file and only showing me "latest version after all changes applied". E.g. deleting half the file changed file with little memo at the end saying "this half is invisible now". I could go on and on... In a way it feels this "cropping" has been always happening everywhere, only we kind of ignore "what's behind the technology" :)
Easy solution: Convert the image to BMP, crop, then save as whatever format you wish.
Really strange breakthrough, the point about how many security concerns there are regarding images uploaded to the net innocently containing potentially undiscovered private content is particularly strange...
Hope some helpful resolutions (yes, shamefully intended) are found
This has been a known issue for ages.
Instead of looking for duplicate iEND tags, one could just decode the image and see where the filestream is at after it thinks it's decoded everything.
If the offset is less than EOF then there's more data in the PNG file to be looked at.
It would take more time to do that for every png file, so only do it on files that actually have more than one iEND "tag" in them.