Earlier quoted context omitted.
You'd be at the mercy of them potentially changing their encoding scheme unannounced and corrupting your files.
You'd want to make sure the coding scheme is in the identifiable visual data. Think QR codes. Build in a bit of redundancy, and I think it would work.
Unlimited Google Drive storage by splitting binary files into base64
211–220 of 251 posts
Re: Unlimited Google Drive storage by splitting binary files into base64
#212Earlier quoted context omitted.
The checksums in the left column of the listings innocuously looked to the casual observer kind of like line numbers, which may have contributed to their true subversive purpose flying under the radar. Are you implying there's something more interesting there than just the DES source code and related data that the book already very clearly claims to contain?
I don't think so, I think the OP's just trying to be dramatic?
It's a bit dramatic to imply this was covert in anyway.
Re: Unlimited Google Drive storage by splitting binary files into base64
#213Earlier quoted context omitted.
It means if you slip up and lose your domain, nobody can send you email (including 2FA, reset password, add a new email to your account, etc). You can imagine how inconvenient that would be. I use fastmail with a custom domain and that scenario gives me nightmares.
Mostly off-topic, but related: this is one of the major reasons email needs to finally go away. It was never intended to be the backbone of peoples lives in the way it has become. Access to my email account probably gives you more access to my life and identity than my SSN [0]. I long for the day that we [1] all get assigned a public/private keypair instead of SSNs. That won't fix everything, but it's a huge step abo…
What is the remedy for when someone loses or leaks their keypair?
Re: Unlimited Google Drive storage by splitting binary files into base64
#214Earlier quoted context omitted.
Seems like a good way to earn yourself a Terms-of-Service ban. If this considered an abuse-of-services now, the terms could be updated to clarify. The finger print of big chunks of base-64 encoded blobs in Google Docs could be easy to spot. If Google cares to notice this and take action, they can and will.
It's an arms race situation. Once you give me an information channel like a "word document", I've got an endless variety of ways to encode other things into it. I can encode bits as English sentences or other things that will be arbitrarily hard to pick up by scanning. If I were Google, I wouldn't try to pick up on the content, I'd be looking for characteristic access patterns. It's harder to catch uploads, since "ne…
I'd say most certainly do not try this. Do you want to loose access to your gmail, maps, contacts, whatever else you rely on Google for, because you were found abusing google drive?
Re: Unlimited Google Drive storage by splitting binary files into base64
#215I don’t know anyone remember but some years ago I remember seeing a file compressed from 1GB to 1mb. And I was amazed.
Re: Unlimited Google Drive storage by splitting binary files into base64
#216Earlier quoted context omitted.
You'd want to make sure the coding scheme is in the identifiable visual data. Think QR codes. Build in a bit of redundancy, and I think it would work.
It would probably work, yes. But I don't think many people want their backups powered via a service that "will probably work".
I really do think videos would would work, reliably, given sufficient redundancy. Again, we have QR codes already, so this is a proven idea. You can't make QR codes unreadable without removing lots of perceptual visual details. The risk, as with using Google docs, isn't that Google will change their encoding, but that Google will just take down the videos for service misuse.
I think it would be comparatively more difficult for Google to detect this stuff in a video compared to a text document, because you expect some videos to be long and large. The entirety of the Encyclopedia Britannica comes out to less than 500 MB in a .txt document, so using any reasonable amount of space in a Google Doc should quickly raise red flags.
Re: Unlimited Google Drive storage by splitting binary files into base64
#217In 1998, the EFF and John Gilmore published the book about "Deep Crack" called "Cracking DES: Secrets of Encryption Research, Wiretap Politics, and Chip Design". But at the time, it would have been illegal to publish the code on a web site, or include a CDROM with the book publishing the "Deep Crack" DES cracker source code and VHDL in digital form. https://en.wikipedia.org/wiki/EFF_DES_cracker https://www.foo.be/doc…
It seems like a cute and irrelevant distinction that electronic software would be published in a book. If researchers created a computer that processed information using proteins in plant cells instead of electrons, and such a computer could execute programs on this book directly instead of “scanning” it, would not the textbook be software? When laws say “electronic versions” I don’t think they literally mean to refe…
To what extent does analog encoding fall under the illegal threshold?
Re: Unlimited Google Drive storage by splitting binary files into base64
#218https://gist.github.com/retroplasma/264d9fed2350feb19f977575...
TL;DR: An alternative to NZB, RAR and PAR2. Private "magnet-link" that points to encrypted incremental data.
Re: Unlimited Google Drive storage by splitting binary files into base64
#219Very cool! About a year ago I had a similar idea, but to store arbitrary data in PNG chunks[1] and upload them to "unlimited" image hosts like IMGUR and Reddit. [1] http://blog.brian.jp/python/png/2016/07/07/file-fun-with-pyh...
Re: Unlimited Google Drive storage by splitting binary files into base64
#220In the same spirit, I made a few "just for fun" plugins for my (now abandoned) encrypted-arbitrary-storage Dropbox-like application Syncany: The Flickr plugin [1] stores data (deduped and encrypted before upload) as PNG images. This was great because Flickr gave you 1 TB of free image storage. This was actually super cool, because the overhead was really small. No base64. The SMTP/POP plugin [2] was even nastier. It…