Hacking for Christ

Mozilla Manifesto Discussion at FOSDEM

We had a great session on the Mozilla Manifesto at FOSDEM. My summary of the feedback (Google Groups) is now available, along with an attempt to distill and summarise the points (Google Groups).

Reducing Attack Surface

Some of you may remember my campaign to wipe SSL2-only sites off the face of the net. This was preparatory to turning off the old and insecure SSL 2 protocol in Firefox 2.

The first fruits of this attack surface reduction are now apparent - Firefox 2.0.0.2 and 1.5.0.10 both contain a fix to an arbitrary code execution buffer overflow in the SSL 2 code in NSS (security advisory). But in their normal configurations, Firefox 2 is immune to this attack because SSL 2 is turned off, whereas Firefox 1.5 is not.

So why are we taking the fix in Firefox 2 anyway? Partly because, dveditz tells me, some short-sighted webmasters, instead of upgrading their sites, have been telling their customers to re-enable SSL 2 (presumably by editing about:config!). Those webmasters have directly placed their users at unnecessary risk, which is IMO shameful.

Weekly Status 2007-02-25

This Week

• Continued discussion of location bar changes; produced Version 1.2 of proposal
• Discussed security group rearrangement with dveditz; currently blocked on Bugzilla bug 303183
• Brought regional CA discussion to a close; they are going to the back of the queue, but when I get to them each will be considered on its merits
• Did first pass through P1 CA requests (those from CAs with existing roots in our store)
• Participated in security review of Cross-site XMLHttpRequest proposal
• Obtained relicensing permission for Java and Perl LDAP SDKs
• Travelled to FOSDEM
• Prepared and led discussion session on Mozilla Manifesto; a summary of community feedback will be available soon
• Read first seven chapters of "How To Change The World: Social Entrepreneurs and the Power Of New Ideas" by David Bornstein

Next Week

• Take Monday off in lieu of Sunday
• Summary of community feedback on Manifesto from FOSDEM discussion
• Investigate the possibility of shipping new certs earlier than release of Firefox 3
• Look into the bug which blocks the security group rearrangement
• Work further down CA inclusion request list

PageRank and the Installation List

Now I know one reason why some companies are so keen to get on the Bugzilla Installation List :-)

According to the PageRank checker, the PageRank of http://www.bugzilla.org/installation-list/ is:

Junk App Preloads Subsidise Your PC?

On Dell's new customer feedback website, pressure is growing for them to ship desktop machines with Linux pre-installed. Often, when this sort of thing is suggested, there's an expectation that the machines will be cheaper, due to not having to pay the "Microsoft tax". But would it actually work out that way?

Surprisingly, perhaps not. Robert Accettura comments on a candid blog post by someone from Lenovo (whose Wordpress server seems to be down currently) who points out that the reason they preload all those apps which clutter the Windows desktop is that they get paid for doing so. Users are much more likely to buy copies of apps which have cut-down or demo versions already installed.

Such payment would probably not be available for machines shipped with Linux. If those income from these apps offset the cost of Windows itself, and if the vendor's support costs are higher for Linux and the volumes are smaller, might it end up being that computers running free-of-charge Linux distributions would still cost the purchaser more than those burdened with the Windows tax?

Weekly Status 2007-02-16

This Week

