Proposal: Personal Data Encryption (maybe SoC?)

[Knight Walker]

On Tue, Mar 20, 2007 at 03:06:18PM +0000, Jim McDonald wrote:
> Yep I understand that there are lots of possibilities and options, I
> just think that if something ships by default it should provide end
> users with a very simple dialog that is basically an on/off switch for
> 'protection of personal data' (or something else that doesn't even
> mention encryption) and the additional levels of configuration can be
> made available through plugins or whatever.

I agree, to an extent.  I've used a lot of security programs on a lot of     
handhelds and I would like something that's sort of a cross between the
way Palm OS does security and the way GNOME does security.

On PalmOS, each record has a "private" flag that can be set.  In the OS,
there is a setting for what to do with "private" records, either hide      
them, redact them (black them out in listings) or show them.  If we could
combine this with a system daemon that keeps the encryption key in memory
for a user-selectable amount of time (1 minute, 5 minutes, until sleep,
etc), then it would minimize the annoyance factor of having to type in
your password all the time while still having a per-item level of
security.  A system encryption engine would also allow the user to select
their level of security (light vs. strong) and possibly be extended to
keep multiple keys/encryption schemes.

For anything beyond that, it may have to be implemented through plugins
or as a stand-alone encrypted message application (a.la CryptoPad on
Palm or ZSafe on Zaurus).

> Perhaps I've spent too long battling with ugly interfaces, but I think
> that if OpenMoko is going to have a broader audience than the people on
> this list and their kindred-in-geekness then a large amount of the
> effort will be deciding how to keep the interface as simple and
> streamlined as possible rather than loading the default build with every
> option imaginable...

A wise man once said something to the effect of: "make it as simple as
possible, but no simpler."  Some things may need to be more than a 
check-box, but I doubt things will end up needlessly complex.

I think to avoid ugly interfaces, we will need to make things somewhat
abstracted and flexible.  That way if v1 is rather ugly, then v2 could be
made better without overhauling the entire thing.  And the interface
should be kept separate from the implementation, so one can be updated
without breaking the other.  Probably something that talks through DBus to
a storage engine of some kind.

-KW