Back in high school in ye olden days of 2003, the trick was to put a powerful magnet on your floppy disk prior to turning in the assignment. Floppy disk failures weren’t too uncommon, so it was hard to prove intent.

Frankly I’m amazed computers were trusted by anybody back then. Imagine if iCloud randomly corrupted 1 in 100 photos.

Seriously, the magic of error correction is hardly appreciated or noted by younger hackers these days.

I had one important project (I don‘t remember anymore which one it was), so I put it on THREE 3,5‘‘ disks, one after each other.

All three were unreadable by the time I arrived. I was devastated.

(note I had heard stories about rotating current brakes ruining disks so I took care not to go by rail, must have been something else)

Not exactly the same story, but there was this one time when I was working on a long document, several days work, on an Amstrad PPC 640 (this was the early 90s). Saving the file on a floppy took around 1 minute I think (maybe more) so I didn't do it often and had no copy or backup of any kind.

It was around midnight, I was done and hit save. I had an external monitor, and for no particular reason, decided to move it around during the save. It was big and heavy, and while moving it I accidentally hit the power switch of the PC.

Powering off the machine during disk write destroyed everything. I couldn't believe it, I stared at the machine for a while.

Then I spent the rest of the night recreating the document from memory, while making frequent copies on different disks.

It was a horrible moment that I remember vividly, but it taught me a valuable lesson. I never again lost any file for lack of appropriate backup.

Either the drive you wrote the disks on, or the drive you used to read them, were misaligned.

Putting the disks back in the original drive and they probably would have been readable.

And they computers don't have a sense of humor.

To be honest if iCloud corrupted 1% of my photos I’m not sure I would notice.

1.44 MB pretty much fits in my head.

But “infinite” storage over 15 years now? How would I even audit that?

> 1.44 MB pretty much fits in my head.

That the size of a zipped plain text bible.

There are some people that knows the bible by heart, and I suppose if you work with it a lot, you have a general idea of the order of all things, and what's going on in each part without having to know the exact words. Like an essay you've been working on for months.

So seems about right.

Maybe it's time for a new metric: 1 floppy is what you can hold. More is too much.

More like what you can hold as a single entity in your head. The sum of your knowledge is vastly more than that.

Yes.

I can memorize so many docs and API, but there is a threshold for a project size above which I cannot hold the entire code base in my head.

You'd be surprised how much data "cloud" services lose or intentionally delete every year.

That man believed in teaching more than what was in the textbook. Kudos for the lesson in integrity.

how could he be sure the kid did it though, seems like he should have better proof than the file was screwed up.

The hex was clearly corrupted manually, something had been typed there. I don't think it was just the word "fuck" but I think the word "fuck" was in it. Was decades ago.

Ah, it was only "hjfsagufsaiugasfigsaigsg78wafg7fas fuck you teacher! fhadiuofashofhsaibsaiu" Notepad corruption? Huh, that's a fun one! /s But seriously, I'm impressed by that teacher.

What could parent complain about? I'm lost.

There are ways to corrupt a file without messing with the hex content of the file

No there isn't. It is a fundamental property of CS that all bitstrings with the same bits are equivalent for computing.

So if file 1 is a bitstring, you don't modify the bits to produce file 2, then file 2 has the same bitstring and will be processed the same as file 1.

Not the parent and not sure what s/he meant, but one could imagine software that borks when there are invalid (but nonobvious) characters in the filename, for example. Or file permissions or other extended filesystem attributes / resource forks if somehow you can get them delivered to the teacher that way.

The files are also often delivered via USB Stick which are usually formatted with a filesystem without bitrot detection. That would be indistinguishable from someone manually screwing with the file too.

You can never be certain wherever the damage was caused by bitrot or a person screwing with the file, but certain patterns are very unlikely to occur naturally so a reasonable guess is at least somewhat possible

My whole form of copy protection on AIR apps through about 2013 was basically to have the login system side-load another SWF once the user logged in - but the SWF's bytecode would be tweaked and corrupted in a way that required a valid response to the login to de-corrupt on the client side before it could be executed. Probably just the fact that you would've had to decompile the side-loader was enough to prevent it from being stolen.

Hey, I had a similar copy protection scheme for binaries during the 90s :)

Hah. It's pretty awesome to hear that from a Firefox dev. I look back at it and wonder... what was the point? I think I was just having fun. I even went as far as having two "patches", where the first one made the software work but without the second one, it would send your VM and browser into a death loop after about 30 seconds. It was just the right amount of time to cause an SWF decompiler on Windows to crash the whole system. Anyone who wanted it badly enough would have gotten it, and I doubt anyone ever put in the effort to hit that spiral, so I must have just been entertaining myself ;)

Based on OP comment about showing the hex to the clas, my bet is the perp opened the file in notepad, jammed on the keyboard (ascii characters) or worse yet, typed a message proceeding or following the content (depending on the format), making it very obvious that it was an intentionally introduced error.

You could just do what I did instead. To make it less evident that it was tempered with, I'd copy a random chunk of the original file and insert it a few times with random offsets.

Another way: corrupt the formatting such that the file doesn’t show anything. Think the equivalent of adding a CSS property like body {margin-left: -10000px}. File would be perfectly valid but display as blank.

That's not too useful when plenty of students just send in a plain blank document. Corrupting it in one way that looks like a -different- way of slacking isn't so useful.

Why not send a blank file then? The point is that you want the editor to error and fail to read so they can’t tell that you didn’t do the work.

Because a blank file will have a tiny file size and will look like... a blank file. You want it to look like something went wrong such that the file couldn't be opened, but that it would have content if you could.

I'd bet that for the average tech illiterate teacher that's used to lazy students, it would be more work to explain how it could possibly NOT be the student's fault if they got an empty(looking) docx.

Mr. McGuire : I just want to say one word to you. Just one word.

Benjamin : Yes, sir.

Mr. McGuire : Are you listening?

Benjamin : Yes, I am.

Mr. McGuire : Metadata.

(also see https://en.wikipedia.org/wiki/Resource_fork)

"The Windows NT NTFS can support forks (and so can be a file server for Mac files), the native feature providing that support is called an alternate data stream."

you could just truncate it at page (4k multiple) boundary. very hrad to prove intent