Hacking for Christ

Script Keys

This is the second of my three ideas for the client-side mitigation of Cross-Site Scripting (XSS). It's based on the same principle - that of the site owner specifying which scripts should be permitted and which not - but takes a slightly different approach.

Basically, the idea is that an HTTP header, Script-Key, defines a random string or "key" and only script labelled in some way with that string is allowed to execute. As the string will be different for every page load, injected script would not be correctly labelled and therefore would not be permitted to run.

The trick is trying to label the script in a way which allows the resulting markup to still validate. Having analysed the legal attributes of the <script> tag, here's my current idea:

Content-Type: text/html
Script-Key: D3FC219A

<script type="text/javascript;key=D3FC219A">
...
</script>

Of course, that could also be a <script type="..." src="...">.

That's all very well, but how do you label e.g. script in event handler attributes like "onchange"? One idea would be just to say "you don't", and encourage use of proper DOM methods to add event handlers. Another would be to do something hacky like saying as long as the text of the script contained they key, it would be OK. So you could do:

<hr onclick="var foo = 'D3FC219A'; ..." />

Or, you could require the handler to set a navigator.scriptkey property to the correct key before you could do anything apart from assign variables. But that's rather hacky too, and perhaps harder to implement, as you need to sandbox already-running script. (Either of these ideas would obsolete the content-type-parameter method.) Better suggestions welcomed. (We could define a new attribute, perhaps through the WHAT-WG. That might be cleaner, but it wouldn't solve the event handler problem unless the attribute was made applicable to all tags.)

So how does this approach compare with Content-Restrictions? It's a single layer idea - i.e. if it's breached, and the attacker manages to e.g. inject script inside a block which is labelled as safe, then it's game over. But it does reduce the attack surface. Content-Restrictions, on the other hand, is layered - if one restriction doesn't prevent an attack, another one might. As a simple example, for "script=head,cookies=none", even if you managed to inject script into the head, you couldn't read cookies.

FreeDownloadZone.com Are Scuzzballs

Jed: "Hey, I know a great business model! Let's profit from the hard work of others by selling what they are giving away for free!"

Ted: "Er, Jed, isn't making money from people's ignorance a bit unethical?"

Jed: "Unwhat, sorry?"

Ted: "Unethical."

Jed: <looks concerned> "Ted, are you feeling OK?"

Ted: <shakes head> "Sorry, don't know what came over me there. Let's sign up for Google ads for the 'firefox' keyword. That'll be sure to bring the suckers in..."

Mitigating XSS Attacks With Content Restrictions

Currently, the only defence against Cross-Site Scripting (XSS) attacks is server-side filtering of untrusted content. If that fails, the user agent is wide open. In absence of any information from the site designer, the user agent cannot make decisions about what script in the page to execute and what not to execute - it has to execute it all.

So, the perfect way to prevent XSS attacks would be for the user agent to read the website designer's mind to determine which scripts embedded in a page were legitimate and which were malicious. In the absence of affordable and reliable mind-reading technology, and in consideration of the mental fatigue this would undoubtedly induce in web page authors, my new paper, "Content Restrictions", presents the draft specification of a way for a site designer to explain his state of mind to the user agent by specifying restrictions on the capabilities of his content.

I hope to turn this into a draft RFC soon, so any comments would be extremely welcome.

Automatic Resolution of UNCONFIRMED Bugs

We are going ahead with the plan to automatically resolve some old UNCONFIRMED bugs. We will be taking the first step (issuing the warning) on the morning of Sunday 10th April, UK time (the middle of the night in the US).

This idea has been discussed previously on this blog. We've managed to address the major issues raised in that discussion; we've got a new EXPIRED resolution in Bugzilla, the language of the comments has been improved, and we're excluding bugs with the 'testcase' keyword. I'm open to further suggestions, as long as they don't delay the process. In the end, even if we can't get it 100% right, the pros outweigh the cons.

Link Fingerprints

