OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-comment] Change Tracking issue


Hello all,

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.
I would like to whish you all happy christmas and a very good new year.

Yours,

Timo Hartong










[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]