Quote:
Originally Posted by brianinmaine
This is an unusual idea.
What do you envision this used for?
I have a Touch, and might try it, but can't think of any reason?
|
Thinking of a reason is the hard part of this suggestion.
Thinking of a reason that couldn't be accomplished with a simple file transfer is even harder.
- - - - -
Question:
What use-case would require that the originating device **not** create a file?
Ans:
Both devices (the Kindle's flash and the other device's something) using semipermanent memory.
Say, maybe flash or SSD drives.
PLUS:
The Kindle is physically secure and the other device is not physically secure.
Then you would not want to write (or print spool) the output of a program to the storage memory of the un-secure device.
Because it could be physically stolen, the memory chip(s) removed, peeled, the micro-controller hacked, and the erase blocks not in use read.
(A really big technical challenge, but a serious concern among manufacturers and users of big SSD drives.)
Hmm...
Still pretty far out -
And I still don't see why this use-case could not be answered by running a TrueCrypt (or the ms equivalent) storage partition on the originating device, and writing a file to it for later transfer to the Kindle.
- - - - -
No one ever asked for a secure storage facility on their Kindle that I can recall.
So we (twobob and I) never did try creating a LUKS partition (or a file-as-a-device) on the Kindle.
(We did discuss it, as part of a non-public project.)
But I am pretty sure that the kernel version(s) used in any of the touch screen Kindles is new enough to support it.
- - - - -
Perhaps this suggestion was just to answer the technical challange and does not have a (practical) use-case.