I've noticed that some organisations, particularly Microsoft, have been releasing security updates where the download URL contains some form of checksum for the file. Here's an example, which is the download for this security vulnerability in Windows 2000.

The page doesn't explain which algorithm they use to generate the hash. It's a 128-bit value, but it's not straight MD5 (wrong values), or SHA1 (wrong length). It also doesn't say why it's there, or give you any way to use that information to verify the download, so I assume it's designed for automated tools like Windows Update or similar. If anyone has more info, please comment. [Update: apparently, it's just a GUID - basically a random number. So all the stuff below is my invention rather than being copied from anyone else.]

This is a great idea in principle, because it means that no-one can break into the server and trojan the file - if they do, then the checksum doesn't match any more. And if they change the name of the directory it's in to match the new checksum, all the published links break and users still don't get the trojaned file. But it's no use if the checksum isn't checked.

So I started thinking. It must be fairly common that users download files where they are given the URL by a trusted source - or, at least, get it from another location or server which would also have to be compromised.

So what's to stop any user agent verifying a downloaded file against its path-based checksum, or 'Link Fingerprint'? It would work like this: if the user agent downloaded a file whose URL had a path component matching a particular pattern (perhaps /md5[0-9a-zA-Z]{16}/), the user agent would checksum the file, compare it to the URL, and put up a nasty scary "don't trust this file" warning if they were different. I'm assuming it's fairly unlikely that many files will have paths like that where the relevant path component isn't an md5sum.

Yes, files may be digitally signed with the distributing company's key, as most Linux distributions do with their RPMs, but verifying that often involves a lot of PKI hassle which is currently out of the reach of many users. The idea of this would be a simple way for a software distributor to reduce the likelihood of their download being successfully trojaned, with no need for the user to be made to perform verification steps.

There are implementation details, of course - you'd need to watch out for redirects, for a start - but is the basic idea useful, or are there too many potential problems with it? Or perhaps it's solving an issue that isn't a problem in practice?

Simple Curvy Corners

Rounded corners are the bane of a website designer's life. I can take them or leave them; for some reason, graphic designers seem to swoon at the slightest hint of revealed shoulder. And, while Mozilla has a CSS extension which does them, and CSS 3 standardises it, if you want them cross-browser then you used to be stuck with tables, or wrapping your divs in up to three others and using background images.

However, another alternative is script. If your site already requires JS, then you can now have lovely rounded corners in all modern browsers using a simple script and CSS include without the need for extra markup.

IDN Update

I was asked yesterday about the current status of the work on IDN homograph spoofing. Here's what's being done.

1. The Unicode Consortium are writing a Technical Report (TR) called "Security Considerations in the Implementation of Unicode and Related Technology", which includes a section on the homograph problem. This report is currently under active development. It includes the start of a very useful list of ASCII confusables, which should be useful to the registries in point 3).

2. A working group of the IAB, which is part of the IETF, is looking at revisions to stringprep and nameprep, two of the standards underlying IDN. These standards define what characters are permitted, string canonicalisation and so on. We hope to be able to reduce the number of permitted characters without affecting legitimate usage, thereby reducing the scope for spoofing.

3. Registries which are issuing IDN domains are being asked to put in place appropriate policies to prevent two homographic domains being registered to different entities. Such a policy would probably involve a permitted character table (a subset of the characters defined by 1) and a method of dealing with homographic domains using characters within that table, such as aggregation or blocking.

4. Browser manufacturers are putting in place temporary measures (mozilla.org, Opera, Apple) to protect users while a long-term strategy is devised. The core of that strategy is likely to be based around a black or whitelist of TLDs, allowing IDN to be rolled out for each registry once they have appropriate policies in place (see point 3). We hope to achieve consensus on which registries have such policies, and eventually to have a neutral body keep the list.
   

As you can see, this is a hard problem to solve, and work at every level is necessary. However, I hope that once all of it is completed, we will be able to achieve the goal of making legal IDN domains first-class citizens on the Internet, deployable and usable with only the same risks as ASCII domains.

