Slashdot Mirror


Mozilla Drops Support for International Domains

tsu doh nimh writes "Netcraft has the story that Mozilla has decided to drop support for international domain names in future versions of its Firefox Web browser. The decision comes after demonstrations by the Schmoo Group that the feature can be used to aid in phishing scams and other browser naughtiness." From the article: "The attack can be disabled in Firefox and Mozilla by setting 'network.enableIDN' to false in the browser's configuration (enter about:config in the address bar to access the configuration functions). The Mozilla development team today made this the default setting. Users who want IDN support will be able to turn it on, but will be warned about the risks involved."

73 of 365 comments (clear)

  1. Drops? by Anonymous Coward · · Score: 5, Informative

    They've disabled it by default until they come up with a long term solution. That's hardly dropping.

    1. Re:Drops? by bob65 · · Score: 4, Insightful

      No they didn't. They temporarily changed the default. Support for it certainly is still there.

    2. Re:Drops? by erroneus · · Score: 3, Funny

      Yeah, I wanted to say the same thing so I'll just say it here. They will have disabled it in new downloaded versions... I haven't seen a new release yet but I'm sure the next release it will be disabled by default. Hope it comes about soon but for now... I guess I'll have to switch back to MSIE where I *know* I'll be safe from that ONE kind of attack.

    3. Re:Drops? by GrenDel+Fuego · · Score: 4, Informative

      Actually I think it's funny how people are so quick to defend Mozilla and say it's not dropping anything. The grandparent is right to point out that they are indeed dropping support. It doesn't matter if they're temporarily turning it off. They're turning off support. They are dropping default support in future versions of Firefox.

      I think what we have here is a terminology conflict here.

      Support for computer software can mean "ability to use" (eg. does linux support SCSI hard drives?) or "ability to get help with" (eg. is linux 2.2 still a supported kernel?)

      IDN is still supported in that the functionality still exists on mozilla once it is turned on.

      It is not supported in that it's known broken, and you use it at your own risk if you enable it.

    4. Re:Drops? by Rodness · · Score: 5, Informative

      Now I understand why the Mozilla community consistently blasts Slashdot for "not getting it". Lately it doesn't even seem like the submitters are even bothering to read the articles before they rush to post their mental mucus.

      Mozilla has temporarily disabled internationalized domain name handling until they figure out a long term fix. This is not 'dropping' anything. They're not ripping out the IDN code, they're just trying to protect their users while they figure out a fix, and most of the English-speaking world isn't even going to notice a difference anyway.

    5. Re:Drops? by vperez · · Score: 2, Insightful

      I'm glad people understand sarcasm.

  2. Drops? by Scrameustache · · Score: 5, Insightful

    There's a difference between "drops support" and "sets that option to 'off' by default", you know.

    --

    You can't take the sky from me...

  3. That's False by Uruviel · · Score: 5, Informative

    It will be turned of in the 1.0.1 But for 1.1 and further releases they will look for a more cleaner way to fix the spoofing issue. And thus brining back IDN support. Here is a link to the Mozillazine article: http://www.mozillazine.org/talkback.html?article=6 073

    1. Re:That's False by Qzukk · · Score: 5, Informative

      A fix is pretty easy, but requires two parts:
      1) Amend the IDN spec to require that valid IDN urls use the lowest-numbered codepoints that match that glyph.
      2) Have browsers use a table that identifies all the characters that share a glyph. Any invalid IDNs are mapped down to the lowest codepoints before the browser goes there, so a link to a fake paypal.com address actually goes to the real paypal.com address.

      Of course, this still can't stop people who just refuse to look closely at the URL. The payqal.com domain is taken, who knows what its used for...

      --
      If I have been able to see further than others, it is because I bought a pair of binoculars.
    2. Re:That's False by interiot · · Score: 4, Insightful

      I dunno... when your entire security is dependent on the user being able to notice slight pixel changes on the screen, something seems a little broken...

    3. Re:That's False by bo-eric · · Score: 2, Insightful

      Or they could just use the Unicode facilities for doing just that, as described in the Unicode Standard Annex #15 - Unicode Normalization Forms... I think it's a good question why the IDN committee didn't do that in the first place. Or why registries allows registrations for domains that are approximately equal to already existing ones.

      --

      -- Free speech is only free if your time is worth nothing.
    4. Re:That's False by Alsee · · Score: 2, Interesting

      Any invalid IDNs are mapped down to the lowest codepoints before the browser goes there, so a link to a fake paypal.com address actually goes to the real paypal.com address.

      Setting aside other issues, I'd say that is very very VERY bad implementation. If the browser is given an invalid address then the browser should not invisibly guess at rewriting it into a valid address. Better to have invalid addresses trigger immediate errors and be killed off / corrected in the first place. It would be an absolute nightmare to encourage impossible to trace down bugs caused by quasi-valid and conflicting addresses that took identical and inexplicably sometimes go to the right place and sometimes don't. Remember, that address may pass through a chain of 14 different programs from different sources potentially in varying orders. Imagine clicking on a pseudo-valid address in an e-mail going through the e-mail program and through spam filter and through a proxy and off to a browser and throgh another proxy then to the local IP stack and then out to the DNS system and back to the local IP stack and through your ISP's proxy and cache and THEN first going out to the website.

      At some effectively random point it gets changed into a completely a different address. A different address which looks identical to any human attempting to hunt down a bug. It's worse than looking for an invisible needle in a haystack, you haven't even figured out yet that you're looking for a needle much less an invisible needle.

      -

      --
      - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
    5. Re:That's False by JanneM · · Score: 2, Informative

      1) Amend the IDN spec to require that valid IDN urls use the lowest-numbered codepoints that match that glyph.

      "Match the glyph" is a _very_ vague concept - and the degree of visual likeness will depend on the currently chosen fonts. Japanese half-width romaji looks very different from western monospace. Or extremely similar. It all depends on the typefaces you use, your locale and so on.

      2) Have browsers use a table that identifies all the characters that share a glyph. Any invalid IDNs are mapped down to the lowest codepoints before the browser goes there, so a link to a fake paypal.com address actually goes to the real paypal.com address.

      But they really don't share a glyph. Mostly, this has already been done when Unicode was defined; in fact, at some codepoints they were overenthusiastic and reused some glyphs they really shouldn't have.

      Just because two different glyphs will look very similar with some combination of typefaces (but, note, not with other), it doesn't mean they aren't very different and should be treated like it.

      Example: in sans-serifed fonts, I (caiptal "i") and 1 ("one") will tend to look very, very similar. With your suggestion, all "I":s will thus be changed to "1" in registered url:s everywhere.

      The problem is rather the opposite, actually. WHen you don't have the real typeface needed, the browser (or font system, really) tries to substitute the missing glyph with something similar, which is a good thing when you try to read text. It can make an URL look different from intended, however. One step of the solution may well be not to accept this kind of substition in URL:s. No idea if you can get this kind of control, though.

      --
      Trust the Computer. The Computer is your friend.
  4. network.enableIDN by athakur999 · · Score: 5, Interesting
    The attack can be disabled in Firefox and Mozilla by setting 'network.enableIDN' to false in the browser's configuration


    Isn't this the "fix" that everyone found stopped working after you restarted the browser?

    --
    "People that quote themselves in their signatures bother me" - athakur999
    1. Re:network.enableIDN by mikeophile · · Score: 4, Informative

      Clear your cache in Tools/Options/Privacy and restart Mozilla. Or go here and try this. /thank BoingBoing

    2. Re:network.enableIDN by scovetta · · Score: 2, Informative

      Or use my fix: http://www.scovettalabs.com/advisory/SCL-2005.002. txt in corporate environments (or home use too).

      --
      Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
    3. Re:network.enableIDN by athakur999 · · Score: 3, Informative

      Clearing the cache doesn't make setting network.enableIDN to false start working. The compreg.dat method you linked to also is not a permanent fix as that file is recreated everytime you install an extension.

      The AdBlock method does work though.

      --
      "People that quote themselves in their signatures bother me" - athakur999
    4. Re:network.enableIDN by athakur999 · · Score: 2, Informative

      That's talking about making changes to file 'by hand' using an external editor. If you use about:config, the browser itself keeps track of the change and modifies prefs.js according when you close it.

      Why don't you give it a try?

      --
      "People that quote themselves in their signatures bother me" - athakur999
    5. Re:network.enableIDN by ptlis · · Score: 2, Informative

      On the contrary, it does. At least for me: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0 I closed down all windows, cleared the cache & history, typed about:config into the Address bar, disabled network.enableIDN and then restarted Firefox.

      --
      There's mischief and malarkies but no queers or yids or darkies within this bastard's carnival, this vicious cabaret.
  5. Fix it now. by Anonymous Coward · · Score: 3, Informative

    From Chris Smith via BoingBoing

    1) Goto your Firefox address bar. Enter about:config and press enter. Firefox will load the (large!) config page.

    2) Scroll down to the line beginning network.enableIDN -- this is International Domain Name support, and it is causing the problem here. We want to turn this off -- for now. Ideally we want to support international domain names, but not with this problem.

    3) Double-click the network.enableIDN label, and Firefox will show a dialog set to 'true'. Change it to 'false' (no quotes!), click Ok. You are done.

    4) Go check out the shmoo demo again and notice it no longer works.

    1. Re:Fix it now. by el_gordo101 · · Score: 4, Informative

      5) Close all instances of Firefox, restart Firefox
      6) Go check out the shmoo demo again and notice it works again.

      This "fix" only works temporarily. Once you restart the browser, it reverts back to the original behavior.

      --
      TODO: Insert witty sig
    2. Re:Fix it now. by Anonymous Coward · · Score: 2, Informative
      1. Type "about:config" in the URL bar, then scroll down to network:enableIDN -> double-click and set to false;


      2. Go to "Tools" -> "Privacy" and clear the cache;


      3. Then restart Firefox. You are now protected.


      Clearing the cache is a mandatory step.

    3. Re:Fix it now. by Neurowiz · · Score: 4, Insightful

      Nope. Did exactly that. about:config, clear cache, restart Firefox, test at secuna - wham. The spoof still works.

      The Adblock method of stopping this (mentioned earlier) is a nice workaround. Adblock has become quite a useful tool.

      --
      Neurowiz
  6. It is good... by Jpunkroman · · Score: 3, Insightful

    It is good that after all the media news about Firefox actually having a security issue that the team moved to correct it, even if very short term. Unfortunetly I don't think this will get as much media coverage as the previous stories on it, but it is a step in the right direction. So, at least we don't have to wait for a fix, they will disable the issue, fix it, then reinable it. Sounds like good software development to me.

  7. NOOOOOO!! by Anonymous Coward · · Score: 5, Funny

    Not .cx!!?!? Don't drop support for .cx!!!

    1. Re:NOOOOOO!! by northcat · · Score: 5, Informative

      No, it's not dropping support for country specific TLDs (did i use the right term?). .cx, .us, .de etc., will all work. It disabled support for Internationalized domain names. Internationalized domain names are domain names with characters from non-english languages. http://www.verisign.com/products-services/naming-a nd-directory-services/naming-services/internationa lized-domain-names/index.html. IE doesn't support this too. It's all in TFA.

  8. Simple answer... by andreMA · · Score: 3, Interesting

    Wouldn't rendering the characters in question as black-on-red in the status and location bar be a more effective solution? Or the entire background changes to red to warn the user that the characters they can read aren't the "actual" characters in the domain name?

    1. Re:Simple answer... by arkanes · · Score: 2, Insightful
      "For every problem, there is one solution which is simple, obvious, and wrong."

      Pretend for a moment that you live in Japan, or Russia, and you actually use websites that use these IDN characters.

    2. Re:Simple answer... by RealAlaskan · · Score: 3, Insightful
      Pretend for a moment that you live in Japan, or Russia, and you actually use websites that use these IDN characters.

      Pretend, also, that you occasionally use paypal.com. Wouldn't you like to see that the background changes from the familiar red to a soothing white for the real paypal link?

      Making the colors configurable (maybe via two simple options: ``I regularly use IDN.'' and ``I don't usually use IDN.'') would take away most of the remaining objections.

      ``Simple and obvious'' does not mean ``wrong''.

  9. Temporary fix does not work.. by slashkitty · · Score: 3, Informative

    This was discussed before, but the temporary fix, of setting it to off, doesn't work in current versions. Apperently the setting wasn't reloaded when the browser was restarted. I hope they fix that as well. In the mean time, please do NOT recommend the temporary fix to people, because it makes them think they are safe when they are not!

    --
    -- these are only opinions and they might not be mine.
  10. Re:Mozilla is an American project by Anonymous Coward · · Score: 5, Funny

    What's this "international" thing people keep talking about?

    It's where you go to fight wars.

  11. Re:RTF...what? by Lisandro · · Score: 2, Informative

    Seriously, it says it RIGHT THERE. I quote:

    "This is obviously an unsatisfactory solution in the long term and it is hoped that a better fix can be developed in time for Firefox 1.1,"

    I found hard to beleive a serious project like Firefox would drop IDNs so easily. It's a huge world, you know.

  12. OUtstanding! Smart defaults by redelm · · Score: 4, Interesting
    I have always maintained that one of the keys to powerful software is carefully chosen defaults. Otherwise, there simply is too much for the user to learn before they see the value in learning it.

    Perhaps some of the international versions of Mozilla will have Int'l name _enabled_ by default. A quick peek at $CHARSET would do.

  13. Correction by Stiletto · · Score: 5, Informative

    The submitter SHOULD have mentioned that Mozilla has decided to disable internationalIZED domain names, ones made of "funny" unicode characters.

    International domain names like .uk .au, and our favorite, .cx, are of course still supported.

    1. Re:Correction by tehshen · · Score: 3, Funny

      Actually, my favourite is the Cook Islands, because then we can have .co.ck

      --
      Guy asked me for a quarter for a cup of coffee. So I bit him.
  14. Honest question by the+pickle · · Score: 2

    Has anyone actually seen a legitimate IDN in the wild?

    With most of the phishing scams targeted at English-speaking users, I don't see this as such a horrible decision.

    p

    1. Re:Honest question by Anonymous Coward · · Score: 4, Interesting

      Yes, There are plenty, especially in Sweden and northern Europe. Take for example vävtak.se.

      Anyway. I think this solution is truly bad. IDN is a fundamental change we need to the internet. Not only to incorporate local languages on to the Internet, but also to increase the number of available choices.

      Disabling IDN is really bad. Instead, as suggested by someone else here, the registrars should prevent/ban addresses that will look the same on screen as existing ones.

      In fact, couldn't Mozilla instead do a simple test and see if the domain name exists without the hidden characters. If it does then it should warn the user about it.

    2. Re:Honest question by SmokeHalo · · Score: 2, Funny

      Has anyone actually seen a legitimate IDN in the wild?

      I did once, when I was out hiking in the Appalachians. It ran off before I could photograph it.

      --
      I'm not good in groups. It's difficult to work in a group when you're omnipotent. - Q
    3. Re:Honest question by Anonymous Coward · · Score: 2, Insightful

      horseshit. vävtak.com should take me to the same place as vavtek.com

      NO! Why should it? ä is not the same letter as a (at least not in swedish and other north european countries)

      a != ä != å
      o != ö

      /AC

  15. Re:How about selective INT Domain Filtering? by PurpleFloyd · · Score: 5, Informative

    This isn't about turning off domains like .kr. Rather, it's about turning off Unicode support in domain names - currently, in browsers which support IDN, it's possible to send someone to a URL which looks like "https://www.paypal.com" but really has a letter replaced with a non-English Unicode character which looks the same. This deactivation turns off support for Unicode domain names, not national domains.

    --

    That's it. I'm no longer part of Team Sanity.
  16. hmph by miruku · · Score: 5, Informative

    have they not read this?

    --
    MilkMiruku
    1. Re:hmph by Myen · · Score: 2, Informative

      Yes they have. Or at least somebody working for MoFo has.

  17. Editors? by Space_Soldier · · Score: 2, Insightful

    Doesn't Slashdot have editors that are supposed to analyze and edit user postings. "Dropping" and "disabling" mean two different actions. I got confused for a second or two. Lately, Slashdot quality has been going down the tubes.

    1. Re:Editors? by ari_j · · Score: 2, Insightful

      Lately? This has been ongoing (or maybe complete) for years. The user submissions are either really bad as a whole or poorly selected by the editors to reflect only the low-quality posts we actually see, and then the editors further frustrate the readership by neglecting to do any editing at all, much less fact-checking.

      The least they could do is read the story and decide whether the story is accurate and whether the submission accurately reflects its content. If an editor can't decide one or both of those questions, then that editor should not post the story and some other editor who can understand the subject matter can take it up.

  18. Re:Those dirty foreigners by Anonymous Coward · · Score: 4, Funny

    In Soviet Russia, dirty foreigner is you

  19. Re:Internations by cthrall · · Score: 2, Informative

    Ahhhh...the point of the scam is a domain name that looks like www.paypal.com in your browser but redirects you to something eeeeevil.

    See the pretty demo.

  20. Make IDNs more obvious by Mr.+Sketch · · Score: 3, Interesting

    Why don't they just make it obvious you're visiting an IDN? Similar to how they handle SSL sites, the location bar background turns yellow. Maybe for IDNs, they can make it red and flashing or something similar, so it's obvious to the user that something may be wrong. Maybe they could check and see if there is an equivalent looking domain name in english and then making it red and flashing to let the user know that it may not be the site they think they're visiting.

    There just seems to be other ways to handle it, since it really is more of a 'user beware' issue.

  21. IDNC3 by StarDrifter · · Score: 5, Informative

    D. J. Bernstein (djbdns, qmail, ...) saw this problem coming back in 2002. He proposed an alternative to IDNA called IDNC3 which he claimed wouldn't cause this kind of mess. Looks like nobody listened to him though.

    1. Re:IDNC3 by evilviper · · Score: 2, Informative

      DJB is hardly a prophet. He predicted that new (greek) characters that looked like ASCII characters could be used to make an alternate URL that looks like it is legitimate. Big whoop. Anyone with a double-digit IQ and any grasp of the internet could have predicted the problem long before 2002. Back when I was signing on to Compuserve on a 286 running DOS, I could have told you that the rendering different characters similarly would pose problems with site verification.

      The solution, however, is not to eliminate the number 1, or the letter L from our keyboards, but to use decent FONTS in our web browsers. I generally use Bitstream Vera Sans, which does a fair job of differentiating between similar characters. An ever better solution would be for fonts to appear in different COLORS. If all numbers in URLs appeared BLUE, while all letters appeared GREEN, and all foreign characters appeared RED, you couldn't possibly confuse them. Most governments have figured this out decades ago, and design their currency in this way.

      Even fixing this will only stop the current wave of tricks. The underlying problem is that the internet (and computers in general) is just pieced together from spare parts. Things like SSL are just added on-top, and you're lucky Netscape programmers were even smart enough to put a Lock icon in the browser.

      These issues are everywhere, and just waiting to be exploited. I heard from someone, not long ago, that installed SSH and connected to a server, and noticed that his data was being transfered in clear-text. Now, the problem was just that the client and server couldn't agree on a mutual protocol, other than null, but the real problem is the lack of communication from the lower-levels of the program, to the user. OpenSSH has simply removed the NULL cipher for reasons such as this, but that's just another quick fix that doesn't really solve the problem, and will come back to haunt us in a few years.

      All this stuff NEEDS to be re-designed to be robust, and I don't mean handling strange errors behind the scenes, without telling the user. We lack the fundamental system design needed to put together a solid system from the ground-up, rather than piecing hacks on top of programs to temporarily eliminate the most common flaws that are exploiting fundamentally poor designs.

      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    2. Re:IDNC3 by snorklewacker · · Score: 2, Insightful

      > Looks like nobody listened to him though.

      To the defense of ... well, everyone but DJB, he doesn't exactly make people want to listen to him. Given his manner and his licenses, the conclusion of even cold rational business-oriented security folks is that if they borrow djb's ideas elsewhere, he'll turn around and sue them for IP violations simply out of spite.

      At any rate, his proposal for IDNC3 simply seems to be "just switch to UTF8, let everything break, and when it goes live, disallow any characters that are 'risky'". This is what we in the industry call a handwave. I'm not a fan of punycode either, but it addresses a problem that raw UTF8 precisely doesn't. There's simply nothing to his proposal at all.

      --
      I am no longer wasting my time with slashdot
    3. Re:IDNC3 by millwall · · Score: 2, Insightful

      An ever better solution would be for fonts to appear in different COLORS.

      Ahem, *cough* colour blind *cough*

  22. Can you identify an IDN? by jfengel · · Score: 5, Informative

    The problem is that you can't always easily identify an international domain name. In particular, IDNs contain characters that are nearly identical to Latin character set but are treated differently. Slashdot won't let me put in examples, but examples here.

    The paypal.com one is particularly scary. It looks like paypal.com in your status bar when you hover over the link. It reads paypal.com in your address bar. But it isn't Paypal. That's because the "a" isn't an "a" but is really Unicode D0B0 If they'd put any effort into making it look like Paypal, it would be easy for somebody to direct you there and steal your Paypal password.

    In Firefox and IE they're indistinguishable. Even if they added a clue that something was different (e.g. colors to indicate an IDN) you'd have to look closely, and if IDNs became common you'd start to ignore the color coding. If the only difference between "paypal.com" and an identical spoof were small, you'd get tired of looking closely, and forget. If the warning was unignorable, like a popup, you'd turn it off.

    So the upshot is, yeah, beware of web sites you don't know, but with IDNs you don't always know whom you know.

  23. Re:Internations by Tackhead · · Score: 5, Informative
    > If you ever go to an international domain name you such be looking out for scams anyway.

    No, no, no. IDN's aren't about country codes, they're about special character codings that result in things in your status bar that look like their ASCII equivalent characters, but aren't.

    Don't worry, that special site hosted in Christmas Island will continue to resolve just fine. :)

  24. Not International domain names. by northcat · · Score: 2, Informative

    Not International domain names. Internationalized domain names.

  25. We need to tighten up web certificates by EsbenMoseHansen · · Score: 4, Insightful

    Well, you wouldn't trust a site that doesn't present a valid certificate. The problem is that obtaining such is too expensive for many.

    We need a reliable way for the a domain owner to get a certificate issued for that domain. This is mostly a bureaucratic problem, which could be solved, people willing.

    --
    Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
  26. Real solution... by Sylver+Dragon · · Score: 4, Informative

    A real solution for this problem is posted here

    The applicable part is:
    1. Install the Adblock Firefox extension.
    here
    2. Look at the Adblock 'Preferences' and go to 'Adblock Options'

    3. Tick 'Site Blocking'

    4. Add the following filter :-
    /[^\x20-\xFF]/

    --
    Necessity is the mother of invention.
    Laziness is the father.
    1. Re:Real solution... by TuringTest · · Score: 3, Insightful

      This is not a solution, it's a workaround. A solution would be something that allowed to use IDN sites without risk of phishing.

      This will block any URL that uses characters outside the normal ASCII range.
      So why was IDN created at all?

      --
      Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
    2. Re:Real solution... by lakeland · · Score: 3, Insightful

      No, that's an awful 'solution'. What about a domain name like http://www.m/#257;ori.co.nz/? I bet that doesn't even render correctly for you since you probably disabled international fonts too. Your stupid solution prevents people from accessing that site.

      Or are countries supposed to not allow domain names to use characters from their language now? Chinese who don't speak a word of English are expected to guess an English version for local domains? I bet they'd like it as much as you'd like a new standard that only chinese characters are allowed in domain names since they are unambiguous.

      Disabling international domain names is barely acceptable for a workaround. It sure isn't any sort of solution to the problem.

  27. Re:That's International_ized_ Domain Names by Headw1nd · · Score: 2, Funny

    I feel your pain - how do so many long-winded comments spawn so quickly? Twenty minutes and the topic is washed up. I can only assume it's all a trick to get you to buy the subscription.

  28. Better yet by TuringTest · · Score: 2, Funny

    There are websites that use IDN characters... IN JAPAN!

    --
    Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
  29. a fix for Firefox under Linux by SilveRo_kun · · Score: 2, Informative

    From your home directory, enter the .mozilla/firefox/*.default folder; then with vim open compreg.dat, and search for the string: "idn-service;1" (use the / function). Change the 1 to 0 in both the strings you find. Now, restart Firefox.

    The url will still appear spoofed at the bottom-left corner of the browser, but if you click on the proof-of-concept link it won't work.

  30. It's like curing calluses by chopping the legs off by melted · · Score: 4, Insightful

    It's like curing calluses by chopping the legs off. It's about time that someone with a brain came in and fixed this phishing problem once and forever. Disabling international domains is not a solution. Remember, majority of the population of this planet doesn't speak English. Why should they NOT use their native alphabet?

  31. Better by Quixote · · Score: 2, Insightful
    A better solution would be to limit the possibilities for each domain. For example: ".com" can be limited to just plain ASCII. On the other hand, ".cn" can have the Chinese characters.

    Think about it: the aim of the IDN is so that the native readers of a non-ASCII language can use domains which make sense to them. If ASCII doesn't make sense, then what about the ".com"?

    This whole IDN thing was designed improperly. I can't imagine why the designers didn't bother to take a look at the myriad character sets floating around out there. Just a cursory glance at the Unicode book would have given them second thoughts.

    1. Re:Better by dreamer-of-rules · · Score: 2, Informative

      ..l..0..1..O..I

      They did consider the implications, compared them to the security risks users were already exposed to, and suggested that the applications (this being an application-layer protocol) visually distinguish IDN or mixed IDN domains.

      http://www.faqs.org/rfcs/rfc3490.html

      Check out sections 1.2 and 10.

      --
      Everyone is entitled to his own opinions, but not his own facts.
  32. Guess I'll have to get a day job. by Cyburbia · · Score: 3, Funny
    That's too bad. I just registered bánkofamerïca.com, too.

  33. Well.. by raehl · · Score: 5, Funny

    It's used to send me money, of course.

    Thanks,
    Qal

    1. Re:Well.. by qal · · Score: 2, Funny

      Damned ID-Theft... Qal

  34. Known broken? by Trejkaz · · Score: 2, Insightful

    It isn't IDN that's broken, it's users who don't read carefully before clicking a button.

    --
    Karma: It's all a bunch of tree-huggin' hippy crap!
    1. Re:Known broken? by Anonymous Coward · · Score: 2, Insightful

      Or is it ``the fault of domain name registries and registrars that let people register homographic variants of existing domain names''?
      (from mozillazine)

    2. Re:Known broken? by LittleBigLui · · Score: 2, Interesting
      Well, RFC 3454 mentions this kind of attack briefly:


      The Unicode and ISO/IEC 10646 repertoires have many characters that
      look similar. In many cases, users of security protocols might do
      visual matching, such as when comparing the names of trusted third
      parties. Because it is impossible to map similar-looking characters
      without a great deal of context such as knowing the fonts used,
      stringprep does nothing to map similar-looking characters together
      nor to prohibit some characters because they look like others. User
      applications can help disambiguate some similar-looking characters by
      showing the user when a string changes between scripts.


      So no, that doesn't resolve it, but it recommends a (general) way to deal with it.

      Obviously, Mozilla should have followed that recommendation instead of ignoring it.
      --
      Free as in mason.
  35. Solution! by Alsee · · Score: 2, Funny

    The solution to this whole mess is so simple! Just use numeric addresses!

    -

    --
    - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
  36. Re:Mozilla is an American project by LadyLucky · · Score: 3, Informative

    American? Hmm. Lead Developer was in my class in Auckland, New Zealand.

    --
    dominionrd.blogspot.com - Restaurants on
  37. Re:It's like curing calluses by chopping the legs by ockegheim · · Score: 2, Informative

    I've been a long-time web user, can speak French and German, have done a lot of trawling German sites for information, yet had no idea that anything other than ASCII was available for URLs. I think it's a good solution for most English speakers, especially monolingual English speakers until something better can be worked out.

    --
    I’m old enough to remember 16K of memory being described as “whopping”