Attention conservation notice: 900 words of inside baseball about Mozilla. No security content whatsoever.

The Mozilla Project has been taking a whole lot of flak recently over its new “rapid release cycle”, in which there is a new major version of Firefox (and Thunderbird) every six weeks, and it potentially breaks all your extensions. Especially the big complicated extensions like Firebug that people cannot live without. One might reasonably ask, what the hell? Why would any software development team in their right mind—especially a team developing a critical piece of system infrastructure, which is what Web browsers are these days, like it or not—inflict unpredictable breakage on all their users at six-week intervals?

The first thing to know is that Firefox’s core developers are really focused on making the Web better. If we weren’t, we would be hacking on something other than a Web browser. The old release cycle was way too slow for us to do that effectively; as Jono Xia describes in his blog post “It’s Not About the Version Numbers,” anything we did might not get out to end users for over a year. When David Baron fixed visited-link history sniffing, he patched Firefox first—but Chrome and Safari shipped the change before we did.

You should read Jono’s post now. I’ll be here when you get back.

Shipping new versions of the browser every six weeks is clearly a better way to improve the Web rapidly, than shipping a new version only once a year or so. But what’s stopping the Mozilla team from shipping a new batch of under-the-hood improvements to the Web every six weeks without breaking anything? Why do we need to break things?

Well, we tried not breaking things for ten years, give or take, and it didn’t work. The second thing to know is that the core browser (“Gecko”) suffers from enormous technical debt. Like any large, 15-year-old piece of software, we have code in abundance that was written under too much time pressure to get it right, was written so long ago that nobody remembers how it works, isn’t comprehensively tested, or any combination of the above. We also have major components that reasonably seemed like good ideas at the time, but have since proven to be a hindrance (XUL, XBL, XPConnect, etc). We have other major components that should have been recognized as bad ideas at the time, but weren’t (XPCOM, NSPR, etc). And we have code for which there is no excuse at all (Firefox still had code using the infamous “Mork” file format until just this summer, and I understand it’s still live in Thunderbird).

It gets worse: many of the bugs can’t be fixed without breaking stuff. For example, take bug 234856. That’s a seven-year-old display glitch. What could possibly be an excuse for not fixing a simple display glitch for seven years? Well, the root cause of that bug (described more clearly in bug 643041, where the actual fix is posted) is an error in an XPCOM interface that, until we decided we weren’t going to do this anymore (post-FF4), was “frozen”—it could not be changed even though it was wrong, precisely so that extensions could depend on it not changing. There are thousands of XPCOM interfaces, and extensions can use all of them. That’s a great strength: it lets Firefox extensions do far more than, say, Chrome extensions can. That’s also a huge problem for people trying to make the core better. (Only about 200 of these interfaces were permanently frozen, but pre-FF4 we tried to avoid changing even the un-frozen ones as much as possible.) You’ll notice that the change in bug 643041 makes it easier to write extensions that manipulate SSL certificates, because now there’s just one nsIX509Cert interface, not three. But taking away nsIX509Cert2 and nsIX509Cert3 breaks code that was using them.

Some bugs can’t even be fixed without breaking Web sites. Any time Gecko doesn’t do the same thing Webkit and/or IE do, we (and the Webkit and IE people) want to make that difference go away—but to do that, at least one of the three has to change, and there may be sites out there relying on the behavior that just got taken away. In some cases, adding features breaks the web. For instance, if you write ‘<element onevent="do_something()">’ directly in your HTML, when the event fires, the JavaScript interpreter will try to call a method of element’s DOM API named do_something before it tries to call a global function with that name. Which means that adding DOM methods to any HTML element potentially breaks websites. (This is not a problem if you assign to element.onevent from a <script>.)

This is why Mozilla core developers can seem so callous to the needs of extension and website developers built on Gecko. We know that we depend on both groups for our continued relevance—a browser is no use at all with no websites to browse, and without extensions there is not much reason to pick one browser over another. But we feel that right now it is more important to fix the problems with our existing platform than to provide stability. In the long run, we will have a better platform for both groups to work with. And in the long run, stability will come back. There are many bugs to fix first, but there are not infinitely many bugs, even if it seems like it sometimes. Having said that, there are some things we could be doing right now to make extension and website developers’ lives better … but I’m going to save them for the next post. 900 words is enough.

Note to commenters: I know lots of people are unhappy with the UX changes post-FF3.6, but let’s keep this to discussion of API breakage, please.

 <!-- jQuery 1.5.2 -->
 <script src="h:sha1,b8dcaa1c866905c0bdb0b70c8e564ff1c3fe27ad"></script>

