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
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.
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
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!
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.
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.
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.
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.
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.
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
Props to the editor for the diagram at 3:25
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.
best video since a time. those 2 rock together
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.
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.
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
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.
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.
The banter from these two is gold.
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.
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.
This collaboration between the professors is fantastic, more please!!
Loved this tag-team combo. Do more!!! Also, brilliant editing by the video editor.
I love listening to Mike and Robert
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.
🐲✨🐲✨🐲✨
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.
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.
Two of my favourite, these are the collabs we need!
Fascinating video! Superb explanation and great editing, too.
Nice to see you both again
when you see steve and mike in the thumbnail you know somethings rumbling
I love the smell of non-re-encoded data in the morning.
Superb video. Immensely entertaining and very knowledge-dense.
gotta miss this duo, best duo in computerphile
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?
Sounds like a feature to me. A joy to see.
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.
"The default changed" And this is exactly why I am always explicit with my parameters when making certain types of function calls.
Screenshot-> Crop -> Screenshot-> Send
These animations are amazing
3:28 edition showing what is happening with file is a great adition, tks for that :)
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
The Carmageddon 2 reference is very much appreciated
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.
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
Very interesting. Makes me want to learn more about file formats.
What a time to be alive
Love your channel
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"
That thumbnail is a masterpiece
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??
Now I'm sort of glad that my phone only does the "save a new copy" as opposed to overwrite
I thought this was gonna be about the movie apocalypse now.
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
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.
When the video starts and you see Steve and Mike sitting together, you know sh*t has happened.
Interesting topic and great job with the title ;)
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.
Name a more iconic duo
Love the hair!!❤❤❤
guess we have a new winner of the "underhanded c contest"
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.
i've always been paranodi abotu this kind of stuff so whenever i want to crop something, i take a screenshot, copy the bit i want, paste it onto a new file before sending it lol
Upvote if you paused and read the messages that got uncropped? Lol.
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...
"maybe stand in the back and be a bit blurred"
A+
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.
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.
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.
"They say of the Acropalypse , where the Parthenon is..."
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.
amazing!
I'm a bit paranoid, but I've always assumed that cropped photos had this problem.
I found something similar to be true on iPad/iPhone screen captured video when it’s cropped, even when you create a new file. The new cropped and trimmed video can be reverted back to its original size, at least on the same device. I’m not sure if it’s a copy it reverts back to, or if the cropping is simply done by markers over the full video. Does this new cropped and trimmed video file contain the uncropped data (not the trimmed ones) when it’s sent to another device over iMessage for example?
Love you sir❤❤❤
5:49 Mike is a menace 😂
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.
7:36 very cleverly timed ad break
Terrific. Have you considered doing a video on JPEG XL?
This has been a known issue for ages.
Having two pundits in the same video might not be the best idea.
I remember years ago receiving images, censored images but the thumbnail was intact. I don't know which editing software the other person was using but it didn't bother to update the thumbnail data.
new to me that the old extra data isn't lost on the save
yeah i noticed this a few months ago. it’s why i always screenshot my screenshots and delete the first
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" :)
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.
So the golden rule is always specify every parameter, even if the value happens to be the current default.
Apocalypse Now is one of the best anti war movies imho, good choice for the video title :)
Would that be possible for videos too🤔
Like cropping videos to send on social media... because thinking about it, it's probably happing when it comes to cropping a video frame but the video itself would be something even scarier
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. 😂🤷🏻♂
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.
This reminds me of the 2008 Underhanded C Contest
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.
Mmh on Samsung phones you can actually revert cropping. I don't know if they do that through additional metadata (like, original image + stack of post-processing settings), or using a sepatate backup copy. But I thought that the bug was related to that, sharing the image with the "cropped info" instead (which I used to be scared by).
Yeah, I thought I was going crazy when I found out about this "bug" because samsung phones tout this as a feature of cropping (I think with all formats) and it's mysterious to me how they do that.
As you said, they could be doing it with a separate copy but I've always been skeptical of cropping an image to delete unwanted parts of the image (save from a proper image editing tool) though on samsung phones cropping *does* reduce file size.
@@Tomyb15 For my phone, this is an option in the settings, "Save original screenshots" with the description
"This lets you revert to the original screenshots after editing them in Gallery, but it uses more storage space."
So from that description, I assume that they simply save the original screenshots in a way that they're _hidden_ from your default Gallery app, but are still very much there. I doubt they're saved in the same file, that just seems like it'd more trouble than it's worth.
That's just called saving the original crop.
Let’s say I take a screen shot of a private dm and I don’t want anyone to know who I’m talking to. I can use markup option on my phone to scribble out the name of the person in the dm. Is it possible that I could remove scribble data from the image to see the name of the user in the dm?