Monthly Archives: January 2013

Norton Making Firefox Crash

Posted on by
13

My stepfather recently sent me an email:

Firefox keeps crashing and I keep receiving an apology and having to restore things. I switched off my computer and downloaded a new Firefox file but things are still the same.

I asked him for 10 crash signatures from about:crashes (sidenote: why does the “copy raw data to clipboard” button on about:support not also copy data about the last 10 crashes?) and found that the crash was in a DLL belonging to Norton Confidential. Symantec say they should have a fix by the end of the month. (Incidentally, Socorro is awesome.) Although I don’t know what their update uptake rate is.

There are loads of reports in SUMO about this. Scoobidiver says that this issue alone accounts for 8% of all Firefox 18 crashes. Every time this happens, I wonder how many people, who do not have Mozilla employees in their family to email, simply give up on Firefox because “it keeps crashing”, not knowing that a) it’s not our fault and b) there may be a fix coming in a few weeks?

Should we be even more aggressive in blocking crashy binary addons as soon as we see a crash-stats spike?

[Update: here’s his follow-up:

I have Norton 360 but if I disable it while on Firefox, does this leave me vulnerable? Would I be better using Internet Explorer and waiting for the system to be fixed?

Norton Confidential actually does password encryption (?) and phishing protection (which we already have), but people are scared to disable any of this stuff because the anti-virus companies have made them afraid.

Another comedy point: look at the titles of the top 4 Google hits for “Norton Confidential.]

Producing Open Source Software: 2nd Edition Kickstarter

Posted on by
1

Regular readers of this blog will know that over the last year I’ve been posting striking quotes from “Producing Open Source Software”, an excellent book written by Karl Fogel in 2005, published by O’Reilly, and available online.

I’ve just been informed by Devdatta that Karl is looking to update the book for a 2nd edition, which will also be available under a free license.

If you think this book contains as much wisdom as I do, head over to Kickstarter and chip in. He needs US$10,000, and currently has just under US$5,000.

Persona Login Now Fully Enabled On bugzilla.mozilla.org

Posted on by
4

[Update 2013-01-23 18:35 GMT – turns out there are a couple of Persona features we still need to be absolutely certain that this is a good thing. The change has been reverted until we’ve got those. Sorry for any confusion.]

In April last year, we enabled Persona logins on bugzilla.mozilla.org using a Bugzilla extension I wrote. However, we restricted this login method to low-privilege accounts only while Persona and the extension both matured.

I’m pleased to say that, as of now, unless you are a member of the administrative Bugzilla groups “admin”, “editusers” or “editgroups”, or the “legal” group, then you can now use Persona to log in to bugzilla.mozilla.org :-) In particular, this means all Mozilla employees and security group members can now log in this way.

Make sure you use the correct email address; if you pick a different one to your usual one, Bugzilla will auto-create a Bugzilla account for it.

If for some reason you want b.m.o. not to accept Persona logins for your account, you can do so; file a bug to have your account manually added back to the “no-browser-id” group.

To The Archives, Batman!

Posted on by
Reply

Typically, all communications in an open source project (except sometimes IRC conversations) are archived. The archives are public and searchable, and have referential stability: that is, once a given piece of information is recorded at a particular address, it stays at that address forever.

Use those archives as much as possible, and as conspicuously as possible. Even when you know the answer to some question off the top of your head, if you think there’s a reference in the archives that contains the answer, spend the time to dig it up and present it. Every time you do that in a publicly visible way, some people learn for the first time that the archives are there, and that searching in them can produce answers. Also, by referring to the archives instead of rewriting the advice, you reinforce the social norm against duplicating information. Why have the same answer in two different places?

— Karl Fogel, Producing Open Source Software

Mozilla and Non-Copyleft Licensing

Posted on by
4

[tl;dr: starting a discussion in mozilla.legal about the appropriate role of non-copyleft licenses with respect to Mozilla-originated projects.]

For a long time now, the Mozilla License Policy has said, paraphrasing, that new codebases written by Mozilla should use the MPL. (When we contribute to projects created by others, we have a policy of using the licence which that project uses.)

