Establishing Trust Online

No, this post is not about certificates :-))

We want to make Mozilla as open a project as possible, which means that ideally there would be no parts of what we do which were closed to input from particular sections of the community. Question: how does Mozilla acquire sufficient trust in a potential community member that we could let them work in sensitive areas? Sensitive areas might include ones where they were working with confidential data belonging to users or employees, or working with partners under NDA, either temporary or permanent. We would not want someone untrustworthy in such a position.

Here is a (probably incomplete) list of ways to establish trust between a truster and a trust-ee:

  • A) Recommendation from 3rd party already trusted by truster
  • B) Trust-ee putting something at risk (deposit)
  • C) Legal contract with penalties
  • D) Demonstration of bona fides (e.g. by being faithful in small things)
  • E) Gut instinct
  • F) Trust-ee revealing verified identity information
  • G) Default to trust; remove trust if trust broken

When Mozilla employs someone, we have sufficient trust in them because of B) (their job is the thing at risk if they violate trust), C), F) and perhaps a little of A). How do we go about establishing similar trust with someone we don’t employ?

Here are some comments on each:

  • A) doesn’t scale well to a globally-distributed organization, where we regularly get new people who know no Mozillians in real life.
  • B) This is a difficult thing to ask of new community members. What options are there? Money? Something else?
  • C) IT went for this one, but it might be too heavyweight for some. (Of course, it might be required by law in some cases.)
  • D) This is how things work normally; we are looking for a way to speed this process up.
  • E) This works right up until it doesn’t…
  • F) We could investigate this; obtaining such identity proof might involve a time and/or money cost for the contributor.
  • G) Possible in some circumstances, but not the difficult ones. Perhaps involves an overly-rosy view of human nature.

Thoughts and further comments?


Outstanding Requests in Bugzilla

Many Mozilla project members will wake up this morning to find an email entitled “[Bugzilla] Your Outstanding Requests” in their inbox. This is a reminder of all requests (for e.g. review, feedback, or super-review) which have been outstanding more than 7 days, and from now on will be sent out every week.

This is part of an effort to clear the request backlog (by either cancelling, fulfilling or transferring the requests) and set up a community norm that contributors should not have to wait more than two weeks for a request to be dealt with. (Two weeks is our initial community-wide target, and we hope that people or their managers may set more ambitious personal targets.) We hope that this will lead to fewer instances of new contributors becoming discouraged by being ignored, and if we can get the backlog cleared and then monitor the statistics to make sure the problem does not recur, it will generally oil the wheels of the project.

So please do your best to deal with the requests on your list. It is important to emphasize that this does not necessarily mean doing e.g. a review – it may mean cancelling it (with an apology) because the patch is unwanted or bitrotted, or transferring it to someone else if you are not the right person.

At the time of writing, there are 996,333 waiting-days in the system for the “review” flag (recently it was over 1,000,000), and 1494 reviews have been outstanding more than 14 days. Let’s drive that figure towards 0 :-)

Mozilla Projects and GPLed Code

I had two emails about this yesterday, so I thought I’d stick a post on Planet to clarify.

The short version: GPLed code may not be included in software that Mozilla ships.

The long version:

Three major goals of the Mozilla licensing policy are:

  1. legal simplicity for downstream users;
  2. the ability for as many people as possible to use our code in their products; and
  3. striking a balance between maintaining copyleft for our code, and the right of those downstream users to combine our code with proprietary code.

The practical result of this is that we act to preserve the right of anyone taking all or part of a codebase from us to use it under the terms of the MPL (currently mostly version 1.1, soon to be version 2), or in projects under the LGPL or the GPL, at their option. That means that all the constituent parts have to be under either the MPL 1.1 tri-license, or the MPL 2 without the incompatibility clause, or a simpler subset of those terms, such as Apache, BSD or MIT.

If any part was solely under the GPL, then people wanting to use MPL terms for the entire application could not do so – only GPL terms would be available, unless the GPL-only part was removed. It would also no longer be possible to release binary versions of e.g. Firefox under the MPL, as Mozilla does today.

If any part was solely under the LGPL, then people would not be able to use MPL terms for that part. This is possibly less of a problem, particularly if the software is a clearly-defined and self-contained library. There is some talk of changing the policy to permit LGPLed libraries to be included, but it’s at an early stage and no decision has been made yet. We would need to do some legal work to find out what the additional compliance requirements were on us and on users of our code, and whether it was possible to clearly identify what was part of the LGPLed library and what was not (both in general and in any particular case).

If an author of some code has placed it under the GPL, then that means that they want it to be used only in GPLed projects (and Mozilla projects are not GPLed projects). We need to respect that licensing decision that the author has made. There is a load of code out there which is unavailable for use by us at Mozilla. The fact that you can read the source, or use it in other projects doesn’t change that.

The release of the new MPL 2 does not change any of this.

So, if you want to use some code which is under the GPL in a Mozilla project codebase, you have a few options:

  • You can ask the licensing team to contact the author or authors of the code and ask them to make it available under the MPL or another licence which fits with
    our licensing policy. Software authors are often receptive to polite requests of this type. We have done this before for large pieces of code, e.g. cairo.

  • You can find another library implementing the same functionality. For many standard libraries, there is a GPL version and a BSD version.
  • You can rewrite the code (just as you would have had to do if you hadn’t found the library or if it had been proprietary or otherwise not open source).

Note also that I talk about “code that Mozilla ships”. We have a small number of internal tools, such as build tools, which were sourced from elsewhere and are GPLed. So finding GPLed code in a Mozilla repo is not necessarily a violation of this policy. However, “software that we ship” includes anything we create ourselves as an open source project, even if it’s primarily for our own internal use (e.g. the AMO codebase). And this policy applies to all code being created under the auspices of the Mozilla project, whether the code is stored in a Mozilla-hosted repo or somewhere else, like GitHub.

