[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Some details about encrypted documents
From:       Thomas Schaap <t.m.schaap () student ! tudelft ! nl>
Date:       2007-02-19 5:49:37
Message-ID: 45D93A71.2090002 () student ! tudelft ! nl
[Download RAW message or body]

Hi,

I've been implementing encryption for documents in KOffice for some time 
now. I've taken quite some time, but it's definitely done, except for 
some details.

Most important of all, I need a generic thumbnail for an encrypted 
document. Since a thumbnail is required by the ODF standard, but an 
encrypted document logically shouldn't have a picture showing it's first 
page to the whole world, the standard also suggests using a generic icon 
for these. I don't know if any icon for this exists. If not, where can I 
place a request for it?

The rest of the issues to be solved concern usability, mostly. First of 
all the description: the implementation simply lists encrypted 
opendocument in the list with filetypes in the save-dialogue. Currently 
it's named 'OASIS OpenDocument SpreadSheet (encrypted)' in KSpread. It's 
the '(encrypted)' part I'm interested in, of course. Is this a clear 
description or should it be changed? Alternatives are '(with password)', 
'(password-protected)' and the like.

A possibility I have not implemented yet is for applications to retrieve 
the password the user gives when opening a document. One possible 
use-case for this is not asking the password again when the user saves 
the document. It's a use-case with two sides: on one side there's the 
usability of not having to enter the password again and again, on the 
other side there's the insecurity of not needing the password to make 
changes once the document is open. I'm not sure, at the moment, which 
one of these is more important.

Last but not least there's autosaving. Currently autosaving of encrypted 
documents is disabled by hardcoding. In it's current implementation 
encrpyted autosaves can't be handled by Ko2, for the simple reason that 
autosaving would require the user to enter the password, which is rather 
cumbersome. Deciding on having the application know the password of the 
opened document (see above) would immediately solve this problem, but 
deciding against it leaves another question to be answered: should we 
enable (or give as an option?) unencrypted autosaving of encrypted 
documents? It gives the user more protection against loss of work, but 
does allow an attacker with access to the computer to determine the 
contents of encrypted files without having the password by reading the 
autosaves.

I'd like to know the opinion of you folks before pushing my own 
decisions on end users.

Kind regards,

Thomas Schaap
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]