Hello, Heikki.
Thank you for the clarifications you've provided about the Mozilla
security process. I realize it takes precious time to read the
traffic here and write detailed explanations, and I appreciate it.
> Now the way I see the way forward is: code. Or if you can't code,
> recruit coders to work on some promising anti-phishing feature.
I agree that code is necessary, but as I see it, it is not enough.
The existence of code should not be the only criterion.
It seems to me there are two different contexts for dealing with
security issues:
1. A security bug was just discovered. Should we keep it
secret or not? What should the press release say?
How can we fix this bug, and fix it fast?
2. We need to design a solution for a known problem. How
do we choose a good and effective solution?
Situation 1 is reactive. The urgency makes it high-profile and
exciting. Bugzilla and the disclosure process are tuned to deal
with this. When you need a bug fixed fast, the requirements are
clear and you can grab the first working patch offered.
Situation 2 is proactive. It's less thrilling because there is
no clear time pressure, but it is more important IMHO. This is
what I'm interested in.
> I'll leave you with one interesting research paper about Mozilla
> anti-phishing skin [...]
>
> See http://www.sims.berkeley.edu/~rachna/papers/securityskins.pdf
Yes, that's one proposal. But only one of at least five:
1. Netcraft Toolbar
2. Petnames
3. Security Skins
4. SpoofStick
5. TrustBar
All of these except DSS have implementations that could be deployed
immediately. (DSS requires the server side to speak SRP.)
None of them have been usability tested in a browsing situation.
I have my own opinions about these options. Ian has his own opinions,
and Gervase has his own opinions. We could argue endlessly about it,
but there comes a point where arguments are based on speculation and
the only way to know is to gather empirical evidence.
So, how does the team choose? Are there generally accepted criteria
that a proposal can satisfy in order to be accepted? Is it just a
matter of convincing the right two or three people? For example, if
one of these solutions showed favourable results in a usability study,
would that satisfy the right people?
I am grateful that you posted the link to the list of people on the
Mozilla Security Group. It's helpful to know those names. It's
just that there are over 60 people on that list, so I'd like to know
a little more about how consensus is reached on design decisions.
I can't imagine that all 60+ people magically agree when something
is proposed. As you probably have experienced, when it comes to
security, and probably even worse with usability, everyone thinks
they're an expert.
Thank you!
-- ?!ng
_______________________________________________
Mozilla-security mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-security
