<sigh> Kieren McCarthy, whose work I normally appreciate, has sounded off on the IDN issue in The Register without doing any research. The following is the letter I sent him, which I'm reproducing here in case anyone else is under any of the same misapprehensions.
FWIW, the three documents his article mentions, which were released by the registrar community, are also ill-informed in thinking we've disabled IDNs. This points to a communications failure that we should try and do something about. More on this when I've caught up on the 200-odd mails I have in my Inbox on the subject. (Irony noted.)
Sorry, Kieren, but much as I generally admire your work, 0 marks out of 10 for doing your research on this one. We haven't disabled IDNs, as the follow-up post in my blog (or, heaven forbid, actually downloading the code and trying it) would have told you. All IDN domains in Firefox 1.0.1 and Mozilla 1.8b1 display in their punycode form. Given the timescales we had for releasing the 1.0.1 security update, this was the best solution we could come up with which dealt with the problem, but as we've made quite clear, it's a temporary one only.Paul Hoffmann, your "knowledgeable expert" you deployed to patronize us by proxy, may be an expert on IDNs, but he's not an expert on browser or security UI design. Neither am I, but I know enough to tell him that his idea wouldn't fly, and I did. The other two documents you link to are in fact guidelines for registries to implement to protect users - in fact, some of the very "ICANN guidelines" I mentioned. So, quoting them as an "everyone else disagrees" measure would rather suggest you hadn't actually read them.
As for mozilla.org being parochial, it seems that I spend half my time answering well-meaning people who put forward ridiculous suggestions about how IDN domains can be "flagged" or "warned against" (Mr Hoffman included) when in fact our goal is to make them first-class domain names in the browser, alongside and equal with traditional domains. This thinking is laid out in my paper "A Plan For Scams" which I also wrote and blogged about recently.
So, just to set everything straight:
- We haven't disabled IDNs, just made them ugly in the short term.
- We are getting together with the other browser and plugin manufacturers, the registry groups, some registrars, the IDN people and the Unicode people to sort something out that'll work in the long term. Don't worry - when we have, you'll be the first to know :-)
Gerv
Update 9.42am: Don't write emails quickly when in need of sleep. While most of the content above is right (having fixed some typos), as a kind friend has pointed out, the tone is not. I apologise to Kieren for sending him something so ill-considered.
Also, I didn't mean to count Mr Hoffmann's remarks among the "ridiculous" ones I've seen, only among those which recommended warning against IDNs in some way. So apologies to him, too.
Update 11.54am: and I can't even spell his name right. Thanks to Smylers for spotting this one.
I'm off to FOSDEM, giving a couple of talks (on the MoFo and Bugzilla) in the Mozilla Developers Room, and hopefully meeting a lot of European Mozilla hackers. Hope to see you there :-)
OK, here's a technical problem to solve. I've been chatting with one of the administrators of a very large website (if you guess, keep it to yourself) which, as part of its function, displays user-provided content in the middle of site-provided pages. For historical reasons, the user-provided content needs to allow scripts, Flash and other dynamic content. However, they want to prevent such content affecting "their" part of the page, above and below the user content, and performing malicious actions. Currently, this can be done using either script or CSS-positioning or both.
I suggested that in general, their problem was unsolvable, but that the industrial-strength way of getting such separation was to use an <iframe>. He told me that they'd tried that, but as scrollbars internal to the page were unacceptable, they'd had to try resizing the iframe dynamically using JS to eliminate the bars. This solution had run into technical difficulties, as explained in the following saga, some of which I don't quite follow.
Read it for background if you think it helps - but the question is: how hard would it be to get an <iframe> or <object> which always resized to its content? The solution can involve either JavaScript, or hacking Gecko.
Currently in Gecko, as far as I can tell, if you don't set a width and a height, <object> tags of type e.g. image/png size to their content. So why can't (or why don't) <object> tags of type text/html?
Here's the story:
Here was the general process under which we went through to implement iframes:The Problem: The users enter malicious content on the page that can overwrite our page content as well as steal cookies since it's in the same domain.
Our proposed solution: We want to separate the user data on the page from our site content. The most esthetically clean way to do this was inside of an iframe that is automatically resized to avoid having embedded scrollbars which our user community would never be okay with.
How it was implemented: We wrapped the content inside of JavaScript to detect the vertical height of the page and then render the iframe appropriately to avoid any scrollbars inside the page itself. When we tried to roll this out we encountered massive problems.
- Any items with links, when clicked on only redirected the main page. We solved this issue for the most part, except for Applets, objects, etc... We would be willing to take this hit and force our developer community to change their code to support this. This is somewhere around 10-30% (the number is hard to calculate since it isn't a part of the page, it's a part of the code hosted elsewhere).
- Tables rendered badly. This ended up being the show-stopper. Users would put dozens of large images into tables and wouldn't put sizes on the images. This would cause the page to sit there for minutes in some cases because the table wouldn't finish loading so our JavaScript wouldn't render the entire table until every last image were loaded. So next we attempted to change it so that every image pre-loaded as a 1x1 pixel image. That worked okay, but the only way to do that was to wrap the entire user's content in <noscript> tags. The problem with that was that once we encountered an end </noscript> tag it would start rendering again. IE:
<noscript>
User content
<script>
//Some javascript
</script>
<noscript>
You don't support JS
</noscript> <--- at this point it breaks our <noscript> block
More user content with tables, etc which breaks our code...
</noscript>At the time <noscript> was found on 22% of user input. Now it is closer to 2-3% due to some changes we have made, although that number is still too high to implement this solution. The users would also do really bizarre things with their code like have weirdly malformed tables, and JavaScript that outputted </noscript> tags. The fact that there was no way to completely stop text from rendering so that we could pause it and run JS over the code made this approach unfeasible after months of testing.
- It broke save-as in IE, which we don't care about that much, but it was a big deal in certain countries, as users really like to save data to their desktops to prove that they saw it and agreed to whatever was said on the page. We can get around this issue by allowing a save-as friendly version that can only be linked to from our own page, but it's less than ideal.
- Certain forms of popups still allowed some forms of overwriting (both Netscape and IE verified - although SP2 has fixed some of these issues since that time).
- When users resized during render time it became an issue because of the weird way in which the JS was written... it would be making assumptions about a size that was no longer accurate.
- It caused JS errors with pages that attempted to resize themselves.
- Browser support - with iframes and JS required for this to work it only supported ~90% of browsers.
Based on our discussion the right idea would be to have a different form of iframe that resizes to the size of the page it is calling to avoid the embedded scrollbar issue. If we could make this a standard we might even be able to get higher than the ~90% we found in #7 of the problems list.
I've just discovered RMS's blog. For a man who explains things verbally so well, and who writes great essays, he has a very stilted style in day-to-day blogging. Each pair of sentences are exactly the same mental distance apart, and it's a fairly short distance. The combined effect is like reading through treacle.
I've discovered an interesting HTML parsing foible. HTML entities, such as &, are used to encode special and extended characters in HTML. But, as web page authors are sloppy, both IE and Firefox attempt to "do the right thing" when faced with unterminated (no semicolon) HTML entities like:
"I used Sun's java compiler"
However, if HTML sanitisers don't do exactly the same thing when decoding, you may be able to slip some script past them. So, for example:
<img src="javascript:alert('Oops');">
could be the name of a valid image on the webserver. However, IE and Firefox will decode it to:
<img src="javascript:alert('Oops');">
IE executes the JavaScript immediately; you need to do a View Image for Firefox to (not sure why). Perhaps this isn't a big deal, but I have no idea whether any commonly-used HTML sanitisers would fall for this one...
In the Matter of Component Architecture is a fantastic piece on the value of code reuse which appears to have been written merely as an email to a mailing list.
Software as it is currently being developed provides so much value relative to its costs that we as practitioners of this medieval-class craft can get away with practices that would not be tolerated by a Taiwanese manufacturer of toasters.
I've written a spec for Firefox's anti-phishing features, in the form of a document which explains to the user how they can stay safe from phishing using Firefox.
Staying Safe From Phishing With Firefox.
The idea is that the statement represents the minimum work we need to educate users to do to stay safe, and that Firefox's anti-phishing features should be designed in such a way as to always make that statement true. There's a discussion page which talks about this in more depth.
I'd be very interested in feedback of the following forms:
There's been rather a lot going on recently, and I just noticed that I didn't post an update on the results of the biopsy they did after my mouth operation.
It turns out that the lump they took out from the floor of my mouth contained the primary site, or most of it, for the cancer I had back in 2001. I have a cancer called Adenoid Cystic Carcinoma (ACC), a slow-growing salivary-gland cancer with a tendency to spread along nerves.
Obviously, removing the primary is a step forward. However, as they didn't get it all, I need to have a further operation to remove the rest. This will probably create a larger hole than can just be sewn together, so they intend to fill it with a lump taken out of my upper leg. (In the past, it has been remarked that I'm rather prone to foot-in-mouth disease; I didn't expect I'd prove everyone right in quite such a literal way...) This operation is scheduled for April 13th. The primary risk is probably nerve damage - I've already lost feeling in part of my tongue as a result of the initial procedure.
I also have between one and four, depending on how pessimistic you are, metastatic nodes in my lungs. These can only be removed when they are big enough for the surgeon to feel, which should be in about 12 months.
Survival rates for ACC are, according to one website, 89% at five years but 40% at fifteen years. In that context, I stand behind Paul's words in Philippians 1:
"I eagerly expect and hope that I will in no way be ashamed, but will have sufficient courage so that now as always Christ will be exalted in my body, whether by life or by death. For to me, to live is Christ and to die is gain."
Paul goes on to say how torn he is between continuing to serve Christ on earth, and departing to be with him. I already understand somewhat how he felt and, as this goes on, I'm sure I will do so more and more.
Those (few...) of you who are Christians, please pray for me the same thing - that Christ would be exalted in my body and my actions.
Darin Fisher, network supremo, has pulled it out of the bag and come up with a less drastic short-term solution to the IDN problem. It has just been checked in for all three upcoming releases. Read about it over in bug 282270, but basically IDN will still work, but all occurrences of IDN domains in the browser UI (URL bar, security info etc.) will be the punycode form. There is a pref to re-enable full IDN - set "network.IDN_show_punycode" to false. As with the previous plan, this preference will be set to true in all official builds.
As I've said in previous blogposts, turning off IDN entirely was always an suboptimal solution, and I'm very pleased we've managed to find a third way. The search goes on for something better long-term - I'm sure you'll all agree that, while showing the punycode domain all the time solves the immediate spoofing problem, the fewer browsers out there that do it, the better.
Could I please add a plea that before anyone posts comments on bugs or blogposts suggesting their incredibly simple idea for solving the issue completely, could they please read at least some of the previous posts, bugs, discussions and papers written about the subject? Thanks :-)
"A Plan for Scams"[0] is a summary of my views on the action required to tackle the phishing problem. I believe a co-ordinated effort from browser and mail client vendors, website owners, ISPs, domain registrars and certificate authorities is necessary, and I outline what steps each of them should take.
This document does have something to say about IDN homograph attacks, but is by no means solely focussed on that.
[0] With apologies to Paul Graham.
There are some issues that I didn't make clear enough in my last IDN policy post.
Now, to talk about what other people are saying:
Paul Hoffman may know more about IDN and Unicode than I do, but as someone who has done a lot of thinking about browser UI, I can tell him that an "IDN explanation popup" will not be read. Also, merely indicating whether a domain name is IDN or not is useless unless there's some inference that a user can draw from that. "It's suspicious" is presumably not the inference he wants people to draw. And if one IDN domain spoofs another one, the icon will be similarly present on both.
He and others (including some advice issued by the IDN community) have also suggested that you can solve the problem by indicating the class of each character by changing the background colour. Leaving aside the problems this causes for the 5% of the population who are colour blind, this will merely make the location bar ugly. Users will either complain loudly about the ugliness and ask to turn it off or, if reconciled to it, either get used to the dancing array of colours behind the domains they visit (non-English users) or treat any change in colour as suspicious (English users). Both are bad outcomes, and neither improves security.
He can rest assured that we neither want to turn IDN off (permanently), nor do we want to make IDN use obnoxious. We would like IDN domains to work as beautifully and simply as non-IDN domains, and that's the goal we are shooting for.
After much discussion, staff@mozilla.org and drivers@mozilla.org have agreed a short-term strategy for dealing with the recently-publicised issues relating to IDN and domain spoofing.
First off, we want to make it clear: we support Opera's position that this is a registrar/registry problem. These issues were known when IDN was proposed, guidelines were developed for avoiding the problem by restricting registrations, and the DNS registration organisations need to step up and implement them. (Certificate Authorities should also, as a simple matter of acting responsibly, not issue certs for domains which are part of a homographic block registered to two or more entities.)
However, we also have a duty to protect our users. So, in the mean time, the enableIDN preference will be set to "false" in Firefox 1.0.1 and Mozilla 1.8 beta, including all official localisations. An XPI will be made available to turn it on again; this XPI will make the risks of doing so clear. This means that by default, links to IDN domains which use the Unicode rather than the punycode form for the href will fail, and the browser will display any IDN domain visited in its raw form.
In the future (Firefox 1.1 and beyond) we hope to be able to turn IDN back on again. We may be able to find a way to turn it on selectively for those TLDs which have a demonstrable record of good practice - but we can't promise to do that. It partly depends on how much resource maintaining a white or black list would take. (To help with that decision, please tell me of any instances where the registration of two homographic domains to different entities has happened in TLDs other than .com.)
So if people want to see full, unrestricted IDN back in Mozilla and Firefox, the best way is to put pressure on the world's registrars and registries to fulfil their obligations to their customers - both domain owners and Internet users - and commit to implementing the ICANN guidelines.
Software from mozilla.org has a good reputation for security, and we'd like to keep it that way. Dan Veditz, a long-time Mozilla contributor and ex-Netscape employee, was hired a year ago by the Mozilla Foundation to work full time on security issues, and the Foundation will soon be looking to recruit additional resource in this area.
But the project is bigger than just the Foundation, and our security story needs additional help. One place where we could do with reinforcements is in PSM (Personal Security Manager) - the security UI for the Mozilla Suite, and to some extent Firefox and Thunderbird too. This builds on top of our excellent NSS security libraries and other code to expose security control to the user.
PSM needs help in two ways - help at a code level with maintenance of an important part of our software and, in the more general sense, help in tackling the larger UI problem that security presents.
Exposing control of our security infrastructure in a way that gives sufficient flexibility, but is easy for users to understand is a big challenge. In the past, we've probably not done as well as we might on the "easy to understand" part. We hope that some people will step up to the plate to take part in collaborative, iterative, open UI development to improve our products in this area.
If this sounds like you, contact chofmann or dveditz.
Trolltech have recently dual-licensed QT for Windows under the GPL (as reported by scc). Previously, only the non-Windows versions were available under the GPL. Reading their FAQ on the subject, I did notice a clever licensing hack.
Q: I want to dual license my software too! That means I can use the Open Source edition for development, right?A: No. In order to write software that will be sold or licensed commercially, in addition to open source, all of your programmers will need a commercial license from the outset of the development phase.
But how can this be? The GPL allows you to use software you've obtained under it in any way you choose. "The act of running the Program is not restricted." How can Trolltech prevent you from developing your app against the GPL edition, and only buying a commercial licence when and if you want to release it?
Here's the trick:
If you use the Open Source edition of Qt, you can only publish the software under the GPL. Trolltech's commercial license terms do not allow you to develop any proprietary software using the Open Source edition.
The commercial licence terms presumably say something like "you can't use this license to distribute code you originally developed against the GPL edition". So they use the commercial licence terms to restrict the use of the GPLed version. Clever. And legal.
You heard it from the horse's mouth - IE doesn't use standard Windows controls. So all those who continue to complain about how XUL "re-invents the wheel" by doing its own widgets, and how that has to be the cause of our allegedly poor performance (did you start Firefox recently?) can finally pipe down.
Raymond Chen is a Microsoft guy who writes a fascinating technical blog called The Old New Thing. While hoping I never have to use any of the technologies he discusses, he writes so well and comes out with such great historical nuggets that it's essential reading.
Tecmo, the company who makes such classics as "Dead Or Alive: Extreme Beach Volleyball", a gameplay-free excuse to display hi-res moving images of scantily-clad women, has sued a modding community for messing with its games.
"Most of the skins posted on the Message Board by defendants show Tecmo Characters with appearances that are different from the original Tecmo designs," the complaint notes. "Several... are designed to make Tecmo Characters appear naked."
Oh, the horror! How could evil hackers do such a thing to a family company like Tecmo?
"Hackers, if they're allowed to do this kind of thing, will be allowed to hack into any game, anywhere," [a spokeswoman] warns. "We spent millions of dollars to develop these games, and people are coming in and changing the code to their liking, and that's illegal."
Absolutely. If gamers start changing games so they like them more, where would it all end? I mean, you might end up with software that anyone could change for any purpose, without asking anyone's permission! What sort of world would that be?
Some further research reveals some unintentionally hilarious message board posts from around the time of the game's release. Feel the indignation!
Hollywood Video actually lists this as an adult game because of the supposed nudity, so I rented it and I couldn't wait to see the girls topless. I was totally looking forward to the "nudity" that was described on the box. After playing for about 2 hours straight I realized that there was none!
"...I want my money back!"
All I know is that in Xbox Mag (XXXbox issue) they stated that you would be able to "win" or "buy" topless mode. And just to be fair...I paid fifty bucks, so I deserve me some ***s!
(Censorship his, not mine.)
Yes your right EGM has a DOA XBV nude cheat.. but its the APRIL MAG!!!... as in APRIL FOOLs... as in that is just what we are.. fools... Dang i wanted it 2 be true.. have not tried it yet.. but ... i will not get my hopes up... sniff sniff... let it be true...
Aaaawww....
Yahoo! have released a beta of their search toolbar as a Firefox extension (release notes). The blog post says: "the Yahoo! Toolbar Beta is just one of many Firefox goodies you can expect to see from us this year, so stay tuned."
Point of interest:
PwdHash is a browser extension (currently IE only, but Blake wrote it, and plans to port it to Firefox) which allows you to use a single password for all sites in a secure fashion, by making the actual password used a hash of your master password and the domain name.
I love the idea, but I think that, if and when it gets built into Firefox, a modified UI is necessary. (Blake does say that "our focus thus far has been primarily on the technology, not on Firefox-style intuitiveness".)
Here's my suggestion. The right-click menu of a password field would have an option "Fill in password". Optionally, password fields would be decorated with a small "?" icon to click as well. Activating the function would prompt for the master password if it hadn't been given in that session, and then fill in that password field using the standard algorithm.
This style of UI, where the user has to request the password to be filled in, would work in harmony with the existing password manager, which would do the automatic prefilling the passwords in the future. It allows for a gradual transition between the old model and using PwdHash. A user could run any copy of Firefox anywhere, and the PwdHash mechanism would Just Work for them, using the same UI actions. There would no longer be issues with PwdHash's auto-fillin filling in the wrong fields, or trying to deal automatically with password reset forms.
For legacy browsers, the web-based generator should move to a well-known short URL (like "pwdhash.com") and should auto-fill the domain box with the domain of the Referer, if present. There's also an niche for a bookmarklet which takes the master password and fills in any password fields, if one can be squeezed inside the character limit.
Interestingly, as the site notes, PwdHash protects against phishing as a side effect. Pick "Fill in password" on a phishy site, and the password they get won't be the one that the genuine site uses.
The recent Shmoo Group punycode phishing demo has caused a lot of debate on the topic of phishing. In fact, domain registrars were warned about this problem (guideline 3, subsection b) when IDN was invented, and many registrars (for example, the Japanese) have implemented sensible controls to counter the problem of homographic domains.
However, it's caused me to crystallise a number of thoughts I've been having on the subject into a paper - Phishing - Browser-based Defences - which covers what we can be doing in the browser space to mitigate the phishing problem. It lists the qualities of a good solution, analyses some of the suggestions that have been made, and then makes three of its own.
Please let me know what you think.
I've been working on the relicensing project recently, and it seems the following instructions are necessary.
When adding licence blocks to files:
DO:
DON'T:
There is an exception to the last rule. You may put "#" blocks inside other comment styles in files which the XUL preprocessor runs over, as long as the surrounding comment markers are each on their own separate line, as follows:
/* # ***** BEGIN LICENSE BLOCK ***** # Version: MPL 1.1/GPL 2.0/LGPL 2.1 # # The contents of this file are subject to the Mozilla Public License Version ... # # ***** END LICENSE BLOCK ***** */
Last night, I went to a Gathering in London for players of "The Stone", an internet mystery game involving solving a load of cryptic pictorial puzzles, which are all smaller pieces of a wider framework which is slowly being revealed. Since it launched back in the last century, a real community has built up around the game, which is extremely well designed and implemented.
The Gathering was to watch a film about the community called "Stoners", made by Rod Bruinooge, original creator of The Stone.
If you are into puzzles, I'd invite you to come and join. It's tough, but it's great fun, and you get to meet a more... unusual type of person.
Fancy earning $18,500 a month ($222,000 a year) tax free, as part of a team of eight people working for a secretive organisation, living on an island in the Mediterranean and hacking on Mozilla? Then HJ has a job offer for you.
- you better inform us about who you are and what you did in the past, because we will get a hold on it anyways.
There's only one plausible explanation. You will be coding Mafiazilla.
I'm looking for a person who knows about, or research papers on the subject of, human perception of simple shapes, and distinguishing between them. I'd like to produce a set of, say, 64 shapes or glyphs which are all as different from one another as possible.
If anyone knows of something I should read or someone I should talk to, please let me know.
FOSDEM is the Free and Open Source Developers European Meeting, which has been held at the ULB in Brussels for the past few years. This year's event is on the weekend of the 26th/27th of February. Since the beginning, the EU Mozilla group has had a developers' room, where we have our own track of Mozilla-related talks and discussions, and there will be one this year too. A schedule is under development.
I'd encourage all European free software hackers, and particularly Mozilla developers to make an effort to come.