Proposal: Personal Data Encryption (maybe SoC?)

[Tim Newsom]

On Mon, 19 Mar 2007 18:25, Jim McDonald wrote:
> Clare Johnstone wrote:
>> On 3/20/07, Jim McDonald <Jim at mcdee.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