Desktop

Ask something
Discussion Locked

Undo - Redo a security bug.

0 helpful
4 replies

by jaqui

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

Something I have been thinking about for a while.
I submitted the text below to the Oasis Group Technical Committee for development of the ODF.

A security issue with every office document that it might be a good idea to include into the ODF specification.

The history of edits, or "Change Tracking". I know that this is a heavily used feature and cannot be removed from the specification. The problem lies in keeping that history in the document. I do not know of a single person who will retype a letter completely from scratch if they have one that can be modified slightly to meet the current need. This is a common practice even with business communications with clients. The problem with this is that the history will often contain confidential information about the client it was originally written for.

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, 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.

Microsoft's Office format files have the history embedded into them, which was shown to contain every single revision, including a credit card number in one case. This caused me to look at an OOo file and a K-Office file, both have the same issue of storing the history like this, with both using the ODF file specification as default file type.

It will be easier to get the Office Suites to change their handling of history functionality if the specification is changed to require the change tracking to be separated from the main file.

4 replies

by jaqui

That one of the chairs of the TC is from Sun, which sponsors the development of OOo. :D

We might see Open Office as the first Office suite to address this issue effectively ;)
I know that there is no way to get the end user to not edit an existing document for use with a different client.

by jaqui

on the ODF email list.

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 element with an ID. I will give an example, I use the tracked changes example from the OpenDocument-v1.2-draft6.odt

Here comes privacy sensitive information namely the user so

asdfjkasjlkdfhasleugfqo ebt rywshgfac hsdfu3r7t3r578t3r4g3uhgr3lrug

1999-05-18T12:56:04

This is the original textsanhkdbkuwygro783r7803trwoehg3op87eyxeglahsgdhqwgdjhwegr.

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.

edit to add:

This is most interesting because the sender is part of the Open Office development team.

a suprise to not only get responses on a sunday, just before cristmas, but to get serious discussion about the idea that history in documents is a security issue.

by tig2

Had a security policy in place that prohibited end users from using any kind of tracking tool at all. For exactly this reason. But we would still find users who refused to adhere to policy and use the tracking feature.

Unfortunately, security policies are only as good as their enforcement.

Thanks for taking the step of pointing out this security issue to the nice people who will be bringing us the ODF Standards. Hopefully this will result in increased security by default.

:x

by jaqui

the fact I got serious discussion on the issue, on the sunday just before christmas is a very pleasant suprise.

that one commenter on the list seems to be part of the OOo development team is even better.

Though you realise that this is NOT caused by any tracking tools, but by the office suite's own editing history functions?
[ every application has these functions. ]

This discussion is closed to new replies.