Greasemonkey

It's good to see Greasemonkey getting some press. It's a fantastic idea. I demoed something similar, although not as capable, at EuroFoo in August last year. I called it "refacing" - a way of changing the face of particular sites to suite yourself. My simple example was defacing the SCO website so that all the references read "SCOundrels". (Amusingly, the current Word of The Day on the front of www.sco.com is "Longevity". Presumably they are referring to Linux rather than their own business.) But I never had time to take it forward and it languishes still on my laptop. I'm glad someone is making this happen :-)

You don't actually need an extension to do something like Greasemonkey - you could do it all from a bookmarklet with appropriate server-side support. The bookmarklet injects a script which adds a DHTML popup to the page which gives a menu of available scripts. Of course, an extension gives much better UI, and is probably the correct solution for the long term.

However, the key problem with running scripts written by others in your session context for a website is security. There's no real way to control a malicious user script once it's running. Audit is your only line of defence. Be careful out there, kids.

PasswordMaker

I came across PasswordMaker on the most recent MozillaZine Independent Status Report. It's a password generator - a bit like Blake's PwdHash, but it takes the approach I recommended in my comments of getting people to take an explicit action to fill in the password.

Unfortunately, I can't recommend it, because (and this is why this post is in the Usability category) the authors seem to have gone out of their way to make the program extra complex. To see what I mean, have a look at the online version, which you are supposed to use when you don't have access to a copy of the extension.

Now, the ideal UI for something like this would be one where you enter your master password once, and then enter URLs, and an appropriate password comes back to you. At most, you have to enter two pieces of information. However, with PasswordMaker, you also need to enter:

• "Use l33t" - whether you want to put the text through a l33t-speak generator at various points in the process. I can't see the point of this, apart from to create more settings to remember. It doesn't make the generated passwords any more compatible.
• "l33t level" - a parameter for configuring the l33t feature.
• "Hash algorithm" - why would a user ever want to choose the hash algorithm? The implementor should just pick any of the suitable ones, and stick with it. Yet another thing to remember, and gratuitous incompatibility and complexity. Note the number of JS algorithm libraries the page has to include.
• "URL components" - choose which URL components are included in the hash to make up the password. I can't see a use for this either - clearly, you should include the protocol, port, domain and path but not the query parameters. Sadly, in the online UI, that's not one of the options - "query parameters" are bound to "path" in the same checkbox.
• "Length of generated password" - this should just be the length which is long enough to be secure, and compatible with most restrictions people place on forms. I'd suggest 8, but you'd need to do research.
• "v0.1 compatibility mode" - a.k.a. they didn't think about all this stuff hard enough first time round ;-). Note that you can only select this if you remember that version 0.1 used MD5 as the hash algorithm - but it doesn't say that anywhere.

In summary, PasswordMaker is an excellent idea, but it has a terminal case of featureitis. My recommendation: do a (backwardly-incompatible) version 2 with sensible defaults and no configuration, and it could really take off.

Socially Responsible Browsing

Camino, the closely-integrated MacOS X browser, as a new website. One quote stood out:

[T]he Gecko rendering engine brings cutting-edge innovations and capabilities to users in a standards-friendly and socially responsible form.

Plagiarising shamelessly, wouldn't that be a great slogan for Firefox? "Firefox. Socially responsible browsing." It means your browsing experience will be (mostly) unsullied by popups and other annoyances. It means that sites web designers build to the standards will render accurately without too much need for hacks, workarounds, and the tearing-out of hair. It means your machine won't get rooted and be used to DDOS or spam some innocent third party.

Socially responsible indeed.

Sweepstake: Last Chance To Enter

Entries close for the bugzilla.mozilla.org 300,000 bug sweepstake at midnight tonight ZST.

If you can't be bothered to take the time to do a proper estimate, just have a wild guess :-)

Firefox Advert

A guy called Eric Edwards, a motion graphics student at the Savannah College of Art and Design, has done a rather cool television-style advertisement promoting the use of Firefox. It's a student project which he's planning to enter in an Adobe design contest.

