On Wed, 21 Mar 2007 14:35, Joe Pfeiffer wrote:
But it has the "encryption jail" drawback.
So maybe one way to deal with these issues is to build out the framework by constructing a new api for reading and writing data based on this provider concept.. Including the authentication. Then deal with and flesh out the issues we encounter along the way. At the same time or sometime later, another task can be started to hook into the os level read/write calls and make it work for every application the same. Maybe as some kind of layered filesystem driver or something, I don't know.
Anyway, the point is that there are many many tasks to deal with related to the entire framework for this to work at all, right? And in the short run, all OM applications have a specific api anyway to make them work with the gui etc.
The risk to security of doing it this way is minimal as using a program without the encryption hook just means that the program sees an encrypted file. Sure, it could damage the file if it wanted but for the most part the information will remain secure once encrypted with whatever mechanism.
Later once the framework is up and some demo plugins are in place to show encryption providers and authentication providers and data readers/writers for various filesystem/database flavors, maybe we can deal with the issues related to 'all other applications'. That is, unless someone just happens to know off the top of their heads that its about x lines of code to do this by hooking into the os read/write routines with x being some number less than infinity?( ok, that was meant as a little joke)
--Tim _______________________________________________ OpenMoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
