Well, I should say here that some of the arguments presented on Slashdot
are in fact not bogus at all, and deserve a serious response. I'll try
to give my personal response to those arguments below, and illustrate
what I think the real debatable issues are and what possible approaches
we have to addressing them. (I apologize in advance for the length of
this as well as meandering somewhat in the course of making my points.)

First, to clear away some of the misconceptions that found their way
onto Slashdot:

To my mind the true debate here is not about whether AOL/Netscape should
keep Mozilla-related security bugs to itself. Mozilla is an open source
project, and Bugzilla is a resource for that project as a whole, not
just for AOL/Netscape. If the Bugzilla database is going to contain
information that is not available to everyone in the Mozilla project
then the justifications for imposing such restrictions have to be pretty
compelling.

Security-related bugs are a case where I believe you can't justify
restricting Mozilla bug information to a single vendor (whether
AOL/Netscape or whoever). For example, another company basing their own
products on Mozilla has just as much claim as AOL/Netscape to have
access to Mozilla security bug information in order to protect and
provide for their own customers. A similar argument would apply in the
case of developers creating their own version of Mozilla for
distribution -- for example, if the MathML developers were to create and
distribute a custom version of Mozilla to the mathematical community.

So I don't think the real argument is about restricting access to
security bugs only to AOL/Netscape. I think the debate is rather about
a) whether security bugs in Bugzilla should be fully public or
restricted to some smaller group; and b) if restricted to a smaller
group, how that group should be chosen. (Or to put it another and I
think a better way, how could any particular individual get themselves
admitted to that smaller group?)

I also think some people are misinterpreting Bruce Schneier's remarks at

http://www.counterpane.com/crypto-gram-0002.html#PublicizingVulnerabi...

as being in favor of full disclosure under any circumstances. Schneier
writes "In general, I am in favor of the full-disclosure movement", but
then later goes on to write "I believe in giving the vendor advance
notice" to allow them some reasonable amount of time to fix the problem.
(Schneier's idea of "reasonable" appears to be more than a week but at
most a month.) So IMO Schneier can't be represented as advocating for an
absolute requirement that vendors fully and publicly disclose security
bugs as soon as they receive reports of them; otherwise what would be
the point of giving the vendor advance notice?

Schneier is in effect saying that the vendor of the software is in a
special position relative to anyone else, and is justified to some
degree in concealing information about security-related bugs until they
can be fixed. It's not a justification that allows concealing security
bugs forever, but it does allow concealing them for some reasonable
period.

Now, the problem with applying Schneier's argument in this case (and
here we're getting into what I think are the real issues) is that in the
Mozilla project we're not dealing with proprietary software supplied by
an single identifiable vendor; we're talking about an open source
project where in effect anyone and everyone can potentially be a Mozilla
"vendor": In the proprietary world vendors are special because a) only
they can fix bugs and b) only they are (ultimately) responsible for
supporting users of their software. In the open source world anyone can
potentially fix bugs, and anyone can distribute versions of the software
to end users. So either there is no "vendor" in Schneier's sense, or
anyone can be a "vendor"; in either case it's hard to see how Schneier's
ideas of "giving the vendor advance notice" would apply.

The discussion in the previous paragraph leads directly to two different
arguments for full disclosure of security bugs, arguments that IMO are
reasonable and deserve to be addressed.

The first argument goes somewhat like the following: given that a)
anyone can (potentially) fix security bugs in an open source project
like Mozilla, and b) we collectively have an obligation to maximize the
chances that security bugs will be fixed, therefore we have an
obligation to immediately and fully disclose information on security
bugs to as many people as possible, because only in that way can we
maximize the probability that the problems will be fixed.

I don't accept that particular argument in the general case, because it
doesn't take into account the fact that with security bugs there are
real risks and that disclosing details of bugs can potentially increase
that risks. These risks go beyond just not having the software work, or
even suffering from simple denial of service attacks, for example by
malicious people putting up web sites that are designed to crash
Mozilla; with major security bugs you have a risk that users' personal
data will be compromised and altered, and that their systems are
subverted for malicious purposes (e.g., through trojans).