The style reminds me of the original techno-industrial Mozilla artwork (like the banners).

If you like it, he's looking for internships and jobs at the moment. And yes, he did get permission to use the trademark. :-)

UI Dilemma

I have a UI dilemma.

Say you have some toolbar buttons which are part of the UI in a product. These buttons have an obvious function - denoted by their icon and text. This function is applicable at all relevant times. The buttons work and do the right thing in most cases, but in some defined cases it is not technically possible to make them do what a user would expect them to do. The user can perform the operation they would expect the button to trigger - it just requires opening another window, and clicking an identical button in that window instead.

The buttons cannot be disabled, either permanently or just in the problematic cases. The buttons cannot be removed. Which of the following is worse, when you click the button in a problematic case?

• it just silently does nothing
• it puts up a popup saying something like "to achieve what you want to do, click the same UI in another window"

Popups are really irritating, particularly "well, why didn't you do that for me, then?" popups - but is UI which looks working but silently fails even more irritating?

Gorillas In Our Midst

The answers for the observation experiment are as follows:

1. 14 passes from white to white;
2. 19 passes from black to black;
3. A gorilla.

Missed the gorilla? Watch the video again, and try and work out why you didn't see him first or second time round. It's called inattentional blindness - your mind ignores events it's not concentrating on. You can read an overview or see some more demos. The O'Reilly book Mind Hacks by Tom Stafford and Matt Webb also discusses this and similar phenomena.

Of the 17 people who mailed me:

• 8 (47%) didn't see (or didn't mention) the gorilla
• 4 (24%) saw him first time
• 3 (18%) saw him second time
• 1 ( 6%) saw him third time
• 1 ( 6%) knew the secret before the start

Update 2005-03-17: This next paragraph is entirely wrong; I had mistakenly turned pass 9 into two passes. So the answers are 14 and 19, and quite a few people got it right.

[Unrelated to the gorilla, almost everyone said 14 for white-to-white passes, which is one short of the true total of 15. Pass 10 is both quick and completely hidden from the camera, but a different person gets the ball, so it must exist :-) Most people correctly got 19 for black-to-black. Congratulations to Onkar Shinde who was the only person to get both numbers correct.]

Bugzilla 300,000 Bug Sweepstake

It's that time again! :-) The bugzilla.mozilla.org bug database is about to hit another major milestone and, as is traditional, I'm running a sweepstake on exactly when that will be.

So, please email me giving the date and time you think bug 300,000 will be filed. Your entry should be on the first line of your email, and formatted as follows:

2005-04-01 11:09:46 - gerv@mozilla.org

All times are in ZST ('Zilla Standard Time, a.k.a. PST Update 2005-03-17: make that 'the time on Bugzilla timestamps' - I forgot about Daylight Savings), and the email address should be your Bugzilla ID. If you prefer to be contacted on a different address, add that as well, below the entry line. We have ample graphs and charts to help you with your assessment.

Last time we did this, it got covered on Slashdot and lots of random people entered. But I think this should be a Mozilla community event so a) please don't post this to Slashdot or any other non-Mozilla-focussed news source, and b) entrants must have a Bugzilla account on bugzilla.mozilla.org created before the end of February 2005, and which has done something useful in the past six months.

I'm obviously not going to check each entry, but I'll check the "winners", and keep discarding entries until I find the closest one which meets these criteria. The judge's decision is final, and any funny business regarding the filing of bugs on or around the 300,000 mark will be frowned upon. The closing date for entries is midday ZST on Tuesday 22nd March. The winner will get some Mozilla or Firefox merchandise - exact amount and nature to be decided.

Lastly, please do not attempt to hijack bug 300,000 and turn it into some sort of "celebration" bug. It should be a legitimate bug report like any other, and dealt with as such. Let's party somewhere more fun :-)

Visual Basic 6

