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

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

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.


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