Re: Proposal: Personal Data Encryption (maybe SoC?)

On Mon, 19 Mar 2007 18:25, Jim McDonald wrote:
> Clare Johnstone wrote:
>> On 3/20/07, Jim McDonald <Jimmcdee.net> wrote:
>>
>>> continually asking the user to decide which
data is to be encrypted and
>>> which not.
>>>
>>
>> There is the concept of "folders" which
could be used 
>> clare
> True, but that's just another choice to be made when
storing the data 
> plus of course you have filesystem folders, arbitrary
categorisation 
> through tags, automatic classification depending on the
type of data 
> etc. so there are lots of concepts that can be used,
and each one is a 
> potential set of confusion ("I tagged the data as
'sensitive' but the 
> system didn't encrypt it because I accidentally put it
in the 'public' 
> folder).
>
> I just think that this is a good example where having
an all-or-nothing 
> approach is preferable to fine-grained control, as the
benefits are 
> minimal compared to the complexity for development and
day-to-day 
> effort for end-users that have to use such a system.
>
> Cheers,
> Jim.

Ok.. Lets assume for a moment that there is an encryption /
security 
engine.. And its hooked through dbus somehow..  Lets also
assume there 
is a mechanism that handles all requests to save data from
any 
application... Will just call it the save data mechanism..
(Grin)...

So on the encryption / security engine it seems like there
should be the 
ability to define user selectable levels of encryption /
security.. Such 
as no encryption but password required.. Light encryption
password 
required... Heavy encryption picture/gesture required (and
maybe a 
certainty level for fuzzy matching like 90% /shrug).. or no
password and 
no encryption.. Etc.

Ok. There should be some kind of configuration for the save
data 
mechanism which says select the published security levels
(I.e. Those 
the user created in the security config) and then select
which 
applications follow those rules.. So notes could be no
security/no 
password or it could be 'ask me each time'... Calendar could
be the 
same.. File browser could be heavy encryption with picture..
Etc.. Then 
each application does not need to know anything about the
security 
levels at all. It just calls the save information api
(whatever that is) 
and hands dbus the data to save.  The save mechanism looks
at the 
request and notes the application its coming from and then
hands it off 
to the security engine to encrypt appropriately.. And then
it hands it 
back at which point the save data mechanism can write it to
the file 
system..

Reading is the same.. Except the read data mechanism looks
at the 
application making the request and in the case of ask me
data looks at 
the data to see if its encrypted/secured.. If so it tells
the security 
mechanism which asks the user for the appropriate level of
password 
information and then decrypts or authenticates the read
action and the 
user gets to read the data.

Combined with the sudo idea about a configurable amount of
time for 
authorized idleness... And add to it the ability elevate
permission 
levels..  So that once you have authorized to read highly
sensitive 
information you can also just read password protected but
not encrypted 
info.. And then I think it might meet everyones needs.

By default no security is provided and none required..  Once
configured 
it could handle almost any level of detail for encryption
assuming 
someone wanted to go through the trouble of making it happen
that way.

And you could build new security mechanisms that plug into
the 
architecture and allow for some people gesture
authentication and for 
others hand writing codes or voice codes or numeric codes or
anything.

Um... Yeah.. Ok so that might be 10 cents worth.
--Tim

_______________________________________________
OpenMoko community mailing list
communitylists.openmoko.org

http://lists.openmoko.org/mailman/listinfo/community

Re: Proposal: Personal Data Encryption (maybe SoC?)

Thread: Re: Proposal: Personal Data Encryption (maybe SoC?)