Closed Bug 564638 Opened 16 years ago Closed 16 years ago

Please whitelist .TO for IDN display

Categories

(Core Graveyard :: Networking: Domain Lists, defect)

Product:
Core Graveyard
Component:
Networking: Domain Lists
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: stonecypher, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729) The Tonga registrar is among the very strictest registrars, going as far as to prevent the usage of their domain for things that they suspect will lead to spam, such as URL redirectors. As such, given the other whitelisted TLDs, .TO seems like it should also be whitelisted for IDNs. ToNIC also hand-screens all URLs, among the reasons to cover copyright suitability (point 7 in their policy list.) In the attempt to imitate bug 322996 ( https://bugzilla.mozilla.org/show_bug.cgi?id=322996 ), which was this issue for the Icelandic registrar, and which succeeded, I here provide the ToNIC registrar's public policies. The Network.IDN.whitelist.* page at MozillaZine knowledgebase suggests that IDNs will be enabled if-and-only-if anti-spoofing policies are publically stated. They are stated more strongly by ToNIC than by ISNIC, which passed, so ToNIC should pass too. http://www.tonic.to/faq.htm http://kb.mozillazine.org/Network.IDN.whitelist.* Thank you for your help. I really have no idea how this process works. Reproducible: Always Steps to Reproduce: 1. Visit any .to IDN 2. Watch it display in Punycode 3. Stare angrily at unnecessary whitelist Actual Results: I got the punycode. Grr. Expected Results: Shown the IDN.
I confess, I still don't think this whole scheme of ignoring the standards in favor of a bunch of rules you guys made up is ethical. Red-bg the bar, warning icons, whatever, but you really don't have the right to cut a third of the internet off from internationalized domains based on your choice of registration mechanics. This is doing a lot of harm to a lot of small businesses, who aren't responsible for the legitimate, valid engineering decisions that Verisign made, which you happen to disagree with. You guys should not be attempting to control how the registrars make choices. Every other browser gets this right. It's time for Mozilla to choose a different path than refusing to render IDNs.
(In reply to comment #1) > Every other browser gets this right. It's time for Mozilla to choose a > different path than refusing to render IDNs. In fact, the whitelist system used in Mozilla was first introduced by Opera. http://www.opera.com/support/kb/view/788/ See also: http://www.chromium.org/developers/design-documents/idn-in-google-chrome#TOC-Behavior-of-other-browsers Please stick to the point as you did in comment 0. Here is not the place to discuss these issues principally.
Component: Location Bar → Networking
Product: Firefox → Core
QA Contact: location.bar → networking
John: do you work for Tonic ? They're the ones who should apply for this (some do it here, some contact Gerv directly). Note that their FAQ doesn't *not* mention anything about IDN - we need to know what they're doing to prevent homographically confusable domains. Most do this by restricting the charset that can be used, or by preventing certain combinations. But I can't see any information about this on Tonic's website (or it's not publically available). Mozilla's FAQ page about this is actually at <http://www.mozilla.org/projects/security/tld-idn-policy-list.html>. You can see that it links to all the policy documents from all the registrars that have been listed so far.
JJ: Actually, sir, Opera renders this IDN quite nicely. If indeed Opera did once use the system Firefox uses today, they must have ditched it, realizing it's not standards compliant, not what the users want, and doesn't protect the users. Firefox' IDN strategy is easily displayed to *not* be in force in Opera, or indeed any of the major browsers; the only major browser that has trouble with this other than Firefox is IE, which needs language packs to be installed. Jo: Their policies explicitly state that they hand-check every URL. That covers your requirements nicely. And no, I don't work for ToNIC, but IRC was quite clear that that sentence was spurious and should not be there. The example I gave from the Icelandic NIC was also fixed by a non-staff-member, as have indeed more than half of the TLDs not suffering this defect.
As far as homographically confusable, yes, that's exactly what I was saying you have neither the ethical right nor an appropriate design strategy to be enforcing.
Here is a screenshot of Opera not suffering the defective URL control system which JJ believes Firefox got from Opera. http://fullof.bs/OperaWorksFine.png
(In reply to comment #1) > I confess, I still don't think this whole scheme of ignoring the standards in > favor of a bunch of rules you guys made up is ethical. There is no standard for anti-spoofing. > Red-bg the bar, warning icons, whatever, but you really don't have the right to > cut a third of the internet off from internationalized domains based on your > choice of registration mechanics. This is doing a lot of harm to a lot of > small businesses, who aren't responsible for the legitimate, valid engineering > decisions that Verisign made, which you happen to disagree with. If we take the flak when people get spoofed, which we do, then we have a perfect right to put anti-spoofing measures in place. Are you really saying you would be entirely happy if, instead of displaying the URL bar as punycode, you got a big red "Dangerous Site" warning instead? Somehow, I don't think so. Please, seriously, do email the .to registry and encourage them to apply. I'm not quite sure what Verisign have to do with it - or are they the power behind the throne at ToNIC? Gerv
> There is no standard for anti-spoofing. That's correct. There are, however, standards for URLs, and those are being violated here unnecessarily in the name of a safety measure which does not actually create safety, and which lays the tremendously troubling groundwork that an application with a large userbase has the moral and ethical right to make demands of registrars, or hold the entirety of non-Latin domains as ransom. Note that this is why 1/3 of my users can't see .com i18n IDNs, despite that Verisign's IDN strategy is significantly stronger than Firefox' requirements. I wonder if you realize how much financial damage you are causing to small businesses. > Are you really saying you would be entirely happy if, instead of displaying > the URL bar as punycode, you got a big red "Dangerous Site" warning instead? > Somehow, I don't think so. No. But, then, that's not what I suggested, either. Frankly, I would in fact be more happy with that than the current solution, as then my users would understand that there was not a technical problem at my end (which is germane given that I own an internet service provider,) and rather that Firefox merely has concerns. But there are in fact better solutions than either, including the several I suggested. > If we take the flak when people get spoofed, which we do, then we have a > perfect right to put anti-spoofing measures in place. If and only if that anti-spoofing measure does not cause more harm than it creates, and if there are not more-effective, less-harmful strategies available to you, then I agree. However, both of those criteria are failed. Everyone at Mozilla Foundation seems to be stuck in the mindset that the options are the current way or nothing at all. Every other browser has a better strategy for this (even IE9.) Pick one and imitate it. > Please, seriously, do email the .to registry and encourage them to apply. I did. However, at the same time, Firefox is setting itself up to create an ethical nightmare, where any application which feels it's smarter than the registrars will hold tens of thousands of small businesses as ransom against registrars, waiting for the registrar to capitulate to the application vendor's demands. It's a shame Jon Postel passed. He prevented many, many of this kind of situation from happening, which is why the internet did not devolve in its early days into a mire of incompatible standards, when application authors began to attempt to force their will on service providers. I fear that I am not sufficiently eloquent to explain to you the tremendous ethical and moral problems here, nor the tremendous ethical and technological quandary you are lining up to create, by attempting to force yourself into the position of being able to dictate rules to top level registrars. This is exactly the sort of behavior that led most of Europe to suggest that America's involvement with ICANN be severed. We do not have the right to do things like this. China's registrar does not belong to Mozilla Foundation. Mozilla foundation has anti-spoofing options which do not cause Mozilla to break every registrar it doesn't agree with. This is ethically corrupt in a startling way. > I'm not quite sure what Verisign have to do with it They are the best example of Mozilla Foundation's radically over-reaching behavior and its contrast with how the real world works. They run .com, which you refuse to resolve according to URL standards, because their homography system, which is different than the one you want to impose, and radically stronger, does not satisfy Mozilla Foundation. As such, .com IDNs, which work everywhere else, and have for years, do not work in Firefox, because Mozilla Foundation did not get its inappropriate demands met. This has a measurable impact on business. Try it some time, so you know just how much this digging in of your heels is costing, in money, to other people, while they wait for you to realize that there are significantly less damaging options available to you that you simply refuse to consider.
At this point, someone with a clear understanding of Unicode can easily observe that homography requirements as provided by existing whitelisted registrars are not in fact sufficient, and that entire codepages must be eliminated without exception. The character forms of a great number of unicode characters are unspecified, and vary in practice. How do you intend to exclude the several copies of the alphabet in the Math plane, given that one of them looks identical to the other planes, and the others' depictions are not specified? Every registrar I've checked with confirms that the math plane is available for registration. I sat down today and I constructed a dozen different homograph spoofs which Firefox' methodology does not stop. When inserted into my local hosts file, every single one of them worked. All of them are stopped by Verisign's homography method, because whoever wrote that method has an intimate understanding of the structure of unicode code planes. That's who you're denying the world's most common TLD's appropriate resolution to - the people who correctly addressed the problem. Unit tests go places other than code. Had anyone actually made the effort to attempt to defeat Firefox' strategy, you might have realized that its primary value is in looking like a strategy is in place. The only thing stopping a black-hat from exploiting people on the math plane, or any of a number of other planes that echo the entire Latin character set, is Verisign's much stronger set of protections for .com .
(In reply to comment #9) > Every registrar I've checked with confirms that the math plane is available for > registration. If my memory serves me correctly, no-one on our whitelist has the Math plane on their permitted character list. So, if you successfully manage to register a domain name containing a character from the Math plane with one of the registrars for any of the registries listed on our whitelist, then I will be very interested in your results, and would speak to the registry in question. > I sat down today and I constructed a dozen different homograph spoofs which > Firefox' methodology does not stop. When inserted into my local hosts file, > every single one of them worked. Perhaps you could give those examples? > All of them are stopped by Verisign's > homography method, because whoever wrote that method has an intimate > understanding of the structure of unicode code planes. Can you please provide a URL reference to a description of "Verisign's method"? Also, how does the structure of Unicode code planes have a bearing on whether or not two particular characters are homographic? Gerv
Component: Networking → Networking: Domain Lists
I am volunteering some support on the tickets in this section and covering for Gerv while he's focusing on some very important things in the offline world. Seems like the purpose of this list is to whitelist TLDs and their stub zones if they are root listed, and this is done via contact with the ADMIN contacts listed with the IANA. In that spirit, I've emailed TONIC hostmasters for clarification on their use of wildcard, any stub zones (ie COM.TO, NET.TO, etc.), and their IDN tables, if any, along with a link to this bug. The response to my personal request from TONIC, when it comes, will indicate where any action moves on changes here should a change be merited. @John, in 10-20 dispassionate words, what is it you're reporting? (Respectfully, I got a little lost in what you were looking to have happen here in reading through the messages here.)
Basically, locking domains down to a single lingual plane doesn't fix the spoofing problem, and other browsers don't do it because everyone else knows it doesn't fix anything. Combine that with that it isn't Firefox' place to police what domains are allowable, and you've got a massive cluster of broken. This domain now works in every browser but Firefox, because Firefox wants to tell the internet how to work. There's nothing wrong with my current domain, it isn't spoofable, and it isn't Mozilla Foundation's place to determine which RFCs it chooses to implement on grounds of whether organizations which do not belong to Mozilla Foundation choose to implement a bad set of rules that Mozilla Foundation made up one day that don't work for their intended goals besides. This domain should work everywhere. Mozilla Foundation is behaving like Microsoft did in the IE4/5 era - make up rules and expect everyone to follow them based on "well we're going to break it for everyone if you don't." This is the worst behavior this group could be involved in. We're way out into "how dare you" territory here. Dispassionate words do not communicate adequately the correct reaction to Mozilla Foundation's choices. Jon Postel would be horrified.
(Admittedly, in IE8, you have to have those language packs installed, but that limitation disappears in IE9, which is now in second public beta, and should be released in a matter of months.)
John, will you care to respond to comment 11 ?
No. That was months ago. I don't remember where they were. I've sort of grown tired of this. There's no need to paint that bike shed any more. This is much simpler: there are several non-intrusive ways to provide this safety that Mozilla Foundation is ignoring. Mozilla Foundation should be 180ing on grounds of "oh right, we don't get to force registrars to abide by our policies, they're UN sanctioned and we're a free software group." This mechanism doesn't work, other mechanisms are painfully obvious, and this mechanism is not used by any other browsers. I'm tired of this. I lost interest in the domain I bought months ago, because you guys think you get to set rules for the rest of the internet. That's all you should need to know, right there. This is sickening and shameful.
It's been months and none of you have even tried to look into alternative approaches yet. Mozilla Foundation has the same problem Freenode does: people whose self value is set on their policies for a free software organization refuse to budge even on extremely obviously broken decisions because it offends their egos. Gerv hasn't even whitelisted my registrar yet. They contacted him months ago. This is ridiculous. Who are you to authorize UN sanctioned registrars to serve domains? Perhaps next you'll instruct China on what they may do on the web.
QA Contact: networking → networking.domain-lists
I spoke with the .TO administrators and they have updated their FAQ to include a narrative of their IDN policies.
http://www.tonic.to/faq.htm#19 says: "At present, .TO allows the registration of domain names containing any unicode code point." That is not acceptable (and not compliant with the latest version of the IDN standards either). It also will leave them a big legacy problem when they update to IDNA2008 and when/if they decide to have a proper anti-spoofing policy. "Registrations that are reported to be a "homonym" type registration used to perpetrate spam, phishing, fraud, or any activities deemed by Tonic to be inappropriate or illegal may be removed from the .TO zonefile without notice to the registrant." This suggests that .to waits for reports of malpractice rather than implementing restrictions at registration time. I'm afraid that's not acceptable to us either. Tonic have the right to allow whatever registrations they want in their namespace. But we also have the right to choose how we want to display them in our software. And currently, we choose to display them in Punycode form. Gerv
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.