Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Mozilla The Internet

Mozilla Drops Support for International Domains 365

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."
This discussion has been archived. No new comments can be posted.

Mozilla Drops Support for International Domains

Comments Filter:
  • Drops? (Score:5, Informative)

    by Anonymous Coward on Tuesday February 15, 2005 @04:07PM (#11680665)
    They've disabled it by default until they come up with a long term solution. That's hardly dropping.
    • I was about to say, "Wow, is it April 1st already?"
    • Re:Drops? (Score:4, Funny)

      by erroneus ( 253617 ) on Tuesday February 15, 2005 @04:48PM (#11681199) Homepage
      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.
    • Re:Drops? (Score:5, Informative)

      by Rodness ( 168429 ) on Tuesday February 15, 2005 @07:31PM (#11683534)
      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.
  • Drops? (Score:5, Insightful)

    by Scrameustache ( 459504 ) on Tuesday February 15, 2005 @04:09PM (#11680693) Homepage Journal
    There's a difference between "drops support" and "sets that option to 'off' by default", you know.
  • That's False (Score:5, Informative)

    by Uruviel ( 772554 ) on Tuesday February 15, 2005 @04:10PM (#11680701) Homepage
    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
    • Re:That's False (Score:5, Informative)

      by Qzukk ( 229616 ) on Tuesday February 15, 2005 @04:29PM (#11680980) Journal
      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...
      • Re:That's False (Score:5, Insightful)

        by interiot ( 50685 ) on Tuesday February 15, 2005 @05:22PM (#11681855) Homepage
        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...
      • Well.. (Score:5, Funny)

        by raehl ( 609729 ) <(moc.oohay) (ta) (113lhear)> on Tuesday February 15, 2005 @05:28PM (#11681957) Homepage
        It's used to send me money, of course.

        Thanks,
        Qal
      • Re:That's False (Score:3, Insightful)

        by bo-eric ( 263735 )
        Or they could just use the Unicode facilities for doing just that, as described in the Unicode Standard Annex #15 - Unicode Normalization Forms [unicode.org]... 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.
      • Re:That's False (Score:3, Interesting)

        by Alsee ( 515537 )
        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 n
      • Re:That's False (Score:3, Informative)

        by JanneM ( 7445 )
        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 t
    • " ... more cleaner ... "

      Yikes
    • That's not a link, that's a URL, and it's perverted by slashcode which adds spaces to words that are too long, making it useless for copy and paste.

      A link would be something like http://www.mozillazine.org/talkback.html?article=6 073 [mozillazine.org]
  • network.enableIDN (Score:5, Interesting)

    by athakur999 ( 44340 ) on Tuesday February 15, 2005 @04:10PM (#11680709) Journal
    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?

  • Fix it now. (Score:3, Informative)

    by Anonymous Coward on Tuesday February 15, 2005 @04:11PM (#11680717)
    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.
  • It is good... (Score:3, Insightful)

    by Jpunkroman ( 851438 ) on Tuesday February 15, 2005 @04:12PM (#11680732)
    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.
  • NOOOOOO!! (Score:5, Funny)

    by Anonymous Coward on Tuesday February 15, 2005 @04:12PM (#11680736)
    Not .cx!!?!? Don't drop support for .cx!!!
  • Simple answer... (Score:4, Interesting)

    by andreMA ( 643885 ) on Tuesday February 15, 2005 @04:12PM (#11680739)
    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?
    • by arkanes ( 521690 )
      "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.

      • In Soviet Russia, IDN ... nah, too easy. :D
      • by RealAlaskan ( 576404 ) on Tuesday February 15, 2005 @05:07PM (#11681553) Homepage Journal
        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''.

  • by slashkitty ( 21637 ) on Tuesday February 15, 2005 @04:12PM (#11680741) Homepage
    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!
    • Considering this has been a known "exploit" for several years and its not widely used, people are no less safe now than they were a month ago or a year ago.

      There's a difference between being unsafe and having a greater risk exposure. If you have safe browsing habits, you are still safe regardless of the added risk exposure from a minor issue being hyped up by Slashdot, even though that issue was known at the time internationalized domain standards were being created, and even though it was hyped up on here
    • It is slightly more dangerous than the parent implies (at least on Firefox 1.0 with MacOS X 10.3.8)

      Just tried it: network.enableIDN remained set at false. Then went to the test page at secunia.com [secunia.com] and it was clearly set to true. Went back to about:config, and it still says false, even though it has to be true.

      So, don't be misled by the setting status.

  • by redelm ( 54142 ) on Tuesday February 15, 2005 @04:13PM (#11680754) Homepage
    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.

  • I assume there will be an extension to do this shortly. I'm too lazy plus I have to do this on a few computers. It would be better if I could load it on a USB stick and go around installing it instead of editing some file.
  • International domains are dying, and Netcraft confirms it?
  • Correction (Score:5, Informative)

    by Stiletto ( 12066 ) on Tuesday February 15, 2005 @04:13PM (#11680760)
    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.
  • by the pickle ( 261584 ) on Tuesday February 15, 2005 @04:13PM (#11680763) Homepage
    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
    • Re:Honest question (Score:4, Interesting)

      by Anonymous Coward on Tuesday February 15, 2005 @04:20PM (#11680860)
      Yes, There are plenty, especially in Sweden and northern Europe. Take for example vävtak.se [vvtak.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.
      • Relying on the registrars to police this is asking for failure. How do you decide which overlaps are allowed? Do they only look for well known ones (well known to whom)? Ones that pay for the service? Any overlap?

        The brutal fact is, punycode is poorly designed. I agree that internationalized domain names are a good thing...but pure punycode is not the way to do it. Until we have a good way to handle the problems that punycode's design brings up, we should disable it by default. Once we have a handl

      • 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.

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

        increasing the available choices does not solve any problems. we already have pc-club.com != pcclub.com != pcclub.net .. when you give somebody a web address over the phone you explicitly announce dashes or all-one-word because everyone knows about these rediculous ambi
    • 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.
  • hmph (Score:5, Informative)

    by miruku ( 642921 ) on Tuesday February 15, 2005 @04:15PM (#11680788) Homepage
    have they not read this? [proper.com]
    • Re:hmph (Score:2, Informative)

      by Myen ( 734499 )
      Yes [mozillazine.org] they have. Or at least somebody working for MoFo has.
    • have they not read this [proper.com]?

      You know, I read what that guy had to say... and I don't get one of the decisions made. If mixing languages and character sets causes such problems (as two sites having the same "look" but not being the same site)... simple things like phishing are tip of the iceberg. What happens when you have two legitimate sites that are vying for a popular "name", but one is IDN and the other is not? (ie, stupid example: ebay.com vs. ébay.com... some guy with that last name)?

      I think the wh

      • FTFL (follof the f* link). There ARE legitimate uses for mixed character sets. You don't need them because your native language is english, I presume?
    • ...a Firefox extension!
  • Editors? (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.
    • Re:Editors? (Score:2, Insightful)

      by ari_j ( 90255 )
      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
    • Lately, Slashdot quality has been going down the tubes.
      You must be new here.
      • FYI: The spreadingsantorum link in your sig is only going to work on humans. Google spiders slashdot without a login and thus never even sees sigs. Try logging out, you'll see.

    • " Doesn't Slashdot have editors that are supposed to analyze and edit user postings."

      This is often deliberate. Slashdot editors often choose words that are sensational and inflamatory. Accuracy takes a back seat in these cases.

      "Lately, Slashdot quality has been going down the tubes."

      My recollection is that Slashdot has always had this quality. One way in which Slashdot has changed lately is the epidemic of those "free iPod" pyramid schemes [uglx.org]. I can't imagine that people find it worth the effort

  • by Mr. Sketch ( 111112 ) * <<moc.liamg> <ta> <hcteks.retsim>> on Tuesday February 15, 2005 @04:23PM (#11680897)
    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.
    • That does not help. It assumes that visiting a IDN site is something "rare" something you do only occasionally, something you do *not* do daily and certainly never do you trust an IDN site.

      It helps not at all if my bank is a Norwegian IDN-site and I get phished with some IDN-site. Both look identical in the adress-bar, both have the idn-yellow-background on the status-bar. How am I supposed to know which one is which.

      Oh, and making them red and flashing, that'll go over real well with those of us that

    • the correct solution is to fix the IDN spec to not allow multi-charset domains (probably allowing the tld to differ from the rest, or even allow foo.bar.com to have foo a differant sets in foo and bar but never allowing contiguous blocks of characters to use more than one set.)
  • IDNC3 (Score:5, Informative)

    by StarDrifter ( 144026 ) on Tuesday February 15, 2005 @04:26PM (#11680930)
    D. J. Bernstein (djbdns, qmail, ...) saw this problem coming [cr.yp.to] 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.
    • Re:IDNC3 (Score:3, Informative)

      by evilviper ( 135110 )
      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 e
      • Re:IDNC3 (Score:3, Insightful)

        by millwall ( 622730 )
        An ever better solution would be for fonts to appear in different COLORS.

        Ahem, *cough* colour blind *cough*
    • Re:IDNC3 (Score:3, 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 characte
  • Not International domain names. Internationalized domain names.
  • Real solution... (Score:5, Informative)

    by Sylver Dragon ( 445237 ) on Tuesday February 15, 2005 @04:41PM (#11681132) Journal
    A real solution for this problem is posted here [tns.net]

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

    3. Tick 'Site Blocking'

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

    • by TuringTest ( 533084 ) on Tuesday February 15, 2005 @04:59PM (#11681408) Journal
      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?
    • by lakeland ( 218447 ) <lakeland@acm.org> on Tuesday February 15, 2005 @06:33PM (#11682892) Homepage
      No, that's an awful 'solution'. What about a domain name like http://www.m/#257;ori.co.nz/ [www.m]? 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.
  • So does XYZ.US count as an international domain name? Seriously though . . . that was a poor post . . . internationalized/international; changes the entire meaning of the parent.

    Though this may surprise some of the more 'jaded' readers, I am really surprised that this one slipped by the editors. . .

  • So they can see how bloody easy it is to increase security by doing something as simple as making a safer setting the default.

    BTW, Bill if you're listening, thank you sooo much for allowing any source to install browser helper objects by default. I mean how could it go wrong, right guys? CWS variants pretty much destroyed my parents' PC's usability/trustworthiness.

  • 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.
  • by melted ( 227442 ) on Tuesday February 15, 2005 @04:58PM (#11681399) Homepage
    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?
  • Better (Score:3, Insightful)

    by Quixote ( 154172 ) * on Tuesday February 15, 2005 @05:06PM (#11681539) Homepage Journal
    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.

  • by Cyburbia ( 695748 ) on Tuesday February 15, 2005 @05:15PM (#11681715) Homepage
    That's too bad. I just registered bánkofamerïca.com, too.

  • Solution! (Score:3, Funny)

    by Alsee ( 515537 ) on Tuesday February 15, 2005 @07:57PM (#11683862) Homepage
    The solution to this whole mess is so simple! Just use numeric addresses!

    -

UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn

Working...