“Password Bank has found that Firefox was uninstalled from this computer. Please confirm following elevation request to remove orphan Password Bank support”.

After continuing this information the next step is to install strange program:
“Browser support installation for Password Bank UPEK Inc.

Please, tell me, what is it this nagging progra ready for installation?

George

About the window-of-exposure metric, it is worth understanding what do you suppose to get from that. (I provide a suggestion below.)

It is realistic to assume that some vulnerabilities will be, and have been, discovered outside of Firefox development team’s eyes. This is obvious when an exploit is found in the wild, before Firefox’s team is alerted, but also when they are not. You could use the information on when was the vulnerability introduced to the code and when did Firefox’s development team learn about it (i.e., the difference between the two dates), once a fare amount of these have been recorded you might be able to see a probability distribution (e.g., a Gauss bell). I suspect that this distribution will tell you a lot about when are these vulnerabilities discovered, might allow you to classify vulnerabilities by their difficulty of being spot, etc.

An application of this would be: assume that vulnerabilities take 12 weeks to be discovered in the average with a standard deviation of 1 week, assume that Firefox’s team discovered a vulnerability 8 weeks after introducing it, then you know that the patch should be developed fast (and taking 2 weeks to do that might be too much!)

Cheers.

http://www.owasp.org/index.php/Threat_Risk_Modeling

It’s also not clear to me that we are not trying to achieve very similar goals as those proposals. Did you guys consider adapting them?

You also have no chance of saying you were not able to publish it as .ods, since there is the free ODF plugin for MS Office (see http://www.sun.com/software/star/odf_plugin/index.jsp)

Shame on Mozilla for that!

I agree we may need to modify the 90% number. That was just a rough placeholder I think we’ll need to look at closely before finalizing on it.

In terms of how Mozilla measures updates, it’s tied to the auto update mechanism in the browser. The second half of this post provides a good overview of where the metric comes from:

http://john.jubjubs.net/2007/11/27/mozilla-firefox-market-share/

What do you think?

We’re hoping that the “security type” metric will take care of your first suggestion. Examples we’ll include there are remote code execution, privilege escalation, credential compromise, etc. Is that what you’re looking for?

As for comparing to other browsers, that’s not really the goal of the project. We’re more internally focused. I don’t thinks these kinds of models work well when applied externally, they need to be adopted by whoever makes the software.

Finally, the exploit question is a tough one. We looked hard at that and couldn’t find any accurate metrics, so we had to rely more on vulnerabilities.

Thanks for the feedback- did this address your questions? Still think we need an additional category or 2?

We also released the model as a set of csv files for people that don’t want to run Excel. The final version will be released in a bunch of different formats to meet the needs of different users.