On Saturday 28 May 2005 02:17, Ka-Ping Yee wrote: > On Fri, 27 May 2005, Ian G wrote: > > And, both petname and trustbar were roundly rejected > > by the Mozilla security community. > > Is there a foundation for this statement? I would really > like to learn what constitutes the Mozilla security community > and what constitutes the authority to speak for it.
I know what you are asking here, and when I first came across this question myself, it took me a while to get to grips with it. I now have a little chart of all the security project wannabes I know of (14), with points marked for all the differentiators that I've come across (17, and I just now thought of another couple so 19 but one I should remove so make that 18). Maybe one day it will grow up and become a paper on "what makes for a security project." But that's another story. For Mozilla this is the big strategic question. This is what I've observed so far: 1. There is no overarching or cross-team security process. Security as a directorate in the whole - as it exists in security projects like the BSDs and in the terms that you or I would look for - does not exist. There is no identifiable or organised security community other than these two mailgroups (crypto and security) which are essentially talking shops and the "security team" mentioned below. 2. What fills the gap of security process is the models. These are implemented as is. By this I mean the oft-heard retort of "that's not in the standard" as an answer to a security question with the expectation that this is a sufficient answer to a security question. 3. The application teams themselves make the security decisions on how to implement models. The obvious problem here is that the application teams have little experience in wider security practice and simply adopt the models presented by "standards" regardless of needs and security of the users. This is most clearly seen in technical terms with the S/MIME project (where implementation of the model leads to bemusingly few results), and in political terms with the HTTPS secure browsing / phishing debate (where implementation of the model clashes with the evident security breach). 4. Security decisions are taken in secret. The "security team" is a basically an approve-only group, so it is essentially a closed shop and the squeaky wheel of non-model security isn't welcome. [ In one of Frank's earlier lives, he wrote the policy that explicates the closed and secret security process. Basically he documented what was politically possible, he wasn't the one pushing that as his own preferences. ] The problem with secrecy and closed shops is that actions then are indistinguishable from no actions, difficult choices are indistinguishable from no choices, and if there are any other problems then that process can fail very easily. In fact, the most likely result of a secret process is a failure as there is no feedback to point out the problems that all processes have. C.f., Shmoo, where the security team didn't make the decision. 5. The security team concentrates on bug fixing, code audits, patches and the like. In my time on these lists, I've never heard a reference to the security team in any active sense, and it was a year before I'd even realised there might be another group. In all probability, they are sitting there doing good work and believing that what happens on the security mail groups is irrelevant so are keeping the thing quiet. (Now, this is not meant to be a criticism. Someone's got to fix the bugs, Lord knows I wish I had some team to fix my security bugs. But, to say that this team fulfills the wider/higher needs of security beyond bug fixing is a stretch.) 6. One big important part is the bugzilla system. That is a good focussing tool for bug-level issues. But it also acts as a control system, it is impenetrable to outsiders, and it does not admit wider issues. So it works well at the tactical bug level but is actually a negative force at the strategic issues level. So my conclusion is that Mozilla is not a security project, not in terms that you or I would understand. This itself wouldn't be so unfortunate as there are plenty of places in the world for non-security projects, and nobody ever said that browsers had to be security projects. But Mozilla itself presents its browser as the secure alternate and users have been trained to perceive of the browser as protecting them. That's not in accord with reality. Mozilla is just the new kid on the block as far as other browsers are concerned, and the users are starting to get the idea that the browser is not protecting them. So there is a realignment of expectations due here. In terms of security as we know it, the issue is that Mozilla is a "models" project and the models are sacrosanct (this is the same with all browser projects). Until the clash between the models and security is addressed, Mozilla cannot be a security project, IMO. iang PS1: Foundation is by my observation only, and as confirmed by comments. Obviously people who don't like this will find plenty of nitpicking here - but the big picture is essentially there. Nitpick all you want, but if you really want to make a contribution, think of the bigger picture. PS2: One indicator of this was the Shmoo situation. Now, in my book a decision is 9 points out of 10, and a decision did come out regarding the Shmoo situation. So on the whole Shmoo was 9 points out of 10. At the time I kept my big mouth (mostly) shut and observed, as I recognised immediately that this was a wonderful opportunity to see how security apparatus responded to a real apparent threat. Three things were evident that support this post on wider security: 1) it took a long time and during that period there was silence, 2) the decision taken was very simplistic, maybe knee-jerk, and 3) the decision was taken by the "staff" group and not by anyone with "security" in their name. PS3: If you look at the occasional security pronouncements in the press by spokespeople for Mozilla then you can see that they are basically reactive, with no substance. It's not their fault, there's nobody there to advise them on what matters and where to go and what to say. They basically see themselves as locked in a battle of words with Microsoft over security blah blah. What they don't realise is that they are fighting on Microsoft's ground, and that means they lose eventually. PS4: There is a hope that someone like Frank who has the strategic experience can start to build that team. But there is only one Frank, and as he is busy on the CA policy project he's already committed. In this sense, the CA policy project is proving to be very expensive, and holding it up is the worst thing that could be done. If I was Microsoft, I'd pick and poke at the CA policy project because of the damage it does in holding it up from other more important things like security. -- Advances in Financial Cryptography: https://www.financialcryptography.com/mt/archives/000458.html _______________________________________________ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
