Glenn Skinner wrote:
> I think I know what happened, and it's my fault. When Mark sent me
> his (very well done) opinion.ms draft, I had to work on the formatting
> of the interface table a bit and left the original behind as
> opinion.ms-. But although the redaction script is programmed to
> ignore opinion.ms, it doesn't give opinion.ms- the same treatment, so
> the "proprietary" boilerplate in that file triggered the clampdown.
That seems quite possible. I know I've accidentally triggered it with
#opinion.ms# (emacs autosave) files.
But that doesn't change the fact that the current tool is far too
draconian in nature. I spent countless hours hacking away at 'mail'
files that contained phrases such as "this isn't a Sun proprietary
feature" and ones that had accidental "confidential" notices in email
signature boilerplate. (Yes, those patently absurd notices are another
topic for another day.)
Heck, some of our own header files from /usr/include triggered the
mechanism because there were comments saying that a given ioctl was
"proprietary!"
That's frankly not a good use of anyone's time. It's almost as
pointless as removing shoes at airport security.
It does need to be improved. Two immediately useful improvements I
would suggest are:
- Treat messages in the 'mail' file as separate. There are great
mail handling tools in Perl and Python, so this shouldn't be too
hard. (Sadly, Solaris doesn't yet come with 'grepmail' -- it should
-- but it's easy to port.) Doing this would alleviate the DoS
problem; senders can only hurt themselves.
- Treat files as separate. If one has a stray confidential notice,
that shouldn't result in redaction of the entire case. It didn't
in the past, and it's not required now. (If you want to make an
argument based on file name stems, I think that'd be fine; i.e., if
"foo.ps" is bad, then "foo.plg" is also bad, at least if we don't
know how to scan it properly. Any compromise that gets us back to a
less troublesome regime would be good.)
More generally, the old scheme had a set of very specific strings that
had to be matched in order to mark a document as "confidential." I
think that was the right approach. The onus should be on those who want
to protect their information: they should be required to mark it
properly in all cases with unambiguous notices. Loose text matching
rules that match more broadly on suspicious phrases "just in case"
someone doesn't mark properly end up hurting _everybody_.
Let's not forget that we're talking about "open" cases here. Someone
has already put some thought into determining that the discussions
should be open, so closing off materials needs to be a last resort, not
a first one. Closed discussions can always happen on a @sun.com mailing
list or (better yet) by creating an intentionally "closed" case.
Also, as many inside Sun have asked, a tool that allows a diligent case
owner or engineer to scan an individual file and report problems is
highly desirable. It's just silly to be in a position where folks have
to edit some files, wait an hour to see how the web site changes, then
edit again, wait another hour, and so on. It just heaps inconvenience
on an already thankless task.
--
James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