Now the problem with this is, these hexadecimal strings are inconveniently long and are only going to get longer. SHA-1 (as shown above) produces 160-bit hashes, which take 40 characters to represent in hex. That algorithm is looking kinda creaky these days; the most convenient replacement is SHA-256. As the name implies, it produces 256-bit hashes, which take 64 characters to write out in hex. The next generation of secure hash algorithms, currently under development at NIST, are also going to produce 256-bit (and up) hashes. The inconvenience of these lengthy hashes becomes even worse if we want to use them as components of a URI with structure to it (as opposed to being the entirety of a URN, as above). Clearly some encoding other than hex, with its 2x expansion, is desirable.

Hashes are incompressible, so we can’t hope to pack a 256-bit hash into fewer than 32 characters, or a 160-bit hash into fewer than 20 characters. And we can’t just dump the raw binary string into our HTML, because HTML is not designed for that—there is no way to tell the HTML parser “the next 20 characters are a binary literal”. However, what we can do is find 256 printable, letter-like characters within the first few hundred Unicode code points and use them as an encoding of the 256 possible bytes. Continuing with the jQuery example, that might look something like this:

<script src="h:sha1,пՎЦbηúFԱщблMπĒÇճԴցmЩ"></script><!-- jQuery 1.5.2 -->

See how we can fit the annotation on the same line now? Even with sha256, it’s still a little shorter than the original in hex:

<!-- jQuery 1.5.2 -->
<script src="h:sha256,ρKZհνàêþГJEχdKmՌYψիցyԷթνлшъÁÐFДÂ"></script>

Here’s my proposed encoding table:

    0              0 1              1
    0123456789ABCDEF 0123456789ABCDEF
 00 ABCDEFGHIJKLMNOP QRSTUVWXYZÞabcde
 20 fghijklmnopqrstu vwxyzþ0123456789
 40 ÀÈÌÒÙÁÉÍÓÚÂÊÎÔÛÇ ÄËÏÖÜĀĒĪŌŪĂĔĬŎŬÐ
 60 àèìòùáéíóúâêîôûç äëïöüāēīōūăĕĭŏŭð
 80 αβγδεζηθικλμνξπρ ςστυφχψωϐϑϒϕϖϞϰϱ
 A0 БГДЖЗИЙЛПФЦЧШЩЪЬ бгджзийлпфцчшщъь
 C0 ԱԲԳԴԵԶԷԸԹԺԻԽԾԿՀՁ ՂՃՄՅՆՇՈՉՊՋՌՍՎՐՑՒ
 E0 աբգդեզէըթժիխծկհձ ղճմյնշոչպջռսվրցւ

All of the characters in this table have one- or two-byte encodings in UTF-8. Every punctuation character below U+007F is given special meaning in some context or other, so I didn’t use any of them. This unfortunately does mean that only 62 of the 256 bytes get one-byte encodings, but storage compactness is not the point here, and it’s no worse than hex, anyway. What this gets us is display compactness: a 256-bit hash will occupy exactly 32 columns in your text editor, leaving room for at least a few other things on the same line.

Choosing the characters is a little tricky. A whole lot of the code space below U+07FF is taken up by characters we can’t use for this purpose—composing diacritics, control characters, punctuation, and right-to-left scripts. I didn’t want to use diacritics (even in precomposed form) or pairs of characters that might be visually identical to each other in some (combination of) fonts. Unfortunately, even with the rich well of Cyrillic and Armenian to work with, I wasn’t able to avoid using a bunch of Latin-alphabet diacritics. Someone a little more familiar with the repertoire might be able to do better.

Consider the recently redesigned online fiction zine, Chiaroscuro. As of this writing, they’re using an embedded font called Merriweather. [EDIT 8 April: Chiaroscuro has removed the problematic font from its site.]

Here’s what the first paragraph of body text for volume 47 looked like on my Mac, using Firefox 4:

Pretty slick, yeah? Unfortunately … here’s what that same para looked like on Windows, with the same browser:

The letters are squished together in places, and the lowercase Ns are too tall. It’s even worse on Linux: not all the strokes are the same thickness, some of the letters are still too tall (look carefully at the lowercase D, for instance) and others extend below the baseline when they shouldn’t (such as the lowercase R).

What causes this radically different appearance of the same font in the same browser? At typical body-text sizes, the computer has to draw each letter using only 15 or so pixels in each direction. It’s not possible to draw each letter exactly as the typographer intended, and keep all the lines crisp and smooth, with that few pixels. Windows, OSX, and Linux all resolve this dilemma differently: to oversimplify a bit, OSX tries harder to preserve the font shapes, Windows tries harder to make the lines sharp, and Linux tries to do both at once and winds up achieving neither. (For lots of technical discussion of exactly what the difference is, see these blog posts from 2007: Respecting The Pixel Grid, Font rendering philosophies of Windows & Mac OS X, Texts Rasterization Exposures). People argue, loudly, about which choice is better (as the above blog posts and their comment threads demonstrate) but I think it would be relatively uncontroversial to say that the Windows font-drawing algorithm only works well with help from the font itself. The Merriweather font on Chiaroscuro demonstrates this: it doesn’t provide this help (it doesn’t have enough “hinting” information) so it looks fine on OSX, but horrible on Windows (and Linux – although there it’s not quite so much the font’s fault).

