Language Coverage – Version 1.1

I have released an updated version of my language coverage data – its home is now a web page rather than a blog post.

Among the new features are:

  • Several bug fixes and data improvements; the Firefox percentages have gone up but, sadly, so have the IE ones.
  • Information on Opera.
  • A new line showing how IE fares if you don’t include LIPs.
  • A new line for “registered l10n teams”
  • A tab which shows that if a browser team were using this data to guide where to put l10n team effort, what languages they should be focussing on. This data is provided for Firefox, IE and Opera.

Thank you to everyone who gave me useful feedback. Please let me know of any further improvements I could make, within the general parameters of the method.

No JS/No CSS Browser Detection

[Browser detection removed as it broke the validation of my RSS feed. Check the author's site if you want to try it out.]

This browser detection uses pure HTML 2.0, without any JS or CSS. Here’s how it’s done. It even distinguishes Firefox 1.5 from Firefox 2. Can any parser hackers extend it to further distinguish Firefox 3?

Anchor Markers

We’ve had a bug open for quite a long time about implementing the W3C Common User Agent Problems recommendation from 2001 to highlight the target of intra-page named anchors.

Someone recently posted their ideas in that bug; I don’t think much of their UI, but I think it would be great if Firefox had a solution for this. (It would be nice also to style internal links slightly differently, perhaps with a dotted underline, so people don’t do “Open In New Tab”, and end up with five copies of the same large page.)

Is there an extension which does this? If not, does anyone feel like knocking one up?

One implementation method would be to highlight and then fade out the elements contained in the <a name=”"> tag. However, this might not work everywhere because of the following pattern:

<a name=”heading”></a>
<h3>Heading</h3>

People do this a) to make sure the heading is visible on the page, and b) because people used to write bad CSS which caused hover effects to apply to anything within an <a> tag, whether it had an href or not. But maybe this problem isn’t a showstopper.

Only Browser Geeks Need Apply…

The Alliance and Leicester Building Society’s “3D Secure” secure internet shopping service has the following requirements:

What are the system requirements for 3D Secure?

3D Secure requires the use of Windows Microsoft® Internet Explorer 5.5 and 6.0, Windows Netscape® 7.1 and 7.2, Windows AOL ® 9, Windows Firefox® 1.0 and Macintosh Safari®.

Wow. It’s a pretty small and exclusive clientele who can run all of those at once. I guess you’d need a Mac (for Safari) running at least two copies of Parallels (one for each version of IE)…

Styling Internal Anchors

Ever seen an interesting link on a large page, middle-clicked it to open it in a new tab and then realised that it was an internal anchor, and you are just loading another copy of the same large page?

To have every internal anchor marked with a small “#” symbol after it, add the following to your userContent.css:

a[href^="#"] {
padding-right: 6px;
background: url("data:image/png,%89PNG%0D%0A%1A%0A%00%00%00%0DIHDR%00%00%00%06\
%00%00%00%08%08%06%00%00%00%DA%C6%8E8%00%00%00%09pHYs%00%00\
%0B%13%00%00%0B%13%01%00%9A%9C%18%00%00%00%07tIME%07%D7%03\
%1D%10%0D*T%0FgN%00%00%00!IDAT%08%D7c%F8%0F%05%0C%0C%0C%A84\
%8C%83%81A%12%BF%FF%FE%23Q%07N%3B%B0%01%D2%25%00N4%8Fj%C7U\
%97%89%00%00%00%00IEND%AEB%60%82") center right no-repeat;
}

IE Plays Catchup

Is it just me, or could the “IE Add-ons Contest” have been renamed the “IE Add-the-features-Firefox-has-that-we-don’t Contest”? Of the four top addons, three implement Firefox features for IE. And the last is an extension we had first.

Even the description page for the grand prize winner admits as much:

Inline Search is an add-on for Internet Explorer that mimics Firefox’s search behavior…

Imitation is the sincerest form of flattery :-)

IE 7 Cripples IDN

Microsoft’s policy about how IE 7 will handle IDNs has changed slightly in beta 3, but unfortunately as it stands will still have a serious detrimental effect on IDN take-up. Here’s why.

