'Re: undo - redo, a security issue'

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

List:       koffice-devel
Subject:    Re: undo - redo, a security issue
From:       Jaqui Greenlees <jaqui_greenlees () yahoo ! ca>
Date:       2007-12-25 10:18:05
Message-ID: 981419.30908.qm () web38101 ! mail ! mud ! yahoo ! com
[Download RAW message or body]

--- andre@familiesomers.nl wrote:

> Hi,
> 
> > This is an interesting problem.
> >
> >> I propose that the ODF address this issue by
> requiring
> >> that such history data be stored in an external
> file
> >> rather than the original document by default
> >
> > Perhaps a simpler option might be to prompt the
> user to avoid storing
> > the history when saving a document under a new
> name?
> 
> I agree, that sounds like a more feasable solution.
> Storing the history
> seperately will result in documents no longer
> consisting of a single file,
> resulting in huge file management problems IMHO. I
> too think that when
> using Save or Save As, one should have the option
> not to store the
> history. That default should be "store" for Save,
> and "not store" to Save
> As, I think.

From the TC list comment on the history lost
suggestion:
"
>
> However, I am not yet fully convinced that a
separate file is necessary. But there should be a
mechanism to ensure that confidential information is
not passed inadvertently to persons not intended to
view such confidential information.
>
> A possible solution is an option that requires that
all tracking changes are deleted IF a document is
saved with a different name. This should be set by
default.
Interesting suggestion but what if I want the tracking
changes even if the document is saved with a different
name?

One of the changes that will be introduced for
metadata in ODF 1.2 is the ability to have
asynchronous metadata for an ODF document. That is you
and I can maintain separate metadata for the same
document, say in a contract negotiation situation.

> On the other hand I think we should stimulate not
> using a wordprocessor
> format as a document format one would distribute
> outside one's own
> organization. PDF is much better suited for such
> communication. That is,
> in the end, of course not something one could
> enforce in the word
> processing software, but we should make it easy to
> make a "final" document
> one can savely send to clients.
> 

The latest proposal on the TC comments list on this
subject:
If I may I would like to make a comment concerning the
"Change Tracking" issue. Therefore I go back to the
original mail of Mr. jaqui-greenlees.* *And to a
particular part of his mail:
*
*

"...to make ODF files meet all regulations pertaining
to data
protection [ Privacy Protection Laws ] and reduce the
risks of account
specifics being passed on to those with no right to
them..."

So this discussion goes about the authorisation of
somebody to see particular historic data as Mr.
Leonard Mada pointed out in his mail

"...But there should be a mechanism to ensure that
confidential information is not passed inadvertently
to persons not intended to view such confidential
information..."

So the question is : "how do we protect privacy within
the ODF specification". We could even extend the
question : "How do we protect data within the ODF
specification against onauthorised access". In my
opinion the question in what file location this is
done is not interresting, at least not from a
technical point of view.

To accomodate this we could encrypt data. The problem
at this moment we only can encrypt entire files. ( See
OpenDocument-package-v1.2-draft6.odt par 2.3) what
would be usefull is that we can encrypt data within
all data containing elements. We could introduce a
<crypt region> element with an ID. I will give an
example, I use the tracked changes example from the
OpenDocument-v1.2-draft6.odt

<text:tracked-changes>
   <text:changed-region text:id="c001">
       <text:insertion>
           <office:change-info>
            Here comes privacy sensitive information
namely the user so
               <dc:creator>
                          <crypt region
crypt:id="crypt00001">

asdfjkasjlkdfhasleugfqo ebt    rywshgfac
hsdfu3r7t3r578t3r4g3uhgr3lrug
                           </crypt region>
               </dc:creator>
               <dc:date>1999-05-18T12:56:04</dc:date>
           </office:change-info>
       </text:insertion>
   </text:changed-region>
</text:tracked-changes>

<text:p>
   This is the original text<text:change-start
text:change-id="c001"/><crypt region
crypt:id="crypt00001">sanhkdbkuwygro783r7803trwoehg3op87eyxeglahsgdhqwgdjhwegr</crypt
region><text:change-end text:change-id="c001"/>.
</text:p>

This tag gives the following advantages:
- ODF consumers can restrict access to data at user
level. (This accomodates the request of Mr
jaqui-greenlees and Mr. Leonard Mada)
- The user of the ODF consumer can indicate to even
letter level which he want to protect to unauthorised
access.
- The user of the ODF can also simply choose to turn
the feature off all together or tunr on at individual
letter level.
- The methode can accomadate requirements at Law
level. There could be laws where it is illegal to
encrypt data or where the user is required to give the
possibility to encrypt the data by handing over data
needed to encryopt the data.

The tag gives the indication to the ODF consumer that
the following information is encrypted and the ID
gives the possibility to grant access to user level.
The ID could point in the end to an XML file which
contains data which is necessary to decrypt the data.

If you say the "proposal" needs some workout I fully
aggree with you but such a tag would have great
benefits you can restrict access in all levels of
document and so also protect the privacy of users of a
document.
"

The whole purpose of starting the topic was to get
people thinking about how to address the issue, I'm
not going to defend any one course of action, as long
as there are people who really know the code base
thinking about how to address the issue.

FWIW, Kword hasn't enabled the change tracking section
of the ODF yet. The issue goes beyond word processors
though, since spreadsheets, presentations etc also
have this history function in the document
specification.
I included the list comments to make sure that no-one
does any work that would wind up being scrapped later,
if there is an easier solution incorporated into the
file specification.

Jaqui

      Looking for a X-Mas gift?  Everybody needs a Flickr Pro Account.

http://www.flickr.com/gift/

_______________________________________________
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] 