This isn’t “just” a matter of aesthetics (scare quotes because nobody wants visitors to think their website is ugly); it can mean that people can’t read your text. I myself find Chiaroscuro unpleasant to read on Windows or Linux, but my acquaintance Rose Lemberg, who has weaker eyesight, says the site is illegible. I don’t think Chiaroscuro set out to be illegible, but I’ll bet cookies to donuts Chiaroscuro’s designer didn’t bother testing their new font on anything but a Mac.

I don’t want to deter people from using embeddable fonts altogether; however, this is another reason why you can’t just test your site on one operating system. At the very least you need to be testing on OSX and Windows (and I understand there are significant differences between XP and Vista/7 in this area, by the way); I would thank you for trying Linux as well (maybe you don’t care about desktop Linux, but Android uses the same font-drawing code). You might think that the font libraries at fontsquirrel.com or Google Web Fonts would have been checked for good rendering on all OSes, but it turns out Merriweather is available from both sites! So, while I’d still recommend starting with one of those libraries’ body-text fonts, it doesn’t get you out of testing.

(Note: Merriweather’s designer is aware that it looks terrible on Windows, and is working on it. Still, it seems to me that inclusion in public catalogs of fonts “designed for the web” was premature.)

All of these made-up types work because browsers don’t pay any attention to the content type of a web-embedded font; they look at the data stream, and if it’s recognizably a font, they use it. Such “sniffing” has historically caused serious problems—recall my old post regarding CSS data theft—so you might expect me to be waving red flags and arguing for the entire feature to be pulled until we can get a standard MIME category for fonts, standard subtypes for the common ones, and browsers to start ignoring fonts served with the wrong type. But I’m not. I have serious misgivings about the whole “the server-supplied Content-Type header is gospel truth, content sniffing is evil” thing, and I think the font situation makes a nice test case for moving away from that model a bit.

Content types are a security issue because many of the file formats used on the web are ambiguous. You can make a well-formed HTML document that is simultaneously a well-formed CSS style sheet or JavaScript program, and attackers can and have taken advantage of this. But this isn’t necessarily the case for fonts. The sfnt container and its compressed variants are self-describing, unambiguously identifiable binary formats. Browsers thoroughly validate fonts before using them (because an accidentally malformed font can break the OS’s text drawing code), and don’t allow them to do anything but provide glyphs for text. A good analogy is to images: browsers also completely ignore the server’s content-type header for anything sent down for an <img>, and that doesn’t cause security holes—because images are also in self-describing binary formats, are thoroughly validated before use, and can’t do anything but define the appearance of a rectangle on the screen. We do not need filtering on the metadata, because we have filtering on the data itself.

Nonetheless, there may be value in having a MIME label for fonts as opposed to other kinds of binary blobs. For instance, if the server doesn’t think the file it has is a font, shouldn’t it be able to convince the browser of that, regardless of whether the contents of the file are indistinguishable from a font? (Old hands may recognize this as one of the usual rationales for not promoting text/plain to text/html just because the HTTP response body happens to begin with <!DOCTYPE.) The current draft standard algorithm for content sniffing takes this attitude with images, recommending that browsers only treat HTTP responses as images if their declared content type is in the image/ category, but ignore the subtype and sniff for the actual image format. With that in mind, here’s my proposal: let’s standardize application/font as the MIME type for all fonts delivered over the Internet, regardless of their format. Browsers should use only fonts delivered with that MIME type, but should detect the actual format based on the contents of the response body.

I can think of two potential problems with this scheme. First, it would be good if browsers could tell servers (using the normal Accept: mechanism) which specific font formats they understand. Right now, it’s reasonable to insist that browsers should be able to handle either TrueType or PostScript glyph definitions, in either bare sfnt or compressed WOFF containers, and ignore the other possibilities, but that state won’t endure forever. SVG fonts might become useful someday (if those cans of worms can be resolved to everyone’s satisfaction), or someone might come up with a new binary font format that has genuine advantages over OpenType. I think this should probably be handled with accept parameters, for instance Accept: application/font;container=sfnt could mean “I understand all OpenType fonts but no others”. The other problem is, what if someone comes up with a font format that can’t reliably be distinguished from an OpenType font based on the file contents? Well, this is pretty darn unlikely, and we can put it into the RFC defining application/font that future font formats need to be distinguishable or else get their own MIME type. The sfnt container keeps its magic number (and several other things that ought to be in the file header) in the wrong place, but as long as all the other font formats that we care about put their magic number at the beginning of the file where it belongs, that’s not a problem.

¹ To be precise, there is a standard MIME type for a font format: RFC 3073 defines application/font-tdpfr for the Bitstream PFR font format, which nobody uses anymore, except possibly some proprietary television-related products. Bitstream appear to have been trying to get it used for web fonts back in the days of Netscape 4, and then to have given up on it, probably because the font foundries’ attitude was NO YOU CAN’T HAS LICENSE FOR WEBS until just last year.

