While mozilla does correctly convert hostnames (but not the rest of the url) to lowercase before resolving them and before displaying them in the URL bar (even after someone types a url containing caps into the URL bar), it displays the characters 'I' and 'l' in exactly the same way. This is bad, because it allows for spoofing. Consider: http://www.geocities.com/~mIRC/ (legitamate) http://www.geocities.com/~mlRC/ (bogus) Usage as an exploit: grab that geocties address, make it look like the real mIRC site, but the ftp download locations so that the download includes a trojan. Then spam IRC users with the URL of another webpage containing mostly porn, but also containing the message: mIRC [current version] has a huge security hole that can be exploited remotely! Go get <a href="http://www.geocities.com/~mlRC/">mIRC [current version + 0.01]</a> now before someone hAx0rs your box! The correct solution to this problem is not lower-casing the entire URL, because some websites are case sensitive. For example: http://www.angelfire.com/ne/LYLee/ (my friend's site) http://www.angelfire.com/ne/lylee/ (a second site he registered later) Microsoft Internet Explorer gives a partial solution to the 'I' != 'l' problem: displaying an extra pixel of space after an 'I'. I don't consider Microsoft's solution to be complete because: - It's not completely obvious (my guess is that 30% of people would notice unless looking for the difference) - The extra pixel much more obvious for http://www.moziIIa.org/ (bad example, because it's in a hostname, but paste URL into location bar to see effect) than it is for http://www.geocities.com/~mlRC/ . I suggest that mozilla display 'I' as it does in other fonts, with horizontal bars at the top and bottom, so that it looks different from 'l'.

Forwarding to UI.

This is an unfortunate side-effect of selecting a sans serif font for the default. IE's "solution" is more likely a product of slight differences in the way kerning, etc. is handled. Netscape appears to use a more uniform 1-pixel- space for each character. Either way, the single pixel difference between IE and Netscape isn't going to protect more than a few people from the spoof described here. If whomever is handling text rendering wants to tweak the kerning code, feel free; otherwise, I'd rank this pretty low both as a priority and as a security risk. (The only real solution to the spoofing would be to switch to a font in which the 'I' and 'l' glyphs are not so similar; changing the kerning will just make it look a little nicer.)

marking helpwanted and reasigning

Sorry for the spam. New QA Contact for Browser General. Thanks for your help Joseph (good luck with the new job) and welcome aboard Doron Rosenberg

This is a per-skin bug, since the skin can decide the font to use. (Right?)

Moving from browser-general to security and cc'ing mstoltz.

This no longer appears to be the case with the modern skin at least. When I type in multiple I's in the location bar there is a noticable space difference between that and multible L's. It appears to be the case for all capital letters in the font we've chosen. While this isn't the best solution, it is one. Jesse, could you look at this again and decide whether this is fixed to your liking.

QNX Mozilla build from this week w/ classic skin, the i and the l have slightly different vertical lengths in the urlbar. specifically, IRl is a sorted ascending list (1px difference between adjacent chars) of the three chars (capital-eye, capital-are, lower-elle).

Can this be set to INVALID then?

WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031222 modern skin Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040108 Firebird/0.8.0+ (MozJF) default firebird skin (qute)

v

shouldn't this be tested with the classic skin as well, before it's marked WFM?

WFM with classic skin too.