Another example of people getting stuffed by proprietary lockin: Visual Basic 6 developers are petitioning Microsoft not to end support.

I can't imagine, though, why anyone would choose to program in VB if they'd had experience of any other programming language. The last three days I've been programming in VB 6, and it has caused me more stress recently than I've had in months. One particularly irritating thing is that it's impossible to get good online VB 6 documentation any more, because Microsoft has replaced it all with VB.NET docs, and forgotten the very existence of VB 6. Oceania has always been at war with Eastasia.

Observation Experiment

I came across an interesting observation experiment the other day, which I want to share with you.

There's a video on this page, embedded in a 7MB Java applet - so it takes a while to load. The idea is to watch the video, and count how many times a basketball is passed between two players who are both wearing white t-shirts. You may have to concentrate quite hard. Then, watch the video again and count how many times a basketball is passed between two players who are both wearing black t-shirts.

Email me with your counts, and any other comments you have on the video. Please don't post counts or other information in the comments, so everyone can have a go.

Comments Reopened

The MTCloseComments plugin (in general, a good and very useful thing) seems to have gone a bit mental recently and seems to have been closing stuff around 24 hours after I post it. [Update: turns out it was actually a MozillaZine reaction to a comment spam attack.] I've reopened the last two weeks of postings, so if you had something you wanted to say and couldn't, fire away :-)

Prevention of Terrorism Act

The UK Government has just passed the Prevention of Terrorism Act, a law permitting it to take a range of measures against foreign [Updated: all] terrorist suspects, including detaining them indefinitely without trial.

In the future, it is absolutely inevitable that there will be an Islamic terrorist attack in the UK. We live in a fallen world. "Such things must happen, but the end is still to come." People will die. And the inevitable questions about prevention will be asked: Could we have done more? Should we have done more?

The answers to those questions must be the same whether we ask them now or we ask them then, and it is quite possible that they should be Yes - and No. There are always more actions a government can take to protect the citizens of a country, but it is not always right to take them.

Our Prime Minister said, in an angry exchange in the House of Commons, that he was protecting the citizens while trying to preserve civil liberties. This is wrongheaded. He should be preserving civil liberties while trying to protect the citizens. And this should be our attitude now and in the future - we should do everything within our power to prevent acts of terrorism, without being terrified into imposing unacceptable restrictions on our citizenry. I applaud the courage of politicians who stand up for these rights, at the risk of being cheaply blamed when the inevitable attack occurs.

So what can and must be said to the grieving families of the victims? We feel for your loss, and we thank you for your sacrifice. We will do everything in our power to hunt down and punish those responsible. But we could not have done more to keep this country safe, if we also wanted to keep it free.

Seamonkey

I'm very pleased to see a group stepping up to take control of Seamonkey. It's something I've been working for, and I'm very glad to see it happen. The Mozilla Suite still has a lot of users this side of the Atlantic (there's a distinctly European slant to the supporters list). Keeping this effort within the mozilla.org framework is a win for everyone involved.

One piece of advice for those striking out in a new and fresh direction: your first release ("Seamonkey Suite 1.0" or whatever it ends up being called) should not be a world-shaking event in browser technology development. Take time between now and the Firefox 1.1 release to get organised, plan and keep things ticking over, and then release something off that branch with as few changes as possible. Start Small and Simple, and build from there. You'll have enough problems designing and implementing a properly-QAed release process without adding more bugs by changing the code.

Let a hundred browsers bloom :-)

Domain Usage Agreement Released

At long last, we've finally managed to produce an agreement people can sign if they want to use a domain name with one of the Mozilla Foundation trademarks in (e.g. "Firefox" or "Mozilla"). Apologies to all those people who have been waiting for this.

Data Visualisation

How would you present 1000 lines of data, each consisting of ten data points, in an accessible format?

Someone pointed out to me this interesting solution to the problem applied to a century of popularity data on the top 1000 baby names (requires Java). It cleverly combines typedown find with a dynamically recalculated and scaled chart - simple yet powerful.