IE 7 displays all IDN domain names as punycode (e.g. http://www.xn--caf-hya.com), unless the copy of IE has the “language” of that domain name configured as one of its Accept Languages.[0] If it displays the ugly and indecipherable punycode, it also presents a yellow security bar, saying “We can’t display this domain name; click for options”, where presumably the user might have the option of adding to the whitelist whatever language IE thinks the domain name is in.

This will cripple IDNs in almost any international market, simply because domain owners are not going to want an unknown percentage of users visiting their domain to have that horrible user experience. You are a German company – will you choose an IDN domain name containing a ß as your primary domain name if you know you might one day want to expand into the European market and sell goods outside Germany? And that almost all your European customers will have to go through this?

IDNs might be perhaps used when the site owner can guarantee that all their visitors will have a particular language configured – but how common is that? Even aside from the situation above, this is the “World Wide” Web, and people use the browser of a friend, or an Internet café. The browser doesn’t really know what languages its user speaks, and it’s unlikely that the user will take time to tell it. When was the last time you configured the Acceptable Languages in a browser you were using? And if you did, when you stopped using that browser, did you remove them and reset the setting?

The sad thing is that this measure by itself doesn’t improve security. A particular domain name is either dangerous or it isn’t – that is, it’s either a homograph of another domain registered to a different person, or it isn’t. If the domain name is a homograph then all those people who, by default or by configuration, have that language configured are at risk. And if it’s not a homograph, why not display it to everyone from the start?

The other measure IE 7 is taking, which is to forbid most script mixing, will improve security. But here they have gone the other way – this measure is too draconian. Script-mixing by itself is not dangerous, as long as your registry is on the ball.

Firefox has a system based on a whitelist of TLDs whose registries have sensible anti-homograph policies. Only they can tell if a domain name is dangerous or not; browsers just don’t have enough information. Our policy allows many more safe domain names.

Unfortunately, as domain owners will only pick names which work everywhere, IE 7 is further restricting the set of names that can be used in practice. Having worked for a long time on making IDN safe and usable in browsers, it’s very sad to see its uptake stunted in this way. :-( I hope they change their minds and remove that first check, but I fear it’s too late.

[0] There will also be a host of problems caused by the fact that domain names use characters from particular scripts, or perhaps multiple scripts, and IE has a list of languages. Languages and scripts have a really complex relationship – in which language is the letter é? What Accept Language do I have to have configured to correctly view www.café.com? I haven’t covered this further because it’s secondary to the even bigger problem mentioned above.

IE 7′s Effect On Firefox Market Share

rebron’s IE 7 Competitive Analysis is worth a read. I’m glad that printing has been picked out as an area where Firefox needs future work.

It’s nice to think, as rebron suggests, that IE 7 won’t take away share from Firefox. Perhaps it won’t by converting users back directly. But it could have indirect effects; where today, if people get a new computer with IE 6, they think “Ick! Install Firefox now!”, if it comes with IE 7, they may just live with it. Also, people often install Firefox for their relatives or friends – will they be as eager to do so when the feature/usability gap is smaller?

I guess the answer to that is, let’s keep that gap wide :-)

HTTPOnly For Firefox – Sort Of

IE implements a non-standard feature called HTTPOnly, which allows cookies to be set such that they are only sent back to the webserver, and are not available via JS. This mitigates cookie stealing using XSS.

Firefox hasn’t got it yet; we’re a bit held up by our legacy cookie “database” format, cookies.txt. However, Stefano Di Paola has come up with a way to implement the same feature, using the hackability of the Firefox JS engine.

Put the following line of code at the top of the first bit of JavaScript your page runs:

HTMLDocument.prototype.__defineGetter__(“cookie”,function (){return null;});

and, as long as the XSS injection hole is further down the page, cookie access from script will be impossible.

“</scr” + “ipt>”

Everyone knows that you can’t use the literal text “</script>” inside a <script> block, because the web browser will interpret it as the end of the block. But do you understand why it was designed that way, or do you think it is just a bug that no-one has got around to fixing yet?

Raymond Chen has the lowdown.

Carefully Tuned User Irritation

Yngve has an interesting post about how to deal with the problem of banks etc. doing login by submitting from an insecure to a secure page.

The aim is not to protect each user’s form submission when using the broken page; the aim must be to get the bank to fix the site. So we need to change the browser to inconvenience the bank’s customers enough that they complain to the bank, but not enough that they try and change browsers to one which does not have this “feature”. In other words, we need to carefully tune the level of user irritation ;-)

So how can you inconvenience the users? One option is Yngve’s popup on submission; make the users press a big button marked “Submit Insecure Data”. That should cause a few panicky calls to the bank’s tech support line. Another option would be to delay the rendering of the next page by five seconds or so, while displaying some sort of warning in the blank space; banks like their sites to be snappy, and they don’t like worried customers.

If we are going to make browser changes, we’d need to do it in a synced up fashion, so people didn’t simply reduce their security by switching browser provider.

One last option would be to sponsor a 3rd party “major banks security assessment”, which took in details like this, the format of emails they sent out, whether they used third parties for email delivery, and so on. Publicise the results, and try and shame the lagging banks into compliance.

SSL Changes In Opera 9

Yngve Pettersen of Opera has posted about the changes they are making to SSL in Opera 9, including disabling SSL 2, introducing TLS 1.1 with some useful extensions, and warning on weak ciphers.

Galeon To Become Epiphany + Extensions

The Galeon project has announced that they and Epiphany are now close enough that the extra features that Galeon provides can be implemented as Epiphany extensions, and so plan to move forward in that direction. They feel that this way would mean much less duplication of effort.

It’s not an easy thing to make such a decision – pride often keeps “my pet project” going for much longer than it should – and so I applaud the Galeon developers, and hope that the resulting browser(s) become better than the sum of the parts.