• Proposed a list of data items to gather for each CA and each certificate on the root cert list
• Participated in discussions about localisation growth in mozilla.dev.l10n and other places
• Made a proposal for changing the way the location bar works in Firefox 3
• Did further licensing cleanups; our clean status keeps regressing :-(
• Continued EV discussions in mozilla.dev.security
• Persuaded Mike Beltzner to attend the CA/Browser Forum face-to-face meeting in New York on March 1st and 2nd (with Jonathan Nightingale)
• Send feedback to Mitchell on the last newsgroup Mozilla Manifesto draft; she has since blogged a newer version

Next Week

• Attempt to reach resolution on the regional CAs question
• Attempt to reach resolution on b.m.o. security group proposal; need to discuss this further with dveditz
• Will put together CA certificate list for pending requests
• Will hopefully start to evaluate certificate requests for which I have all the data

Perspective

Firefox is just a browser...?

Location Bar Proposal

I've been following bug 366797, and discussions in mozilla.dev.security, with great interest, and I've been thinking about this for some time now. Here's my (slightly long) attempt at a unified and consistent proposal for changing the way the location bar works for Firefox 3.

In the original design of the web, the URL was supposed to be an implementation detail. That hasn't turned out to be the case, for better or for worse. Still, the URL bar itself has changed very little since Netscape 1. I believe there's scope for changing the way it works to improve the user experience.

Goals

• Don't break stuff people use
• Make the hostname stand out more to reduce spoofing
• Reduce the risk of spoofing in other ways
• Make the contents of the URL bar more understandable
• Make common operations easier

Optional Goal

• Find a way of presenting information from EV certificates

Suggested Changes

1) Hide the scheme

The scheme (e.g. "http://", "ftp://") should be hidden permanently for HTTP, HTTPS, FTP and file URLs. The differences between HTTP and FTP have long since ceased to matter to the average web user. The difference between HTTP and HTTPS is, of course, important, but we have other UI to indicate that. (And if it sucks, we need to fix it.) Eliminating the scheme also means we could do things like show some HTTPS connections as if they were HTTP - e.g. for self-signed certificates, which people just use when they want eavesdropping protection - without our UI being inconsistent. This is an improvement on the current behaviour, which is just to throw an error.

FTP could have a special favicon, as could file://.

2) Hide username and password

If present. Usernames and passwords over unencrypted channels, embedded in GET requests (which are cached) and links, are fundamentally insecure and their most common use is for spoofing (although we already have some protection against that). If people type them in, we'll use them to try and log in, but we won't show them in the location bar.

Yes, this makes them less useful - if you make a typo, you need to retype everything. I don't think this is a bad trade-off.

3) Highlight hostname

Take either the entire hostname or the Effective TLD + 1 and highlight it in a button-like style. So either:

www. example.com /foo/bar/baz?q=x

Or maybe

www.example.com /foo/bar/baz?q=x

(We need to be careful with bold; with some fonts, it reduces the difference between letters such as l and i, which is bad from a spoofing perspective. Further research required.) There is some space (perhaps half an em) either side of the button.

Clicking the hostname "button" takes you back to the root of the site - and this would affect which of these two options we actually choose. Consider george.blogspot.com/archive/... - do we want to go back to george.blogspot.com or blogspot.com? Probably the former. But then that would mean that microsoft.com.foo.bar.baz.evil.com would be all on the button, including the microsoft.com part. Difficult.

For file URLs, you'd get:

C: /Program Files/Firefox/

on Windows, and

/ home/gerv/test/

on Unix. Yes, these two are inconsistent with respect to the placement of the initial slash. I'm not sure how to deal with that. I think a prefix like

My Computer /home/gerv/test

would be horrible, particularly on Unix.

Example of what I mean, so far:

4) Display EV business name and country

For HTTPS connections with EV certificates, replace the hostname with the O (Organisation) and C (Country) fields from the certificate. So:

Paypal, Inc. /foo/bar/baz?q=x

Replacing the hostname rather than just adding to it means there's a really big difference between the real site and an attempted spoof, which would have a domain name in that space rather than a textual name.

We need to include information about the country (there can be businesses of the same name in different jurisdictions), and the question is, do we use letters (US, UK, CM) or a flag? A flag is safe because we are actually talking about countries, not languages, and it might be more recognisable and differentiable. IE and Opera are using letters.

Example (ignore the unlikelihood of the URL):

The flag is next to where the favicon should be, which raises a risk of confusing of spoofing, but leads on to:

5) Remove the favicon from the URL bar entirely

