I happened to stumble upon a blog post by Jennifer Rice on “Love/Hate brand scores". She did a thoroughly unscientific comparison of common brands based on querying Google for “I love Foo” and “I hate Foo” (similar to Googlefight, but taking the idea a bit further). I’ve recomputed her results and included some brands and products of interest to us. Here’s the original Love/Hate brand score table, with all figures recomputed based on new searches (partly so I can understand exactly how she computed her results, and partly to get a consistent baseline for adding Firefox et.al. ); I’ve left the brands in the same order as in Rice’s table for ease of comparison. ...

I’ve posted a new draft 10 of the proposed Mozilla CA certificate policy. The only substantive changes are as follows: I changed the language on disclosure of financial compensation (i.e., of independent evaluators by CAs) to read “publicly disclose” as opposed to “fully and publicly disclose”; in other words, I dropped the word “fully.” I added a section discussing revision of the policy, and noting that such revision would be done only after public discussions (similar to what we’re doing now). ...

In the course of our discussing the proposed Mozilla CA certificate policy, Ian Grigg happened to ask about the existing Mozilla policy on handling security bugs and how we tried to forge a compromise between people advocating full disclosure of security bugs and people who were opposed to that. (Ian was interested in this because he and Adam Shostack have been blogging on the “economics of disclosure.”) I happened to look back at the Google archives of the discussions we had, and found some material that I thought was worth revising, reprinting, and commenting upon, especially for people who are not aware of how the current Mozilla policy came to be. ...

I’ve created a new draft 9 of the proposed Mozilla CA certificate policy. The main substantive changes are as follows: I extended the policy’s requirements to cover all CAs, not just new CAs. This puts existing CAs on notice that in the future we can (and I hope will) go back through the list of CA certificates already included in Mozilla-related products and decide whether or not particular CA certificates should continue to be included. ...

I’ve created a new draft 8 of the proposed Mozilla CA certificate policy. The main substantive changes are as follows: I changed references to “users” to clarify that we’re referring to users of the products distributed by the Mozilla Foundation through mozilla.org. I added a requirement for CA disclosure of business practices in the form of a Certification Practice Statement. Besides being a good idea in general, it’s typically the CPS that is referenced in auditor/evaluator reports, so it’s needed to provide a more complete picture of the CA’s conformance to whatever criteria are used to evaluate its operations. (For examples of Certification Practice Statements see my draft Mozilla CA certificate list.) ...

I’ve published a new draft of the proposed Mozilla CA certificate policy. For information on changes from the previous draft please see my posting in the netscape.public.mozilla.crypto newsgroup (aka the mozilla-crypto mailing list). (Note that I have not yet completed writing the accompanying FAQ, but will try to do so in the coming weeks.) This new draft is intended to replace the simple “WebTrust or equivalent” policy that I’ve been using recently when deciding whether or not to approve CAs for inclusion in Mozilla-related software. (This interim policy was based on Microsoft’s policy.) ...

A while ago someone wrote to mozilla.org staff asking “What is the ECCN for Mozilla?” For that small fraction of the world’s population who knows what an ECCN is (an “Export Control Classification Number” for U.S. encryption export control regulations) and cares about what Mozilla’s ECCN happens to be, here’s the answer I gave. Note that this is not an “official” answer, but it’s the closest thing to it you’re likely to get. ...

UPDATE 2023-03-27: This page is obsolete, as it refers to a prior version of this blog. However, it may be of historical interest. I use the seemore plugin by Todd Larason to show only excerpts of entries on my main blog page, index pages for categories, and archive pages, while displaying the entire article on an individual entry’s page. It’s worked well, with one exception: When I created my RSS and Atom feeds I wanted the feeds to contain the full text of all entries, for the convenience of people using news readers. (Many of these applications display article text directly in the reader, removing the need to open a browser window to read the article.) ...

UPDATE 2023-03-27: This page is obsolete, as it refers to a prior version of this blog. However, it may be of historical interest. I’ve been using the entries_cache_meta plugin by Jason Thaxter, mainly for the convenience of specifying the modification date within the entry file. After a while I decided I’d like to also use its “meta” capability, i.e., the ability to specify arbitrary variables in the entry header along with the modification time, e.g., ...

UPDATE 2023-03-27: This page is obsolete, as it refers to a prior version of this blog. However, it may be of historical interest. I’ve previously blogged about my canonicaluri plugin that checks to see whether the requested URI is in the canonical form for the type of page being requested, and if necessary does a browser redirect to the canonical form of the URI. However the canonicaluri plugin may be overkill for some people, for example, it presumes use of the extensionless plugin, so that canonical URIs for individual entries do not have file extensions for the default flavour. A simpler alternative to the canonicaluri plugin is the slashredir plugin, which only enforces proper usage regarding trailing slashes. ...