Towards Mozilla 1.0
Tuesday June 26th, 2001
Gervase Markham recently posted his feelings on what a 1.0 release of Mozilla would be. Gerv has sent us the follow-up to that posting, including much of the feedback he received. To read it, click the full article link. Once you have read through it, we welcome you to post your feelings on what you think a 1.0 release would have. [As Gerv says, please don't post your favorite list of bugs, only the criteria for choosing what bugs to fix.]
#233 Re: Security issues in Mozilla
Monday July 2nd, 2001 1:52 PM
You are replying to this message
I think I was clear enough, first in asking the question "Is there a paper on the security implications of XUL?" (not for the first time here), and then in stating that I was unsure how to interpret the documents that I found for myself when no one answered: "it may be discussing things in a way that makes them look like they're for the future, when in fact they're already implemented."
The reason I was unsure how to interpret the policy document is that it uses tentative phrases like "I am proposing" and "Mozilla should," which makes it unclear whether this is someone's own ideas or actual policy. This ambiguity is why RFCs are careful in using terms like "MUST" and "SHOULD."
Since then, I've looked in Bugzilla and I see that there are definitely ongoing efforts in the areas of preventing spoofing and firewalling dangerous APIs. I can't tell how complete they are, but clearly some work has been done, which confirms my original observation, "I'm sure this has been looked at, so I'm just asking where I can follow up on the issue. Thanks."
I am still quite confused as to the state of the policy document at <http://www.mozilla.org/pr…ty/components/design.html> , which proposes restrictions such as "No web-based XUL" and "no downloadable chrome". I've found Bugzilla bugs from this year which relate to both of these features, which according to the policy document are supposed to be forbidden. Are they forbidden or allowed? Is the document policy or suggestion?
It also appears from my Bugzilla search that Netscape 6.x and Mozilla 0.9.x versions have gone out with significant security holes, which I speculated might be the case. It's all very well to patch these, but in practice the end user installed base is likely to adopt such patches at a very slow rate after the first stable release. The fact that they are made public in Bugzilla means that Bugzilla is a source of useful information to people looking for holes in recent browser versions. Advocates of open source have claimed that open source makes for better security. That may be true in some ways, but this shows one way in which open information charing can actually harm security. To document security bugs in currently-used browser versions is to facilitate exploits.
It might make sense to change the current policy -- making security bugs public after they are fixed -- to incorporate a time-out linked to the observed upgrade cycle, so that only security bugs in now-largely-disused versions are made public.