Hacker News Reader

Comment by ricktdotorg | Hacker News Reader

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.

View on HN

I'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.

Or if they didn't think about this, they know do after reading this thread :)

Encrypt the file and don't upload the key.

They block it outright, even when the purpose is innocent (sensitive documents). Tried with rar and 7-zip.

Wow, 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.

That 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.

Sorry, I may have conflated Gmail with GDrive, my bad.

IIRC I did get a roadblock attaching a zip file with GMail several years ago.

GMail also complained about direct-attaching a locally-built, unsigned exe file to an address that I'd never corresponded with. To be fair this probably should have caused suspicion :)

anecdotal / N=1 here, but I've uploaded standard 7z encrypted backups to personal Drive without issue

This is trivally disprovable. Everyone has countless encrypted files on gdrive. What do you think a keepass db is for example?

Definitely not true. Source: have .zip and .rar files in Google Drive

Perhaps you’re on a ‘list’ for questionable content.

That might be an issue with rar and 7-zip specifically. RAR at least used to be very common with warez and not very common out of it—might just be a low-effort way of discouraging it.

Not endorsing this, btw, I much prefer dumb pipes.

Seems 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.

i'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.

I 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.

Most 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.

That 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

As 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.

I 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).

Are you using this technique successfully? I'd assumed they were using phashes or similar.

yeah I'm pretty certain they are re-using what was already in use by YouTube which is based on perceptual hashes

They may be doing locality sensitive hashing in which case this wouldn't matter.

Reply on news.ycombinator.com