Alan Burlison wrote:
> James Carlson wrote:
>
>> 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.
>
> A lot of the cases had been published when they shouldn't have been.
> That's not a sufficient justification for continuing to do so.
I don't know of any cases that were accidentally published as open, but
if there are such cases, they are the responsibility of the person who
managed the case materials. Not your problem or the community's
problem, but the person with access to the case who mis-managed it.
Nor do I know of any instances where an ARC case was marked "open," but
it was actually confidential, and the old mechanism leaked documents
that were not marked properly, but the current mechanism redacts them
safely. In fact, when I was at Sun and reviewing the redacted cases,
the only thing I found were cases that were erroneously redacted by an
overzealous filtering mechanism. Thus, I claim that it's not an
improvement.
And that's all we see today as well, which is why I compared it to
removing shoes at the airport. It's onerous, and doesn't seem to
address any practical threat.
Note that both the old and new system default to "closed" for old cases,
so those old ones that were never evaluated for openness were never
shipped by either one.
>> 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.
>
> It clearly bears restating that the old tool had got to the point whre
> it was in effect mounting a continual DOS on opensolaris.org, both from
> the traffic it generated and the volume of content it had uploaded to
> the current portal. The choices were either to permanently remove all
> ARC material altogether, or to quickly put together something that
> provided access, and we took the second option in the interests of
> keeping the information as available as we could. That in no way
> translates into a commitment to manage, maintain or enhance the ARC
> infrastructure.
It bears repeating that at no point did I dispute that.
It'd be great if the ARC could find someone to address the issues that
are present, but the current lack of support (on both sides of this
apparent divide) doesn't in any way make those issues less problematic,
nor does it make the problems less important or appropriate to discuss
-- even if nobody has the manpower to solve it.
> In addition, most of the problems need fixing upstream of the external
> publishing step - for example if a mail to a case log looks like it
> contains confidential information it should be rejected and not be added
> to the case log in the first place. Similarly the ARC management tools
> should do the checking an classification processing needed to
> distinguish between closed and open cases. Trying to intuit the status
> of a case based purely on processing the case materials after the fact
> is *always* going to be less than satisfactory.
That's not quite the issue. Each case has a marking on it to determine
whether it should be open, closed, or manually administered. That
happens before-the-fact, and produces a presumptive behavior for the
documents. It requires specific Sun employee intervention. When open
documents are removed from the site by mis-firing filters, that
mechanism is not being respected.
Actually, these particular issues were discussed at length in the ARC.
Confer with John Plocher and the current SAC leadership if you need more
details.
In short, we (the ARC) decided that:
- Users who handle confidential material need to know what they are
doing. We can't fix that problem for them. Someone who is careless
can just as easily send confidential bits to opensolaris-discuss as
he can send it to arc-discuss or any other list, so making a special
filtering mechanism just for the ARC seems to be out of scope.
- There would be rules in place for how cases are handled. Open cases
have email sent to psarc-ext at sun.com. Closed ones have it sent to
psarc at sun.com. The existing ITops infrastructure supports these
having different behaviors. Users (again) are burdened with
understanding the difference and respecting it.
We considered and specifically rejected having filters that cause
automatic bounces of "bad" messages. The specific reason for this was
that the ARC has a complicated balance to strike. On the one hand, it
does (on fairly rare occasions) need to handle some sensitive material,
and does need to be careful with it. On the other, it has a *PRIMARY*
responsibility to encourage and promote the free flow of information
among all with an interest in engineering. That free flow of
information is core to the ARC's mission; it cannot function without it.
Having legitimate email messages bounce for spurious reasons (as you
correctly note is inevitable with any automated system) would undermine
that mission. Thus, we made the conscious decision to err on the side
of openness and ease-of-use when not sure which way to go, and put the
burden where it belongs: on those few who handle confidential data.
If those rules are somehow deficient (and they may be), then I think
Sun's lawyers should take that up with the ARC and with SAC (or SAC's
leadership should start the discussion) so that the right processes and
procedures can be put in place within the context of the ARC's job. It
should not be imposed on the ARC by another group's reinterpretation of
the rules -- no matter how well-intentioned or generous that other group
may be, nor what other problems or exigent crises they may be tasked
with solving
> In addition, we are responsible for ensuring that any information
> published on opensolaris.org meets any restrictions that are placed on
> us. If confidential information appears on the site when it shouldn't
> is is this team that bears the responsibility, not members of the wider
> community. Whilst we'll try our best to be accommodating (e.g. my
> suggestion of how we might improve the handling of the opinion.ms
> files), we don't have free reign in this matter.
I don't see how that's really the case.
If someone -- inside or outside of Sun -- sends a confidential document
to any of the public mailing lists, or simply sends it to a non-Sun
email address, it's gone. There are (as best I can tell) no magic
confidential data filters on these lists or on general email. The
equivalent of the current redaction mechanism would be to shut down an
OpenSolaris Project if a verboten word or phrase were uttered, but I
don't see that happening. Instead, we have special rules that apply to
the ARC alone.
If someone puts a confidential document up on opensolaris.org or on a
wiki, again, there's no filtering that goes on. It would have to be
removed after-the-fact when someone notices or complains. But we have a
different and preemptive mechanism for the ARC: documents that are
mis-categorized there not only cause removal of that document, but
everything in the same neighborhood, no matter how long that other
material had been there, and no matter who does it. It's trivially
DoS-able by remote people who want to remove ARC cases. I can take down
all of the ARC's documents remotely with a simple Perl script.
As for the legal issue of liability, I'm not sure that this is the right
place to discuss something like that. I'd assume that at least the
person doing the posting bears some responsibility -- when I worked at
Sun, I seem to recall agreeing that my use of Sun's publicly-accessible
sites put the burden on me to be careful -- as might Sun in general.
However, having the legal issues for one group managed on behalf of
another seems quite sub-optimal, and likely results in decisions that do
not make sense when put into the right context.
--
James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
