Does it really matter that companies, both online and in real life, profile you based on your purchasing and surfing habits? After all, it means you get ads and offers more targetted to you, and that can only be a good thing, right?

An angry man went into a Target outside of Minneapolis, demanding to talk to a manager:

“My daughter got this in the mail!” he said. “She’s still in high school, and you’re sending her coupons for baby clothes and cribs? Are you trying to encourage her to get pregnant?”

The manager didn’t have any idea what the man was talking about. He looked at the mailer. Sure enough, it was addressed to the man’s daughter and contained advertisements for maternity clothing, nursery furniture and pictures of smiling infants. The manager apologized and then called a few days later to apologize again.

On the phone, though, the father was somewhat abashed. “I had a talk with my daughter,” he said. “It turns out there’s been some activities in my house I haven’t been completely aware of. She’s due in August. I owe you an apology.”

Footnote: Target’s revenues have grown from $44 billion in 2002 to $67 billion in 2010. Company president Gregg Steinhafel has boasted to investors about the company’s “heightened focus on items and categories that appeal to specific guest segments such as mom and baby.”

I had a mad idea last week, which I shared with the NSS team. The fact is that some companies want to monitor everything going into and out of their network. And, my view is, as it’s their network, it’s their right legally, and it’s OK with me morally too as long as everyone using the network is aware of it.

However, the current SSL trust model makes this MITMing of all connections very difficult (which is a good thing, in many ways). Companies such as BlueCoat sell boxes which will MITM SSL connections and log the data, but browsers will complain that the auto-generated certs presented are not trusted. Companies are supposed to deploy their own root to all endpoints – but this is a massive administrative hassle, particularly for mobile devices. As we have found out anew recently, this creates an incentive for trusted CAs to sell trusted intermediate certificates to these big companies. However, such certificates could potentially be abused to silently MITM anyone.

So my mad idea was that Firefox should have one cert in the root store for which the private key was published. However, when an SSL connection occurred which chained up to that root, the browser would bring up an irremovable red infobar which said: “Your connection is not private – all data transferred is being monitored by X”, where X was the O field from the intermediate cert being used. (We would require the use of exactly one intermediate.) If the O field was empty, it would say “by Unknown Attackers”, or something equally scary.

This week I found Phillip Hallam-Baker of Comodo proposing something very similar on the “therightkey” mailing list:

What I find wrong with the MITM proxies is that they offer a
completely transparent mechanism. The user is not notified that they
are being logged. I think that is a broken approach because the whole
point of accountability controls is that people behave differently
when they know they are being watched.

I don’t mean just changing the color of the address bar either. I
would want to see something like the following:

0) The intercept capability is turned on in the browser, this would be
done using a separate tool and lock the browser to a specific
intercept cert root.

1) User attempts to connect to https://www.example.com
2) Browser throws up splash screen for 5secs stating ‘Your connection
has been intercepted’
3) Business as usual.

The splash screen would appear once per session with a new host and
reset periodically.

It should show the interception cert being used as well.

Phil’s point 0 rather defeats the point – if you had to reconfigure the browser, then companies would just add their own root. But if it were built in by default, his point 0 is not necessary. He is right that you’d need a splash screen or confirmation step – we can’t sent initial data or cookies or anything until we know the user knows they are being MITMed, and gives permission to continue.

What do people think?

Although most open source developers would probably hate to admit it, marketing works. A good marketing campaign can create buzz around an open source product, even to the point where hardheaded coders find themselves having vaguely positive thoughts about the software for reasons they can’t quite put their finger on. It is not my place here to dissect the arms-race dynamics of marketing in general. Any corporation involved in free software will eventually find itself considering how to market themselves, the software, or their relationship to the software.

– Karl Fogel, Producing Open Source Software

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?

Gerv

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.

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.