We would keep it on tabs, of course. I realise this is controversial; here's my rationale. Favicons in the URL bar are dangerous, because they represent the website having some control over what's in the chrome. This is why we turned off website access to the status bar. We already have spoof websites having a little lock as their favicon, to try and persuade users they are over SSL. Let's put the websites back into the content area box.

This would probably imply making the tab bar always visible - i.e. setting browser.tabs.autoHide to false - so that the favicon was always visible. I think this is good because it improves the discoverability of tabs and stops the content area jumping around when you go from one to two tabs or vice versa. I don't know if the default setting of this preference is a controversial issue.

I believe that the only other function of the page-proxy-icon (where the favicon appears) is to be draggable to create e.g. bookmarks toolbar entries; that role could be taken over by the domain name button, perhaps. I admit there's further thinking to do here.

6) Focus turns bar back to a text box

On focus, move back towards being a text box. People have important behaviours to do with URL bar hand-editing that we don't want to break. Therefore, clicking anywhere in the URL bar (except on the domain button) or pressing Ctrl-L, focusses the URL bar and makes the following changes.

The 3D-ness of the domain button becomes faded and 2-D - so the separation is still visible, but the URL now looks flat. The URL bar acts as much like a single text box as possible. The spaces between different parts remain (to keep the text stable; the text must absolutely not move on focus, otherwise the caret appears somewhere different from where you clicked) but if you select and copy, the spaces don't appear.

Example:

7) Change selection behaviour

People edit individual URL components. So, we should make it easier to select individual components. Like in a word-processor, a single-click focusses, a double-click selects a component ("word") - hostname, path segment, URL parameter key+value or fragment identifier, and a triple-click selects the entire URL (equivalent to "select line").

Again, I don't know if this is a can of worms - I suspect URL bar selection behaviour has been discussed before.

8) Analyse font choice carefully

If we are emboldening some parts of the URL (e.g. the domain), we need to be very careful about choosing fonts where the bold version provides enough differentiation between visually close letters like i and l. For example, the font that my copy of Firefox uses for my example bold URLs (see mockups) has very bad i/l differentiation. Perhaps we might consider a fixed-width font in the URL bar? This would also make selection easier; at the moment, putting the caret in the right place in million.com is nearly impossible for those with less than perfect motor skills, and tricky even for those with.

Not all of these suggestions are interrelated; some could be removed without affecting others. This is not supposed to be a tightly-bound take-it-or-leave-it package.

Please comment on this proposal in the newsgroup mozilla.dev.apps.firefox.

EULiar?

Some license agreements on websites really annoy me. Not necessarily because they are long, complicated and allow the owners of the website in question to come into my house, put their feet up on the sofa and drink my alcohol, but because in order to get past them I either have to waste 20 minutes of my time, or lie.

Why? Because at the end of the fifty-page lump of legalese, which is crammed into a tiny textbox with a scrollbar to make it really unlikely that anyone will ever read the whole thing, they put a checkbox like this:

I have read, understood and agree to the terms of this Agreement

In order to check the box and proceed, I actually have to have read the entire thing in all its glorious tedium - otherwise I'm lying. And of course, the website owners know that no-one ever reads it. In other words, they expect everyone to lie. It's normal practice.

They often don't even make an effort to make the agreement relate to what you are actually wanting. I recently signed up for plus.net's resale of BTOpenzone roaming wireless access - and yet I had to assent to a license agreement which, among many pages of legalese, talked about the equipment they would install on my premises.

What's wrong with a checkbox like this?

I agree to the terms of this Agreement

I'm resigned to them giving themselves permission to occupy my front room. It's not like I have much choice. At least with a checkbox like that, it'll be a pleasant surprise and I won't have to waste my time right now.

Fragment Search

Fragment Search is a Greasemonkey script for Firefox which allows people to create URLs which link to content within a page without having control over that page.

Fragment identifiers in HTTP URIs have been historically used to link to a name or ID within a document's markup. For example, http://www.mozilla.org/MPL/relicensing-faq.html#why-relicensing finds the HTML construct <a name="why-relicensing"> in the page in question.