Reality does not entirely agree. Over the last few years, some new codebases have been created under various non-copyleft licences, such the BSD licence and Apache License 2.0. Examples include many of our websites, shumway, and Gaia.

The MPL was created as an intermediate stage between the copyleft of the GPL and the non-copyleft of licences like the BSD license. It has served us well in that role for many years.

It has been argued that copyleft, such as that in the MPL, is not particularly useful in the case of websites, because the MPL contains no source distribution requirement for network apps. The question of adding such a requirement was specifically excluded from the scope of the MPL 2 discussions. However, as we move more towards mobile “web apps”, where significant amounts of the code do live on end-user devices, copyleft has become more relevant again.

Copyleft is a tool which we use to achieve particular ends. The leadership of some Mozilla projects, such as Gaia and AMO, have decided that it is not the best route to success, as they define it, for their projects.

So, the first question is: if use of non-copyleft licenses has become a practice, is it a good practice? We should revisit why Mozilla chose copyleft of “MPL strength” in the first place and whether those reasons still apply today, and if so, in what context.

Secondly, if we decide that there is a reasonable and valid demand in the Mozilla community to allow projects to choose non-copyleft licensing, which licence(s) should we permit? Should we just allow people to choose any open source licence? Or any popular one? Or should we be more prescriptive?

One excellent feature of the MPL is that it offers a level of patent protection to contributors. Patents are rapidly becoming even more of a factor in software development, and anything we can do to protect our software ecosystems from the damage caused by patent lawsuits is worth it. This particularly applies to communities where large numbers of competing companies may be taking part – such as B2G. The licensing team is strongly of the opinion that patent protection is an essential part of a modern open source licence.

The equivalent non-copyleft licence to the MPL, in this regard, is the Apache License 2.0. It, like the BSD and MIT licences, is upwardly-compatible with the new MPL 2, but unlike those two licences features a patent protection clause to give companies contributing to a shared Apache 2.0 codebase confidence that other contributors will not turn around and sue them.

My proposal therefore is this:

  1. We should attempt (although this may be difficult) to reach consensus on what sort of projects are best served by what sort of licences, and what scope of copyleft.
  2. We should update the licence policy to permit, via consultation with the licensing team, use of either the Apache License 2.0 or the MPL 2.0 for projects. The exact decision process here would depend on the outcome of 0).
  3. We should clearly and by name forbid the use of other licences for Mozilla-originated codebases, without specific permission and in exceptional circumstances.
  4. We should talk to existing Mozilla projects which are using BSD and MIT and see if there are particular reasons for not using the Apache License. If there isn’t, we should transition; if there is, we should evaluate those reasons against our licensing goals.

Join the discussion in mozilla.legal.

Defeating the Peter Principle

Posted on by
3

A Freakonomics blog post which covered the Peter Principle (see Question 3) got me thinking. The Peter Principle is explained as follows:

Dr. Peter is one of our favorites. His book The Peter Principle: Why Things Always Go Wrong came out in 1969. He first expressed the principle that bears his name like this: “In a hierarchy, each employee tends to rise to his level of incompetence.” Once an employee reaches his level of incompetence, his superiors will recommend no further promotion, leading to “Peter’s Corollary”: “Every post tends to be occupied by an employee incompetent to execute its duties.”

How do you defeat the Peter Principle in your organization? How about this: as a condition of promotion, any employee agrees that they may decide to (or be asked to) return to their previous job, but keep the pay and benefits package from the higher-level job.

The idea here is to remove the financial disincentive for the employee to admit they aren’t doing well and say “OK, fair enough, this job isn’t for me; let me go back to what I’m good at”. If they are ever promoted again, their original salary or salary scale is used to determine their new pay, so they can’t yoyo up and down, collecting a compensation bump each time. One may want to impose a minimum term in the new job, and/or require management permission and agreement for the step-down. This would mean some lower-level employees cost the company more than others, but it might well be a whole lot cheaper than having the wrong person doing the wrong management job, badly. It could perhaps be seen as the price management agrees to pay for promoting the wrong person in the first place.

