Proposal: Personal Data Encryption (maybe SoC?)
Joe Pfeiffer
jjpfeifferjr at comcast.net
Fri Mar 23 18:40:21 CET 2007
Gabriel Ambuehl writes:
>On Friday 23 March 2007 18:01:09 Joe Pfeiffer wrote:
>> >~/file1
>> >and ~/encrypted/file2
>> >seems a lot easier to implement AND use to me...
>>
>> Implement, yes (since it's already been done). Use? I don't think
>> so.
>
>You can actually use it right now, with almost every app (except for those
>broken enough to use hardcoded filenames), without any hacking. Most of the
>neat features mentioned above are app level anyhow which is very well
>possible...
>
>Now, for a (IMHO) truly useful extension: find a way to cache writes and
>encrypt them with a public key so that creating new files (for example
>because you just received a SMS) can work while the phone is locked. Once the
>phone is unlocked, decrypt the data and store it in the encrypted FS.
I'll need a phone to explore that...
>Maybe it's just me, but pefs seems vastly over engineered. Which is generally
>a bad thing when it comes to encryption...
Hmmm... I don't see a lot of over-engineering there; just what's
needed to support the use case that best matches my intuition of what
a user will find most straightforward (well, OK, allowing keys other
than a single password, maybe). But then, as the guy who wrote the
description, I wouldn't be likely to.
Beyond that, I think we're at a real YMMV point; what I see as the
most straightforward approach for a user is something you see as too
much work to implement for not much (if any) benefit; what you see as
a straightforward way to work and an easy interface for a user I see
as awkward. And since we're both spouting opinions, there's no way
to do a real comparison without a prototype.
More information about the community
mailing list