Proposal: Personal Data Encryption (maybe SoC?)
cephdon at gmail.com
Tue Mar 20 02:57:28 CET 2007
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 :)
> 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'
> 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.
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
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.
More information about the community