February 18th, 2013, 06:48 PM
Join Date: Jan 2013
Carrier: Not Provided
Thanked 2 Times in 2 Posts
^^ This.. It'd be no great feat of coding to create a content provider that's storing to SD as a container file.
The trick would be encrypting/decrypting quickly without ruining the user experience.
However just storing multiple files in a single container would keep most 'snoopy' people from seeing your photos, and would make data recovery a lot easier?
I recall in my Mac days, in the era of System 7, we'd bin-hex Mac files with resource forks, send the ASCII conversion, and then on the other end go from hex->bin to recover the binary fork..
I remember one of the admins asking me about a 'teacher' login breaching the FTP quota due to a ton of files with random names and random contents.. I just laughed and claimed I'd seen it before as a result of application crashes, and told him to either ignore it or erase it, since it's all junk either way.
He just ignored them, and then we all started avoiding leaving enough old files to set off quota alerts.
We also started using 'stuffit' on top of bin<->hex conversion so that even if someone got smart and ran a hex conversion, the best they would get is a proprietary 'stuffit' data file that most admins couldn't open. Heck even then they would probably still get a garbage result because most of the files were Macintosh video games. ;p