In this article I’ll describe the attack, what we’re doing about it, how you can ensure that your site will continue to work, and how you can protect your users who have not upgraded their browsers yet.

The attack

In a traditional cross-site scripting (XSS) attack, the attacker finds a way to inject JavaScript code fragments into a web page that they can’t read. When a legitimate user of the targeted site loads the page, the attacker’s code executes. It might send information back to the attacker’s servers, or it might forge commands to the targeted site. CSS data theft also involves injecting strings into a page that the attacker can’t read, but this time, the strings are fragments of a style sheet.

The diagram above shows the course of a CSS data theft attack, from the perspective of a network hub that can see all the traffic. Before the attack begins, a victim user (the laptop in the middle) logs into their favorite website, Clockworks (mockup icon, on the right). Clockworks sends down a session cookie.

Some time later, while the victim is still logged into Clockworks, they click on an ad for dancing hamsters, and get sent to the attacker’s website (Badenov, on the left). The attacker’s website sends down an innocent-looking webpage that contains a <link> tag whose URL points to the victim’s private-messages page at Clockworks.

The victim’s browser duly requests the private-messages page from Clockworks; since the victim is still logged in, it sends the session cookie, so the reply will include information meant only for the victim. The query string, chosen by the attacker, causes Clockworks’ server to inject strings into the HTML on either side of an interesting piece of secret information.

Because the attacker’s website is being rendered in quirks mode, the victim’s browser ignores the Content-Type header and feeds HTML to the CSS parser. Of course, the very first HTML tag in the file causes a CSS syntax error, but CSS has predictable, lenient rules for recovering from syntax errors. The attacker’s injected strings make the CSS parser ignore most of the target page, and capture the secret as the value of the CSS background property.

Finally, since the background property applies to the body tag, the browser needs to download the image it specifies in order to render the attacker’s website. The image URL has been wrapped around the secret information that the attacker wants. So the browser sends that secret to the attacker’s server as a query string.

This attack has been known for some time. The earliest public description I have found was by GreyMagic Corporation in 2002. It has been rediscovered at least twice since then: by Matan Gillon in 2005, and by pseudonymous blogger ‘ofk’ in 2008 (article in Japanese). There are many variations, some of which no longer work, and some of which only work in IE. The variation I’ve described works everywhere that hasn’t deployed a defense; security researchers at CMU were able to use this attack to steal the contents of private messages from a bulletin board and two different webmail providers, with victims using unpatched versions of all the popular browsers.

Since the attack relies on the CSS parser’s error recovery behavior, sites may be immune because of accidental properties of their page structure. For instance, most browsers do not allow newlines in url() literals. If there had been a newline in the middle of the secret information in the diagram, just because that’s the way Clockworks generates its HTML, the attack would only work against victims using IE.

Browser-side defense

This attack works because a webpage in quirks mode can load anything as a style sheet, even if it’s really a HTML page coming from someone else’s server. If the attacker’s page were in standards mode, the browser would pay attention to the HTTP Content-Type header on the target page, declaring it not to be CSS, and refuse to load it as a style sheet.

The attacker, of course, controls whether their page is in quirks mode. But the attacker’s page is on a different server than the target page, which means the attack can be blocked by an extension of the same-origin policy. Even if a page is in quirks mode, it’s not allowed to load a style sheet with a Content-Type header declaring it to be something other than CSS, unless that sheet comes from the same origin. Firefox 4 will implement this rule, and IE has also adopted it (see below).

Unfortunately, there are a few websites out there that are rendered in quirks mode, and load their style sheets from a different origin, and put a Content-Type header on those style sheets that says they’re not CSS. These sites aren’t common—the aforementioned CMU security researchers found 62 in the Alexa top 100,000, and most of those have been fixed already—but Firefox 4 will break them.

To give folks more time to fix their sites, while blocking the attack as soon as possible, we implemented a more lenient rule in Firefox ≥3.5.11 and ≥3.6.7. If a page is in quirks mode, loads a style sheet cross-origin, and that sheet has the wrong Content-Type, we’ll start parsing it as CSS anyway … but we’ll stop and throw the sheet away if we encounter a syntax error before the first complete rule has been parsed. HTML tags cause CSS syntax errors, so unless the attacker can inject text at the very beginning of a page, they won’t be able to make the attack work. Safari, Google Chrome, and Opera have also adopted this rule.

It’s possible that this rule could break sites too. For instance, if a style sheet begins with an @-rule that Firefox 3.5 does not understand, that will count as a syntax error, and the sheet will be discarded.

UPDATE: August 28: The HTML5 spec for <link rel="stylesheet"> now requires the strict rule (see HTML5 defect report 9834).

UPDATE: October 26: As of Microsoft’s October 2010 cumulative security update, all maintained versions of Internet Explorer (6, 7, 8, and 9) now implement the strict rule.