This is historically true, although RFC 1738, the URL RFC, doesn't actually seem to mandate it. Fragment identifiers are specced at a high level in RFC 3986, but that doesn't say what they should be used for either. (If you know where this is specced, please let me know.)

But what do you do if the document doesn't have a name or ID where you want to link, and you don't have control of the document (as is the case for most people and most documents)? My suggestion is to extend the syntax of the fragment identifier using a character which is illegal in names/IDs ("!"), and which conforming browsers can use to trigger a textual search of the page contents. So, for example, http://www.gerv.net/#!s!design searches for the word "design" on the front page of gerv.net.

Clearly, this is just a proof of concept. It needs to be built into browsers to be generally useful. But please do try it out and let me know what you think.

Read more, install the script or extension, and try it out...

Weekly Status 2007-02-09

Now I've started spending a lot more time working on Mozilla things, I've started doing a weekly status report for Frank. I'm also going to post it here (well, most of it :-) in case it's of interest.

This Week

• Continued to knock the list of outstanding CA applications into shape
• Started a discussion on whether we should admit "regional CAs"
• Got on top of my mail backlog, and started to knock off a few longer term mini-projects
• Tried to do some textual analysis on the contents of the mozilla.feedback newsgroup (from Hendrix)
• Found some people to maintain the Effective TLD list
• Worked on b.m.o. security group reorganisation proposal (discussion in mozilla.dev.security)
• Tried out Passpet Firefox extension; couldn't get it working
• Participated in EV discussions in mozilla.dev.security
• Submitted proposal to talk at OSCON - "Beyond the Lock: Browser Security UI For The Distracted", in cooperation with Mike Beltzner

Next Week

• Will begin to evaluate actual CA requests
• Hope to get started on master list of CAs (blocked on getting format and list of required info from Frank)
• Work on Content Restrictions patch as part of Firefox 3.0 (waiting for design help from dveditz)

Does anyone have a Wiki-to-HTML bookmarklet?

Statistical Analysis on mozilla.feedback 2

I just spent an hour or two trying to do some statistical analysis on mozilla.feedback, as I suggested back in December. My approach was a very naive "\b\w+\b" Perl regexp to extract the words. However, the results weren't particularly good :-( They get skewed by a few repetitive spams, and things like that. Make the chains too short, and you don't find out much. Make them too long, and you fall foul of the fact that different people express themselves in different ways. In a message base of the first 6600-odd, I found the following:

Keep up the good work: 72
I would like to see: 28
it would be nice : 57
I would like to: 89
I don't like: 47
in the address bar: 35
I really like the: 23

Not exactly earth-shattering, although very nice. Does anyone have any better ideas for uses for the Hendrix data in the mozilla.feedback newsgroup? Even if we never look at it, it serves the purpose of diverting non-bug-reports and making people feel like they've made a contribution. But it would be nice if we could get more out of it.

Lazy Spammers

It seems that spammers have now got lazy; they expect their victims to do their work for them. Check out the last line:

Genuie Viagra and Cialis from the Original manufacturer are selling by Trusted vendor.

Don't miss this chance to buy Hight-Quality production!

Our online shop: http://www.url-removed.no-publicity-for-you.tld

Only today and only for you all prices eased for 60%!

P.S.: Forward this email to 10 your friends and you'll get a good bid from us.

It's a sort of combination spam and chain letter, of the "Bill Gates will pay you $5 if you send this on" variety. Clearly, spam filters must be working better than we thought.

Thinking about it, what strikes me is their optimism that anyone will actually do it. Imagine the covering note:

Hi Jeff. Great golf last Saturday. Better luck next time!

I was thinking about who to forward this email to, and your name popped into my head. I know you're getting on a bit, and thought you might be having a bit of trouble... you know. With the wife. Could happen to anyone. I know it troubles me occasionally. Anyway, this looked like a good deal, so I thought I'd cut you in. Let me know how it works out, eh? <wink>