[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-comment] Change Tracking issue
lists <lists@jaqui-greenlees.net> wrote on 12/28/2007 01:24:37 AM: > Ok, just a bit of information. > I have seen several people comment that security shouldn't be a part of > the file format specification. > They might need to re-assess that position: Without trying to argue, what exactly do those standards you quote say about security? Their titles at least appear to be quite general and may apply to firewalls, user authentication protocols, and encryption of entire filesystems on disk. They do not appear to be so specific as to define the contents of data files for particular applications. I haven't read them, so it's an honest question. I do not think anyone has argued that security should not be standardized. The point I was trying to make is that it is just not an office application's business to interfere with whatever security measures are configured for the system upon which it runs. Hence, there is no need for a data file to contain support for encryption of a "segment". Just use linked content and deny access to the restricted bits using the system facilities. Put another way, to run an office application on all modern systems, you must be logged in, correct? Authentication has already taken place and you should already have access to all the files you're allowed to see. Denial of content is a responsibility which lies with the OS, not an application/application's data file. The original concern with change tracking was that office file formats did not allow users to remove sensitive content from "reused" documents because it was always retained in the change tracking. This means that users are forced to send sensitive information to those who should not be allowed to have it. Two camps have formed: 1] Remove sensitive information from the document before you send it. 2] Keep sending the sensitive information to people who shouldn't get it, but give users the option of "securing" it first. My suggestion about the live filesystem format is a solution which allows users to retain versioning information separately from the current document content. It implements #1 while vastly augmenting the change tracking abilities. Best of both worlds. Bryce
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]