Fixing your website

You only have to worry about your site being broken by the defense if you load your style sheets from a different server than the HTML and you use quirks mode. If your site works with a Firefox 4 beta, you’re fine. Current versions of Firefox 3.5 and 3.6 will warn you in the error console when they see a site that will break in Firefox 4, so you can also test that way. (Unfortunately, due to limitations of our translation process, part of this warning will always be in English.)

If your site breaks, all you have to do to fix it is make sure that your style sheets are being served with Content-Type: text/css in the HTTP headers. Please also consider switching to standards-mode rendering. If you cannot fix your website, we want to hear from you.

Protecting your users

If a browser tries to load a style sheet, and the HTTP response it gets has no Content-Type header, it will just assume that it has been sent some CSS, even if it’s a cross-origin load. Therefore, your users are not fully safe from the attack, even if they all have browsers with the defense, unless your servers put Content-Type headers on all content requiring authentication. Check your web services as well as human-readable content.

You should also make sure that those headers are correct. Most importantly, ensure that if your server can’t figure out what Content-Type to put on a response, it falls back to application/​octet-stream or text/​plain. Certain other possibilities (for instance, */* and application/​x-unknown-content-type) may be treated the same as if you hadn’t sent a Content-Type at all.

It is also vital to provide an accurate charset= option in your Content-Type headers for all textual data. If you don’t, an attacker can bypass your XSS filters by encoding injected strings in UTF-7. Declaring the charset in a meta tag or <?xml...?> instruction is not enough to defend against a CSS data theft attack encoded in UTF-7; the CSS parser doesn’t pay any attention to them.

To protect users that are still using browsers that have no defense against CSS data theft, you should block this attack in your filters for user-submitted content. All you have to do is add {, }, and @ to the set of characters that get replaced with equivalent HTML entities ({, }, and @, respectively). If you can’t be sure that you are always producing Content-Type headers with the correct charset= option, you should also entity-encode + to +.

More information

Chris Evans rediscovered this exploit in late 2009 and has been instrumental in getting it fixed. He has two other blog posts that go into more detail. Collin Jackson and his team at CMU have also been very helpful in understanding the full scope of the attack and ensuring all major browsers fixed it. Their paper will appear at the ACM Computer and Communications Security conference in October.

For technical details of the fixes, see Mozilla bug 524223, Chromium bug 9877, and Webkit bug 29820.

David Bolton wanted to know why some of the error screens asked the user to visit other sites manually, rather than doing checks behind the scenes. The main reason, honestly, is that that made a good example thing the user could do next. In practice we probably would want to do at least some checks in the background. Right now, another reason would be that error pages do not have “chrome” privileges so they can’t do anything of the sort (this is part of why the certificate error screen pops up a separate dialog box if you say you want to add an exception) but we may be able to get around that in a real implementation.

John Barton, in email, points out that SSL errors often come up in practice because of server-side configuration changes that ought to have been transparent to users, but a sysadmin goofed. I’ve been using the Certificate Patrol extension, which brings up warnings when a site’s cert changes in any way; this reveals that cert handling mistakes happen even on very popular and well-staffed sites (recently, for instance, mail.google.com flipped back and forth between its own cert and the generic *.google.com cert several times in one day). Of course that would have been invisible to most people, but it’s not much harder to make mistakes that do trigger warnings in a stock browser.

My general feeling on that is, yes, it is way too hard to administer an SSL-encrypted web site, and I would wholeheartedly support an initiative to make it easier, especially for sites that carry information of only moderate sensitivity (e.g. the plethora of Bugzilla instances with self-signed certs out there in the wild). I don’t think that should stop us from raising the visibility of SSL administration mistakes, as long as we improve the presentation and advice on those mistakes so we are not just training people to click through the errors.

John also points out that most people won’t have any idea what “Herdict” is or why they are trustworthy. The explicit mention of Herdict was mainly because I was riffing off Boriss’ earlier proposal to use Herdict information to improve page not found errors. Indeed, we should probably put it more like “Other people who try to visit this website get (something) which (is/isn’t) what you got.” We should credit whatever service we use for that information, but it doesn’t have to be as prominent as I made it.

Someone else (whose name I have lost; sorry, whoever you were!) pointed me at the Perspectives extension, which is said to do more or less exactly what I proposed, as far as comparing certificates seen by the user with those seen by “notaries” at other network locations. I like the use of the term “notary” and the proof of concept; unfortunately, Perspectives seems not to be actively maintained at the moment, and doesn’t work with Firefox 3.6. Also, for privacy, we want to make the queries to the notaries as uninformative as possible to an adversary that can observe network traffic. Reusing the same system that is used for “is this site down?” requests would help there. (Ideally, the notaries would also be unable to tell which users are asking what about which sites, but that might not be tractable.)

Small conference rooms (memes)

• All your base
• Bike shed (used as a storage area for a while)
• Chuck Norris
• Dancing Baby
• End of the World
• Fail
• Get to da choppa
• Hampster Dance
• Icanhascheezburger
• Jibjab
• Keyboard Cat
• Leeroy Jenkins
• Mullets Galore
• Numa Numa
• Orly
• Peanut butter jelly
• QQ
• Rickroll
• Strong Bad
• Tron Guy
• Ultimate
• Very good, very mighty
• Win
• Xiao Xiao
• Yatta
• Zombocom

Large conference rooms (Star Trek)

• 10 Forward (break room)
• Holodeck
• The Bridge
• Warp core

This is a big block of jargon which doesn’t do anything to tell the user how big the risk actually is, or help them distinguish a minor problem from a major one. If you click on “technical details” you get a little bit more information about what went wrong, but it still doesn’t make any effort to give advice.

The Firefox UI team has been talking about using Herdict or a similar service to improve network error screens, especially the site not found screen. I think we could get a lot of mileage out of that for SSL errors as well. We should also make use of the user’s history with the site, and pay attention to what exactly is wrong with the credential. Here are some examples.

The only problem with self-signed certificates is they haven’t been signed by a trusted third party. The connection is secure, but you might not be talking to who you think you are. In the first section, we emphasize that the concern here is with identity, and we use Herdict information to deduce that this is probably not a hijacked site, because lots of people get the same credential. (“The same credential” means exactly the same, not just some self-signed cert, but we needn’t bother people with that unless they want to see the details.)

In the “What should I do?” section, we give some examples of things that might be unsafe to trust this site with, but we go ahead and let them visit the site, automatically storing the self-signed cert and marking it valid for this site only. We implement bug 251407, so we can promise to notify the user if the site’s credentials change in the future.

I’ve front-loaded the information that used to be in the “technical details” section, so it has been replaced with “Inspect the Credentials”. If you open that area up, it shows the certificate, but in a more user-friendly way than the existing certificate dialog box does. Especially important here is to reveal the interesting parts immediately, highlight suspicious things, and deemphasize the jargon and the long hexadecimal numbers.

“I understand the risks” is still there, but in this case, it’s for people who didn’t read the rest of the page. It’s meant to make people stop, slow down, and reread. If you click on it you get another link to the page.

There are exploits in the wild that take over your WiFi hub, or your cable modem. Once they’ve done that, they are in a position to tamper with all your Internet traffic. I ran into one of these for reals last week; I was in a café and getting certificate errors on every secure site I tried to visit, including Mozilla’s mail server. (The theory is that you’ll just click through the error messages because you want to get your email, or whatever; one of the staff at the café did just that when I complained.) Here’s where Herdict could really come in handy: if you are getting certificate errors but nobody else is, we can deduce a problem near your computer.

Again, the first section tries to be clear and specific about the problem: we suspect that someone is tampering with your Internet connection, and here is why. The second section underlines how big a deal this is: “Do not log into any site or buy anything online.” It then suggests a test: visit another secure website and see if the problem persists. This scenario should put the whole browser into a paranoid mode, where it will not load saved passwords and continues to try to work out whether there’s something wrong with the local router. Ultimately, we should advise people in this boat to factory-reset their WiFi hub and/or contact their ISP for help, but we should take care to be certain in our diagnosis first.

In this scenario, the “I understand the risks” section gives you access to the certificate-exception dialogs, as it does now.

Finally, here’s what it looks like in the comparatively rare scenario that SSL certificates were originally intended to defend against: the server has been hijacked (but the attackers do not have access to the cert). We can tell from browser history that the cert has changed, and we can tell from Herdict that it has changed for everyone. We tell the user not to visit this website, and again, suggest trying another secure site. (We need to take care to distinguish this case from an expired or legitimately changed cert.)

The CSS 3 Backgrounds and Borders module introduces the border-radius property, which allows you to make the border of any CSS box be a rounded rectangle. Mozilla’s Gecko-based browsers (such as Firefox and SeaMonkey) have implemented parts of this feature for some time, as have Webkit-based browsers (such as Safari and Chrome). Firefox 3.5 adds support for elliptical corners, and brings the Gecko implementation into line with the standard on many details.

At the time of writing, the Backgrounds and Borders module is still a W3C Working Draft, so all the browsers that implement border-radius require you to use vendor-prefixed property names for it. This article uses the standard property names in all examples, but there is a table of equivalences at the end. Mozilla’s policy is to enable the standard names once the module reaches Candidate Recommendation stage; see bug 451134.

Introduction to rounded corners

CSS source	In your browser	Proper rendering
width: 48px; height: 48px; border: 1px solid black; border-radius: 10px;
border-radius: 10px 0px;
border-radius: 10px 0px 20px;
border-radius: 10px 0px 20px 30px;
border-top-left-radius: 20px 30px;
border-radius: 10px 0 / 30px 0;
border-radius: 10px / 30px 30px 10px 10px;

In its simplest form, border-radius takes a single CSS <length> and rounds all four corners of a box border by that amount. Rounded corners are never inherited by descendant boxes.

If you want the corners to have different sizes, you can list up to four <length>s; these round individual corners, counting clockwise from the top left. With two or three numbers, the missing values default to the value for the diagonally opposite corner.

You can also use longhand properties to control the curvature of each corner independently from the others: border-top-left-radius, border-top-right-radius, border-bottom-right-radius, and border-bottom-left-radius. Each takes a single <length>. There is no defaulting from one corner to another with these properties.

The Backgrounds module adds the possibility of elliptical corners. If you’re using the longhand properties, you simply add a second <length> value to the property; the first value sets the horizontal semi-axis of the ellipse, the second sets the vertical semi-axis. With the shorthand border-radius property, the notation is slightly more involved: after the first list of up to four <length>s, you add a forward slash and another list of up to four <length>s. The values before the slash set the horizontal semi-axes, and the values after set the vertical semi-axes; both go clockwise from top left, and default independently to diagonally opposite corners. If either semi-axis of a corner is zero, that corner will not be rounded.

Webkit does not treat border-radius as a shorthand property; it accepts only one <length> value. If you want any effect other than setting all four corners to the same circular radius, you must use the longhand properties with Webkit. See bug 23675.

Corner styling in detail

Constant thickness	Varying thickness	Sharp inner corner

The border-radius properties directly control the horizontal and vertical semi-axes of the outer curve of the border. The inner curve is determined by reducing each semi-axis by the thickness of the side border adjacent to that end of the curve. This keeps the curved portion of the border within a rectangle whose sides are the semi-axes set by border-radius.

border: 6px solid black;
border-radius: 8px / 20px;

border-style: double;

When both sides’ borders are the same thickness, the curve has constant thickness; when they are not the same, the curved portion of the border interpolates smoothly between the two. When the border is at least as thick as the border-radius value on at least one side, the inner curve becomes a sharp corner. Thick elliptical borders sometimes look kinked because the inner curve is very flat.

CSS source	In your browser	Proper rendering
width: 48px; height: 48px; border: 1px solid black; border-radius: 25px 0;
border-radius: 40px 0;
border-radius: 50px 0;
border-radius: 40px 10px 10px 10px;
border-radius: 50px 10px 10px 10px;
border-radius:100px 10px 10px 10px;

When the curves are too big for the box, something has to give. The Backgrounds module constrains the sum of the semi-axes on each side of the box to be no more than the outer dimension of the border box on that side; thus you can make one corner curve all the way to the opposite side of the box, as long as both corners adjacent to it are not curved at all. When the sum is too big on even one side, the renderer is required to compute a reduction factor that will make the largest pair of semi-axes fit exactly within the box, and apply that reduction to all the semi-axes. This has advantages and disadvantages; in the spec’s words,

This [rule] ensures that quarter circles remain quarter circles and large [corners] remain larger than smaller ones, but it may reduce corners that were already small enough, which may make borders of nearby elements that should look the same look different.

At time of writing, this rule is implemented in full only by Firefox 3.5 and very recent versions of Webkit (library version 1.1.8 and later; see bug 8736). Older Gecko-based browsers scale each arc independently, and limit each corner to half the outer dimensions of the border box. Older Webkit-based browsers ignore all the corner radii for a box if the sum of the semi-axes on any side is greater than the outer dimension of the border box on that side.

Transitions

Color and style transitions	In your browser	Ideal rendering
border-radius: 20px; border: 4px solid; border-color: red green blue gray;
border: 6px black; border-style: solid solid double double;

The Backgrounds module leaves the visual appearance of a transition between border colors and/or border styles undefined, but does require that they take place entirely within the curved region of the border. It does, however, recommend the use of a gradient for transitions involving color only.

Both Gecko- and Webkit-based browsers currently implement all such transitions as abrupt, occurring at the diagonal of the rectangle that encloses the corner curve. This may change in the future, at least for color transitions; see bug 483696 for Gecko.

Borders that are not solid

Dotted and dashed corners	In your browser	Ideal rendering
border-width: 2px; border-radius: 15px; border-style: dotted;
border-style: dashed;

In terms of what gets drawn on the screen, inset and outset borders are the same as solid borders that aren’t the same color all the way around, so they are also affected the same way by border-radius. Double, groove, and ridge borders are drawn with two or three stripes within the border thickness. The arc-reduction rule described above is applied to each stripe; this can exaggerate the apparent kink when the innermost arc is too flat, but otherwise works well.

For dotted and dashed borders, the dots or dashes are supposed to continue through the corner curve. Gecko-based browsers don’t implement this at all; the curved portions of the border are drawn as solid (bug 382721). Webkit draws dots and dashes along the curves, but may show artifacts at the ends of the curves.

Clipping of background and content

Clipping	In your browser	Proper rendering
border-radius: 15px; border: none; overflow: visible;
overflow: hidden;

Both colored and image backgrounds are clipped to the curved border. This happens even if there is no visible border (with border-style: none, for instance). A border-image is not clipped, but backgrounds are still clipped to the curve, even though in the presence of border-image the regular border is not drawn.

Content is, by default, not clipped at all. If you use overflow:hidden, however, the Backgrounds module requires content to be clipped to the border curve. This works with very recent Webkit (partially, bug 9543) but not Gecko (bug 459144). or older versions of Webkit.

The spec says The UA may reduce or treat as zero the border-radius for a given corner if a scrolling mechanism is present in that corner. In other words, if there are scrollbars (overflow:scroll or overflow:auto), corners on the sides that actually have scrollbars may not be rounded. This is because the scrollbars themselves obviously should not be clipped, and the visual inconsistency was expected to be undesirable in at least some cases.

By default, the clipping path is the outer rounded rectangle; thus, the background will show under the border if the border is not fully opaque. (This is visible in several of the examples above.) The Backgrounds module includes a background-clip property that can change this. Gecko and Webkit both include partial support for this property, but they conform to an older revision of the spec: the value keywords are border and padding instead of border-box and padding-box; content-box and no-clip are not supported.

Browser compatibility matrix

Attention conservation notice: thousand-word rant about the user friendliness of a bug database.

I, a developer, frequently have trouble figuring out which component I ought to file a bug under, especially when it’s not in one of the areas I work on—which is when it’s most important for me to get it right, so that it comes to the attention of people who do work on that area. It doesn’t help that, for any given bug, I might be supposed to file it under Firefox or under Core, each of which has a dauntingly long list that you have to scroll through via a five-line selection box. (I was hoping that the 3.2 upgrade would at least give me a bigger box, but it didn’t; showing the descriptions is nice but often the descriptions are just as cryptic to me as the names themselves.)

I happened to be complaining about this last night and my SO, who is a web designer, said that she’d completely given up on reporting bugs to us because she had no idea what product and component to select, and the new-bug form gave the impression that if you didn’t get that right you might as well not bother filing the bug at all! —She now has me proxy bug reports for her, which is fine and all but doesn’t scale. And if someone who already knows HTML from CSS from JavaScript and the difference between Firefox and Gecko can’t figure out how to label her bug reports, how can we possibly expect less informed users to?

So I think the user-facing problem—the product+component space is too big and daunting—is more serious than the possibility that QA won’t scale to handle increased triage responsibilities. If MozCo needs to hire some (more?) people whose entire job is to triage bugs, well, I have the impression there’s room in the budget for that.

Now, the component list isn’t the only daunting thing about the new-bug form. I’m looking at it now, and to get to the important part—the description-of-bug box—I have to scroll past an entire screenful of form fields. And I have a huge monitor. And I know that most of the time I can leave all those fields blank. The “bugzilla helper” is even worse; the first thing you see is a giant confusing table of already-filed bugs. I appreciate the attempt to reduce the number of dupes but I’d bet a dollar that lots of users see that and give up without even reading it!

Oh, and halfway down the bugzilla helper it tells you to report broken websites a totally different way. It’s good that we have a guided wizard built into firefox for that–but it’s very bad to let someone get halfway down the page before telling them, no, wait, stop, do something totally different! It’s also bad to demand that the user go try the latest development version before they do anything else, and for the first thing they see when they open the wizard (presumably first time only, but still) to be a minuscule box containing over a thousand words of legalese.

I think we could make life easier for both users and QA by doing some serious user interface redesign on the new bug forms. I’m imagining a directed question-and-answer session with no more than seven (plus or minus two) options at each stage, eventually leading up to one or two freeform entry boxes. The goal of this would be to do a rough-cut categorization that makes less work for human triagers, and at the same time tries to get enough information out of the user that we don’t need to go back for more. It should be clear to people unfamiliar with the terms, but not insulting to experienced users; I think if we do it right it would be easier for everyone than the current form.

For developers it might be good to have a special mode for when you’re filing a bug to describe a specific chunk of work that’s already planned. This could do things like deduce the correct component and suggest reviewers/cc: subscribers from file names or bug numbers mentioned in the description, or even in the patch that you’re attaching as you file the bug.

This is getting pretty far offtopic, but I’d also like to bring up a pet peeve of mine: I don’t think we should ever tell people to stop commenting on a bug. I do realize that when there are widely-cc:ed, widely-commented-on, long-standing, not-gonna-be-fixed-soon bugs, it’s no fun to be on the receiving end of all that mail, and the me-toos can obscure any actual technical discussion that might get the bug solved. Too often, though, I see that turning into hostility to users. A “leave us alone” response to a “hey this is still a problem for me” comment is a great way to ensure that that person never reports a bug again.

I think there ought to be a way for a bug to host a deeply technical conversation about how to fix it and a long train of me-toos at the same time, but I don’t have any great ideas, probably because I read too fast for it to be a serious problem for me.