OK, so most of you won't have deep unmet baby-name-popularity-analysis needs, but I think there are lessons to be learnt here about creative ways to allow users to visualise and manipulate large quantities of data.

(None of you will be surprised to hear that "Gervase" is not in the top 1000 names for any decade this century.)

Free Binaries of Firefox

Six weeks ago, RMS emailed the Foundation to politely point out that the builds of Firefox we ship are not Free-as-in-speech. He's quite correct in this assertion. We ship Talkback, a non-free crash-reporting tool, and there are also some provisions in the Firefox EULA which he suggested are non-Free as well, such as the restriction on removing the trademarks, and the requirement to follow US export regulations.

(I should point out at this juncture that the Firefox source code, as pulled and built from CVS, is Free, although it may be subject to restrictions until you remove any Mozilla Foundation trademarks. I'm looking for help to make it easier for people to avoid being subject to even those restrictions.)

We discussed the issues by email for a while, but other priorities intervened and not much progress was made. So, I went up to RMS after his talk at FOSDEM to apologise for the delay. He said (perhaps understandably) that he was tired of waiting, and planned to use FOSDEM to recruit some developers to make free binary builds, and release them under a different name.

So, on the Sunday during the Q&A in the Mozilla developer room, RMS asked someone to read out a short statement to that effect, asking people to email him if they were interested in helping make such builds. Having heard it, I responded by explaining the situation to the room, as outlined in this blog post.

The Foundation does hope to make Free binary builds available, with no Talkback, and a different EULA. Such builds would not be promoted by us, but anyone could point at their FTP directory and say "those builds are Free". However our build engineer (Chase Phillips) is utterly exhausted after all the work necessary to get 1.0.1 off the ground, and is taking some time off. When he returns and things calm down, we hope to find time to make this happen.

IP over VoIP, Anyone?

Having seen someone actually using IP-over-DNS in a pub in the centre of Brussels at FOSDEM, could the next move be IP over VoIP?

UK Wi-Fi hotspot users are being offered free Skype calls. "Broadreach hopes that after making free Voice over Wi-Fi calls consumers will be more likely to pay to check their email or surf the web at its hot spots."

QuickText Extension

This is an update on my search for a Thunderbird extension to help me deal with large volumes of email, most of which requires the same response because people don't read FAQs.

For the past few weeks, I've been happily using Emil Hesslow's QuickText extension, which does exactly what I need. Many thanks and kudos to Emil. I'd recommend QuickText to anyone else who finds themselves repeating the same things in email after email.

Lies, Damn Lies, and Statistics

Amazing how a 15% market share growth in five weeks can be interpreted as bad news...

If Firefox was growing linearly, the percentage growth over constant time would be expected to decrease as the installed base got bigger. If the percentage value was maintained, we'd in fact be growing exponentially. The truth is probably somewhere between the two.

Help Wanted: Name-Changing Script

Recent events have convinced me that it's important that we have a mozilla.org-blessed script which removes the "Firefox" trademark from the code. This could then be run by anyone wanting to make an "Iceweasel" browser under part 3) of the Trademark Policy, and they could be certain that they weren't in any legal trouble. Basically, it would run over a freshly-pulled tree and change the word "Firefox" to a given string in a number of key files (such as brand.dtd) and other places.

Would anyone like to volunteer to write such a script? It would need to be in Perl, because it's a language I know - the relicensing script was originally done in Python, and I had terrible trouble finding someone to maintain it. (I should say that the guy who I finally found is currently doing an excellent job.)

Let me know if you can help - but please don't volunteer unless you consider yourself a reliable person ;-)

That's More Parties Than In The Iraqi Elections...

I happened to revisit the Mozilla Party page while doing research for my FOSDEM presentation, and noticed that there was 389 parties celebrating Firefox 1.0! The biggest, in Mexico, had 180 attendants! That's pretty impressive.

I suspect 1.1 won't generate quite the same amount of buzz; perhaps people are starting to take excellent browser software for granted ;-)