Proposal: Personal Data Encryption (maybe SoC?)
Tim Newsom
cephdon at gmail.com
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)
--Tim
More information about the community
mailing list