The Impossibility Of SOPA

It has been suggested that if SOPA or PIPA pass, then sites with user-generated content would need to review it all manually for copyright violations.

What would it look like for YouTube, if a reviewer had to watch every minute of video?

  • About 48 hours of video a minute is uploaded to YouTube (that figure is from May 2011, so it’s probably more now, but let’s go with that as a conservative estimate)
  • 48 hours a minute is 483,840 hours a week
  • If the reviewers worked 40-hour weeks, you would need 12,096 of them (plus a thousand or so more for holiday cover) – call it 13,000
  • If you paid them all at the US Federal minimum wage of about $15,000, it would cost $195 million per year.

But, of course, you couldn’t start the reviewers straight out of high school. First, they’d need to watch the 100 years of video which has been submitted to YouTube by content owners, so they knew a copyright violation when they saw one. (They wouldn’t be able to detect copyright violations of the content of independent filmmakers or individuals, but hey, this system isn’t about them, is it?)

The problem is that after watching 100 years of video, those who aren’t dead would have pretty poor eyesight. It would also introduce an unacceptable delay in getting the system up and running. So the job needs to be parallelized. Specialization is the key. One set of reviewers could watch all the musicals, and another could focus on vampire movies. (They might need paying extra.) If we got each trainee reviewer to spend 3 years exclusively watching Hollywood movies, TV network serials and listening to major-label music (drawing parallels with the average college degree is left as an exercise for the reader) then we could get the system up and running faster. However, we’d need 33 times more reviewers – 429,000 in all, making the cost $6.4 billion.

For comparison, 429,000 people is about 1 in 30 of the entire jobless population of the USA, and $6.4 billion is approximately 60% of Google’s annual profits. These resources would be spent entirely on content checking for YouTube, without considering Google’s other sites which take user-generated content, or Facebook, or any other social site.

There is just too much user-generated content to check it all manually, and automatic methods will never be 100% effective. So how do SOPA proponents expect that sites like YouTube can possibly remain open and legal? It’s impossible.

Does “Evil” Include Lying To Get Business?

It seems that Google has not yet managed to implement “Don’t Be Evil” worldwide in their organization.

Here is the story of representatives of Google systematically lying about their relationship with another company (whose public directory they were using to get contacts) in order to get business. Stefan Magdalinski (who I have met a couple of times) has amassed a conclusive portfolio of evidence, including taped phone conversations, of a persistent campaign of such lies.

These people were clearly working to a script. Therefore, someone somewhere within Google authorized these call centre employees in Kenya and India to lie about Google’s relationship with Mocality. That person should be fired.

We recently saw Google do the right thing in relation to another part of their company which had broken their advertising guidelines. Let’s hope we will see the same again.

[Update 2012-01-17: The plot thickens.]

The Potential Effects Of Money

If not handled carefully, money can divide a project into in-group and out-group developers. If the unpaid volunteers get the feeling that design decisions or feature additions are simply available to the highest bidder, they’ll head off to a project that seems more like a meritocracy and less like unpaid labor for someone else’s benefit. They may never complain overtly on the mailing lists. Instead, there will simply be less and less noise from external sources, as the volunteers gradually stop trying to be taken seriously. The buzz of small-scale activity will continue, in the form of bug reports and occasional small fixes. But there won’t be any large code contributions or outside participation in design discussions. People sense what’s expected of them, and live up (or down) to those expectations.

— Karl Fogel, Producing Open Source Software

Approaches to Malware in Software Ecosystems

Today, any software ecosystem, whether it’s software for an OS, addons for a browser, or apps for a phone, has to consider the possibility of malware.

If one wants to deal with the problem of malware, I see the following solutions:

  1. Have a single point of software distribution for your platform that you control, e.g. the Apple App Store for iOS. This does not entirely eliminate the possibility of malware, but does make it less likely, and does enable you to take quick action when it’s discovered. Depending on the policies and entry requirements of such a distribution point, of course, this may lead to unacceptable restrictions on user or developer freedom.
  2. Have software which attempts to detect and stop malware, e.g. virus scanners. This puts you into an arms race with the malware authors, who come up with amazing things like self-modifying polymorphic code. And they will write code to disable or work around your code. There are a lot more of them than you, and they can make a lot of money if they succeed.
  3. Have a reputation system, e.g. by requiring all code to be signed by the developer or a reviewer, and have a blacklist of “bad developers” or bad/stolen signing keys. This gives developers a key management problem, and also potentially the expense and hassle of obtaining a identifying certificate.
  4. Rely on your users to be smart, and hope that people don’t fall for the enticements to download the malware. This approach is the one taken by Ubuntu – even though anyone could make a .deb of malware and start to promote it via spam or compromised websites, it’s very rare. I suggest that this is due to the smaller and better-informed market which uses Linux, and perhaps a diversity of processors meaning that compiled code doesn’t run everywhere.

Unless I’ve missed one (tell me :-), any other solution will be a hybrid of components of the above. For example, on Android, there is by default a single point of software distribution for a given Android device (the Android Market or another vendor’s market), but you can check a preference to allow the installation of non-Market applications and, when you do, it’s up to you to avoid installing something malicious. (Let’s leave CarrierIQ out of the discussion for now!) So that’s a hybrid of 1 and 4.

Question for discussion: which solution is best for Firefox add-ons?

Currently, although there is a website for downloading addons, we allow non-AMO addons with just an “are you sure” prompt to prevent nagware. We do have the capability for code signing, but no-one uses it, and no-one notices whether anyone is using it, because there are no significant penalties for not using it. So it seems to me like we are effectively using solution 4.