3 ms·
time to start changing the hash by adding a few bytes to your movies before uploading to Google Drive head -c 20 /dev/urandom >> movie.mp4 won't affect play
by ricktdotorg 2y ago
time to start changing the hash by adding a few bytes to your movies before uploading to Google Drive
head -c 20 /dev/urandom >> movie.mp4
won't affect playback, will affect Google finding your pirated films.
- nick238 2y agoSeems like this would corrupt the file. There are plenty of metadata fields you could just put some crap in (or just transpose letters in an existing string so you don't need to change any length markers.
- ricktdotorg 2y agoi've never had any problems with playback using the major vid players on Linux with files i may or may not have used this trick on.
- nomel 2y agoI would really hope they would ignore the metadata, when computing the hash, for this very reason. Properly tagging films you download isn't exactly rare.
- toast0 2y agoMost media files are likely to tolerate random garbage tacked on to the end of the file. ID3v1 tags are essential proof of that; 128 bytes of garbage at the end that didn't cause any trouble with playback.
- wongarsu 2y agoThat depends on the container format, and with some container formats on the parser. Any container format designed to be streamable would by definition survive corruption at the end. Provided the player doesn't get too upset if any metadata at the end is corrupted, but e.g. VLC handles such things quite well
- delecti 2y agoAs a fun example of "depends on the container format", one trick people used to use for sharing files on image boards (4chan and the like) was to concatenate a rar file and jpg file. I don't remember which order it was, but one of the two used a header (read start to end), and the other used a "footer" (read end to start), so you could use it either way depending on what you opened it as. I still have a handful of files which are books in PDF format in a RAR file, and simultaneously the book's cover as a jpg.
- cowboylowrez 2y agoI remember this too but with jpgs and zips, if I remember, jpgs go first as zips have the metadata at the end of the file (to the best of my knowledge, corrections welcome).
- alfalfasprout 2y agoThey may be doing locality sensitive hashing in which case this wouldn't matter.
- rakoo 2y agoI'm pretty sure Google engineers are smart enough to detect quick workarounds that fit in a comment on Hacker News. They already have to implement such a thing for finding copyrighted material in Youtube videos, so they know how to deal with mixed signals.
- HenryBemis 2y agoOr if they didn't think about this, they know do after reading this thread :)
- rakoo 2y agoMy guess is that the very minimum they do is cut files in small blobs and analyze each one separately, so that kind of scheme (or adding random junk at the beginning or the middle or zipping it or ...) doesn't work.
- Hizonner 2y agoEncrypt the file and don't upload the key.
- glitchc 2y agoThey block it outright, even when the purpose is innocent (sensitive documents). Tried with rar and 7-zip.
- Hizonner 2y agoWow, really? You can't store an encrypted file on Google Drive? I guess I shouldn't be surprised, but I am, mildly. ... so it has no utility at all, since you definitely shouldn't be storing any unencrypted files on it.
- BXlnt2EachOther 2y agoThat doesn't seem to be most people's experience, see sibling posts. As another data point, I have several manually-uploaded zip and 7z files of my own documents and content, both encrypted and not, and never had a problem. The majority of my Drive usage by bytes is encrypted backup pack files uploaded via API by Arq Backup or rclone. That's all worked fine for many years.
- gazby 2y agoAre you using this technique successfully? I'd assumed they were using phashes or similar.
- xk3 2y agoyeah I'm pretty certain they are re-using what was already in use by YouTube which is based on perceptual hashes