If you expose details of such security bugs to more people you increase
the probability that they will be fixed but you also increase the
probability that they will be exploited by people previously unaware of
the bugs. (And here I should say that I don't accept as a general truth
the statement that everyone who can and will exploit a bug already knows
about it by the time it's reported to the developers.) IMO those risks
(of the bugs being exploited vs. not being fixed) need to be balanced; I
can't say exactly what the balance point is, but I believe it's
reasonable to assume that there's some point in disclosure (below
disclosing to everyone) beyond which you could significantly increase
the risk of exploitation without significantly increasing the chance
that the bug will be fixed.

Of course, we don't know what that point is exactly. We can't say for
certain, for example, that there is a group of exactly 10, or 20, or 100
Mozilla developers that is the optimum audience for Mozilla security bug
information, because no one else outside that group is likely to fix
those bugs. But IMO we still have an obligation to maximise the chances
that bugs will be fixed. So if we accept the idea of limiting access to
security bug information, then IMO we also have an obligation to a)
ensure that people who have the ability to fix Mozilla security bugs are
able to join the group without undue hassle and b) put some sort of
reasonable time limit on how long security bug information is not
publicly disclosed. These two policies help ensure that the initial
group includes the people most likely able to fix the bug, and that the
bug will likely be fixed in any event even if the initial group is
unable to do so.

The second argument for full disclosure goes as follows: There are
sysadmins and other people who are responsible for a user community that
would be using Mozilla, and who have the means, the knowledge, and the
motivation to help fix Mozilla security problems. Don't they have a
reasonable claim to be able to view information on reported Mozilla
security problems, arising from the responsibility that they owe to
their users, and that we owe to them as representatives of those users?

I think the answer has to be, yes, they do have some claim to view those
security bug reports. If you accept that argument, then one can go on to
make the subsequent argument that since anyone in the world could
potentially be in the position of having some reasonable claim on seeing
Mozilla security bug reports, then the only justifiable policy is to
make the bug reports fully public as soon as they are received into
Bugzilla.

Again, I don't believe that this argument for full disclosure is fully
convincing. I believe the population of sysadmins supporting Mozilla,
distributors of Mozilla-based products, and other people responsible for
Mozilla users is a proper subset of the total Mozilla user population,
and you can make a case for limiting information on security bugs to
that subset. Of course, as with the case of people who can fix security
bugs, we have no foolproof way of determining exactly who should be in
that group or not. Since we still IMO have an obligation to sysadmins,
Mozilla distributors, etc., we should take the same approach as we
should for developers: provide some reasonable way for motivated people
to become part of the "inner" group allowed to see security bug reports,
and set some reasonable time limits on how long information is
restricted to the group.

A final argument for less than full disclosure of security bug reports
is that given by Dan Veditz: that mandating full and immediate
disclosure for security bug reports placed into Bugzilla is likely to
encourage Mozilla vendors (including AOL/Netscape, but also potentially
others) to bypass the Bugzilla mechanisms in handling security-related
bugs and to handle that information internally and not make it available
to other interested parties in the Mozilla project.

I believe that it's in everyone's interest that Bugzilla be used as a
common repository for bug information by all parties involved with
Mozilla development. I also believe that when deciding on a policy you
have to consider the likely consequences of adopting it. Even though
mandating absolute full disclosure of security bugs can be justified by
arguments I myself can potentially accept (e.g., by the arguments I've
given above), I believe that the consequences of trying to force full
disclosure are in practice likely to lead to a situation where in
practice we end up with less disclosure rather than more.

Therefore I'm willing to make the compromise of limiting full disclosure
of security bugs in some way, as long as we follow the general
guidelines I've mentioned above:

* Information on security bugs is not limited to any particular vendor.

* There is some reasonable way for people to apply and be approved for
access to the information on the same basis as the others already "in
the know".

* There is some mechanism to make full public disclosure of the
information after a reasonable amount of time.

I'll leave it to others to make more detailed proposals on how this
might be accomplished.

Frank
--
Frank Hecker            work: http://www.collab.net/
fr...@collab.net        home: http://www.hecker.org/