Proposal: Personal Data Encryption (maybe SoC?)

Tim Newsom cephdon at
Wed Mar 21 22:59:23 CET 2007

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)

More information about the community mailing list