What Is ‘Sexism’?

Posted on by
27

A remarkable entry from Merriam Webster’s dictionary (which I found linked from the Wikipedia article):

sex·ism noun \ˈsek-ˌsi-zəm\

1 : prejudice or discrimination based on sex; especially : discrimination against women

2 : behavior, conditions, or attitudes that foster stereotypes of social roles based on sex

The first definition has been in use for a long time, and is (I would suggest) widely recognized. But note the second one. According to Merriam Webster, any expressed positive view whatsoever, however limited, of any historically-recognised (a.k.a. ‘stereotypical’) gender-based social roles is, by definition, sexist.

Have I understood that correctly?

3D Printer: First Useful Objects

Posted on by
3

In the past month, I’ve printed the first useful objects on my printer (the initial Android, while pretty, is not useful). The first was, and I know this is probably playing to 3D printing community stereotype, a calibration jig for someone else’s 3D printer (a Makerbot Replicator). In other words, I’m printing more 3D printer parts:

The second, though, solved an actual problem in our house. Our lovely son William, now 11 months, has worked out how to open cupboards. We have some Ikea Billy bookcases with cupboard doors on, and wanted to stop him getting in them. The knobs are simple wooden cylinders, so the rubber-band-based solution we used for the TV cabinet wouldn’t work. However, a small bit of work with OpenSCAD and a quick print later:

And this is what it looks like in-place, keeping the doors shut:

Actually, the photos are of the second one I printed. The first did the job but the layers didn’t stick together very well in some places, so it was a bit brittle. I’m still having trouble with bed adhesion and warping, but I’m working on that…

TurkTrust Incident

Posted on by
1

As the Mozilla security blog post outlines, we recently explicitly dis-trusted two mis-issued intermediate certificates from a CA called TurkTrust. We have also suspended the addition of a replacement root of theirs to our root store while we consider our options.

The advisories for other CAs are linked from the Opera advisory. Two browsers have revoked the EV status from TurkTrust’s root. It is worth noting in this connection that the two roots which are currently in Mozilla’s root store are not EV-enabled. The replacement root was due to be (bug 788321), but was not at the time that its inclusion was suspended.

For those interested in the technical details of what happened, TurkTrust have posted two messages on the CAB Forum public mailing list which set out the story from their point of view, and also give some pieces of their root cause analysis.

Their explanation is, in short, that there was a technical mix-up of certificate profiles between a test and a production system. Two “intermediate cert” profiles added only to the test system were mistakenly added to the production system under identifiers which were already allocated for other profiles – and so were used to issue two certificates. When the profile mismatch was found and corrected, that “solved” the problem, and no further certs were mis-issued. This happened 18 months ago, and only came to light when (it seems) the organization which was given one of these mis-issued certificates decided to use it for MITM in their corporate firewall.

Cut Off From My Own Creations

Posted on by
6

In 2005 and 2006, I wrote a fortnightly series of online-only columns for The Times newspaper. I attempted to get them to agree to a free content license for the text, but I was unsuccessful. At that time, there were far fewer precedents for that sort of thing, and I didn’t have nearly enough clout to persuade them to make an exception for me.

Still, I decided that the experience was probably worth it, and the money was useful. (Although my cousin, who is in the publishing industry, told me later that they paid me significantly under the going rate; and they also paid on 45-day terms, which I think is pretty shoddy behaviour.) I wrote a couple of pieces with which I was really quite pleased. And I was happy that, even if I didn’t have full rights, everyone could read them. I eventually stopped submitting work when my editor stopped replying to my emails.

Recently, revising my website, I came across the page where I linked to them all – but they are no longer available to read on the public web. They are behind the Times’ paywall. And, although I do have copies of the text I submitted, because I don’t own the rights, I can’t put up mirrors. So, I can no longer share my creative work with people who might want to read it.

Lesson learned: only release your creative work under free content licenses.