Closed Bug 840036 Opened 11 years ago Closed 11 years ago

SecReview: Implement new IDN Unicode display algorithm

Categories

(mozilla.org :: Security Assurance: Review Request, task)

Product:
mozilla.org
Component:
Security Assurance: Review Request
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: curtisk, Assigned: dveditz)

References

(
URL
)

Details

(Whiteboard: [completed secreview][start mm/dd/yyyy][target 02/21/2013][Fx]) 

SecReview tracking bug
Actions regarding the review of the dependent bug should be tracked here.
1) Who is/are the point of contact(s) for this review?
2) Please provide a short description of the feature / application (e.g. problem solved, use cases, etc.):
3) Please provide links to additional information (e.g. feature page, wiki) if available and not yet included in feature description:
4) Does this request block another bug? If so, please indicate the bug number
5) This review will be scheduled amongst other requested reviews. What is the urgency or needed completion date of this review?
6) To help prioritize this work request, does this project support a goal specifically listed on this quarter's goal list?  If so, which goal?
7) Please answer the following few questions: (Note: If you are asked to describe anything, 1-2 sentences shall suffice.)
7a) Does this feature or code change affect Firefox, Thunderbird or any product or service the Mozilla ships to end users?
7b) Are there any portions of the project that interact with 3rd party services?
7c) Will your application/service collect user data? If so, please describe
8) If you feel something is missing here or you would like to provide other kind of feedback, feel free to do so here (no limits on size):
9) Desired Date of review (if known from https://mail.mozilla.com/home/ckoenig@mozilla.com/Security%20Review.html) and whom to invite.
Flags: needinfo?(gerv)
Note: bug 722299 comment 28 says that it will be decided _if_ security review is needed. Does the existence of this bug mean that you have decided that it is?

Here are the answers to your questions:

(In reply to Curtis Koenig [:curtisk] from comment #0)
> 1) Who is/are the point of contact(s) for this review?

Me and smontagu.

> 2) Please provide a short description of the feature / application (e.g.
> problem solved, use cases, etc.):

Currently, we decide which TLDs to show IDNs for based on a whitelist. Here's the canonical location of the list:
https://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/init/all.js#1050
although there's also a web page, which may be a little out of date in terms of the list contents:
http://www.mozilla.org/projects/security/tld-idn-policy-list.html

However, this approach is not scalable due to the release of hundreds (soon) and possibly thousands or tens of thousands (later) of new TLDs. So we needed a new approach. This wiki page describes that approach, plus the rationale:

https://wiki.mozilla.org/IDN_Display_Algorithm

> 3) Please provide links to additional information (e.g. feature page, wiki)
> if available and not yet included in feature description:

See above.

> 5) This review will be scheduled amongst other requested reviews. What is
> the urgency or needed completion date of this review?

Well, it's been waiting almost 12 months. And we want to have the new code in place well before the new gTLDs launch, which will be from May.

> 6) To help prioritize this work request, does this project support a goal
> specifically listed on this quarter's goal list?  If so, which goal?

It supports the goal of making the web accessible to and equally usable by all, no matter what their script or language.

> 7) Please answer the following few questions: (Note: If you are asked to
> describe anything, 1-2 sentences shall suffice.)
> 7a) Does this feature or code change affect Firefox, Thunderbird or any
> product or service the Mozilla ships to end users?

Yes - Firefox.

> 7b) Are there any portions of the project that interact with 3rd party
> services?

Not unless you count the DNS. :-)

> 7c) Will your application/service collect user data? If so, please describe

No.

> 8) If you feel something is missing here or you would like to provide other
> kind of feedback, feel free to do so here (no limits on size):
> 9) Desired Date of review (if known from
> https://mail.mozilla.com/home/ckoenig@mozilla.com/Security%20Review.html)
> and whom to invite.

(SecReviews are scheduled for 10am PST each day except Tuesday.) Wednesdays and Fridays are best for me. smontagu coded the patch, and lives in Israel, so if you need him, he will want to weigh on on when works for him.

Gerv
Flags: needinfo?(gerv)
Fridays are impossible for me, Mondays and Wednesdays are best.
dveditz: do you think we need a team review on this or is this something you can handle on your own?
Flags: needinfo?(dveditz)
OK, let's go for Wednesday 20th. Curtis: can you book us in?

If we do it at the standard time, that would be 1pm PST, 9pm GMT, 11pm (!) Israel time. Curtis, dveditz: is there any possibility of flexibility here? 10am or 11am would work for me, and perhaps be nicer for Simon.

Gerv
If you all can do Thursday the 21st, then we can likely get this in earlier in the day. Wednesday is pretty booked AM for dveditz.
Flags: needinfo?(dveditz)
I can do Thursday 21st at 9am PST or possibly 10am PST (5/6pm GMT, 7/8pm Israel time). smontagu?

Gerv
Flags: needinfo?(smontagu)
I can do Thursday 21st at 9am PST.

It would be helpful to have advance notice of the questions that are going to come up, since it's almost a year since I wrote the code in question and I am going to need to refresh my memory.
Flags: needinfo?(smontagu)
(In reply to Simon Montagu from comment #7)
> I can do Thursday 21st at 9am PST.
> 
> It would be helpful to have advance notice of the questions that are going
> to come up, since it's almost a year since I wrote the code in question and
> I am going to need to refresh my memory.

The general format and flow of the questions we normally ask will be part of the invite. I of course cannot predict all the questions that might come up but it will give you a general idea.
https://mail.mozilla.com/home/ckoenig@mozilla.com/Security%20Review.html?view=month&action=view&invId=39f7eb29-6e7d-4e4d-97b6-550567eab25c%3a250711-250710&pstat=AC&exInvId=39f7eb29-6e7d-4e4d-97b6-550567eab25c%3a250711-278791&useInstance=1&instStartTime=1361466000000&instDuration=3600000

Subject:	SecReview:Implement new IDN Unicode display algorithm [MODIFIED]
Meeting Details:
* Thu 21-Feb-2013, 0900 PST
* Where:
- MTV: 3V - Very Good Very Mighty
- SFO: 319 - Golden Gate Bridge
- Vidyo(9710) secreview [https://v.mozilla.com/flex.html?roomdirect.html&key=EEtiuXn8C5EP]

* IRC Channel: #security
* Etherpad: http://etherpad.mozilla.com/secreview
* Dial-in Info (phone):
- In office or soft phone: extension 92
- US/INTL: 650-903-0800 or 650-215-1282 then extension 92
- Toronto: 416-848-3114 then extension 92
- Toll-free: 800-707-2533 then password 369
- Conference num 99710
Items to be reviewed:
https://bugzilla.mozilla.org/show_bug.cgi?id=840036

Agenda:
* Introduce Feature (5-10 minutes) [can be answered ahead of time to save meeting time]
- Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- What solutions/approaches were considered other than the proposed solution?
- Why was this solution chosen?
- Any security threats already considered in the design and why?
* Threat Brainstorming (30-40 minutes)
* Conclusions / Action Items (10-20 minutes)
(In reply to Curtis Koenig [:curtisk] from comment #9)
> * Introduce Feature (5-10 minutes) [can be answered ahead of time to save
> meeting time]
> - Goal of Feature, what is trying to be achieved (problem solved, use cases,
> etc)

See: https://wiki.mozilla.org/IDN_Display_Algorithm#Background for details. Let us know if you need more.

> - What solutions/approaches were considered other than the proposed solution?

See: http://www.chromium.org/developers/design-documents/idn-in-google-chrome for a summary of what other browsers do. We did not consider those solutions acceptable - see below.

> - Why was this solution chosen?

See: https://wiki.mozilla.org/IDN_Display_Algorithm#Background 

Our primary goals were to:

a) protect users from spoofing attacks

b) treat all languages and scripts equally, in line with Mozilla's principles of inclusiveness

A consequence of b) is that we needed a solution such that if an IDN works in one copy of Firefox, it works in all of them. Anything else injects an intolerable element of uncertainty for domain owners, who cannot know how many of their customers see the correct form of the domain and how many see gobbledigook. That would have a significant chilling effect on the uptake of IDNs. This means that e.g. making name display depend on browser language or OS language, or other methods of throwing UI warnings in some but not all circumstances, are not acceptable.

Another consequence of b) is that saying that some scripts are just not allowed in IDNs, as Safari does, is also not acceptable.

One could argue that Latin has somewhat of a privilege in the resulting solution, but there are unavoidable historical reasons for that. Cyrillic and Greek are also somewhat disadvantaged as they cannot be mixed with Latin - but all-Cyrillic or all-Greek IDNs work everywhere, which is very for those script communities, and something that IE, Chrome and Safari have all failed to achieve. (In a rather culturally imperialistic move, Safari simply disables IDNs for those scripts entirely by default.)

> - Any security threats already considered in the design and why?

The design considers the same security threats as previous implementations, informed by eight years of additional experience.

It knowingly relaxes the restrictions in a way which may permit whole-script homographs - e.g. caxap.ru in all-Latin, and caxap.ru in all-Cyrillic. This is considered OK because other browsers such as Chrome and IE have implemented a form of script-mixing restrictions, and there have not been reports of problems with whole-script homographs. (Many registrars ban the practice of registering two homographic domains to different entities.) Also, there is no implementable programmatic way of detecting such possible problems at domain resolution time - they have to be detected at domain registration time, when the registrar is not under millisecond time pressure and has access to a database of existing registrations. 

The above relaxation is considered less bad than trying to maintain the whitelist in the face of 1000+ new TLDs, which would lead to IDN not working in lots of places where it should due to lack of manpower.

There is a political dimension to this; if we encounter problems e.g. with whole-script homographs, we will need to place the blame where it belongs - on the registries which are letting their customers attack each other.

Gerv
Some comments: 

While I'm all for principles of inclusiveness and having a fully unicode platform for the internet, this entire IDN proposal has been a train wreck from the very beginning (to be clear, I'm referring to the RFCs, not mozilla)  .

I'm very pleased that we are finally considering the security implications of deploying this fundamentally flawed set of standards.  While it's great that we could let caxap.ru and caxap.ru exist and belong to two different people, you are pretty much saying that you are preventing fishing attacks by trusting the entire worlds registries.  

I strongly disagree that this is the only line of defense available to customers of firefox.    To just blindly follow standards would be the same as allowing cross site cookies or enabling every requested popup.  

The core issue we have here is the registries. IT IS NOT THEIR JOB TO AUTHENTICATE a domain name to a business.  SSL can do that (or in some cases, only domain validate via email), but the core business of a registry is to sell names, not ensure that they don't conflict. 

While it's difficult to whitelist each TLD based on policy manually, I don't see any other option right now.  

I could envision a system utilizing TLD based resolution (eg a record attached to .name) which defines an electronic policy which communicates to the browser how it should behave when it receives an IDN for that TLD.  That system would need to be built and reviewed, of course. 

Specific to the "IDN Display Algorithm", it should really follow the guidelines as outlined here to detect confusable chars: 

http://www.unicode.org/reports/tr39/tr39-3.html#Confusable_Detection

Here's a great utility which illustrates just how bad this problem is: 
http://unicode.org/cldr/utility/confusables.jsp?a=google&r=None

Here's some demos of Traditional Chinese: 
http://unicode.org/cldr/utility/confusables.jsp?a=%E9%82%A3%E9%9A%BB%E6%95%8F%E6%8D%B7%E7%9A%84%E6%A3%95%E8%89%B2%E7%8B%90%E7%8B%B8%E8%B7%B3%E9%81%8E%E4%BA%86%E6%87%B6%E6%83%B0%E7%9A%84%E7%8B%97&r=None

and finally Simplified Chinese: 
http://unicode.org/cldr/utility/confusables.jsp?a=%E9%82%A3%E5%8F%AA%E6%95%8F%E6%8D%B7%E7%9A%84%E6%A3%95%E8%89%B2%E7%8B%90%E7%8B%B8%E8%B7%B3%E8%BF%87%E4%BA%86%E6%87%92%E6%83%B0%E7%9A%84%E7%8B%97&r=None
(In reply to 3ric Johanson from comment #11)
> I'm very pleased that we are finally considering the security implications
> of deploying this fundamentally flawed set of standards.  While it's great
> that we could let caxap.ru and caxap.ru exist and belong to two different
> people, 

To be clear: we are against this happening, just as you are. The only question is: who is best placed to prevent it happening?

> you are pretty much saying that you are preventing fishing attacks
> by trusting the entire worlds registries.  

That is not correct, because:

a) IDN-based phishing is a tiny subset of phishing
b) The controls we plan to put in place prevent all of it except full homograph spoofing
c) Once the problem is of manageable size, if registries fall down on the job, companies can 
   manage the issue through defensive registration, just like they do for registering their 
   name in multiple TLDs.

> I strongly disagree that this is the only line of defense available to
> customers of firefox.    To just blindly follow standards would be the same
> as allowing cross site cookies or enabling every requested popup.  

We were part of the group which _changed_ the standards - leading to IDNA2008 - precisely because we saw flaws in the original standard. This hardly counts as "blindly following".

> The core issue we have here is the registries. IT IS NOT THEIR JOB TO
> AUTHENTICATE a domain name to a business.  SSL can do that (or in some
> cases, only domain validate via email), but the core business of a registry
> is to sell names, not ensure that they don't conflict. 

This seems to be the fundamental philosophical disagreement. We believe that registries are best placed and have the best information to prevent one of their customers attacking another one, and it is part of the role a responsible registry will take on. And if a registry is not responsible in this matter, then people will take that into account when choosing from the many registries and TLDs available.

> While it's difficult to whitelist each TLD based on policy manually, I don't
> see any other option right now.

Is the Shmoo group offering to provide manpower to maintain the manual whitelist system?

Have you been as vocal in attacking the policies of the other browser vendors who implemented similar no-script-mixing systems some time ago?

> I could envision a system utilizing TLD based resolution (eg a record
> attached to .name) which defines an electronic policy which communicates to
> the browser how it should behave when it receives an IDN for that TLD.  That
> system would need to be built and reviewed, of course. 

This is a key question: why should this check be done millions of times a day by browsers (with exactly the same results on each occasion, for a given domain), when it could have been done once at registration time by the registry? You are advocating a highly complex system which has exactly the same weak point as the one you are pointing out - after all, who sets that "electronic policy"? The registry. If you say we shouldn't trust them, how do you know they will set a sensible policy? And if you agree they will, then why can't they enforce it at registration time, once?

Gerv
(In reply to Gervase Markham [:gerv] from comment #12)
> > you are pretty much saying that you are preventing fishing attacks
> > by trusting the entire worlds registries.  
> 
> That is not correct, because:
> 
> a) IDN-based phishing is a tiny subset of phishing

In part, because ya'll had been very smart about enabling the whitelist on specific high risk TLDs up until very recently. (thus, bug #840882)

If you try to be forward thinking for a minute, you can see how enabling thousands of duplicate domain names could be a major problem. 

> b) The controls we plan to put in place prevent all of it except full
> homograph spoofing

Are you saying the test urls here:  http://www.shmoo.com/idn will or will not work? 

.. and you are specifically excluding recommendations outlined in TR39 to detect confusable characters? 

> c) Once the problem is of manageable size, if registries fall down on the
> job, companies can 
>    manage the issue through defensive registration, just like they do for
> registering their 
>    name in multiple TLDs.

Do you receive any funding from anyone who is in the business of selling domain names?  It seems like you might be in a conflict of interest.  Are you really recommending that companies to register all of the variations (thousands? millions in some cases) of all international character sets?? 

> 
> > I strongly disagree that this is the only line of defense available to
> > customers of firefox.    To just blindly follow standards would be the same
> > as allowing cross site cookies or enabling every requested popup.  
> 
> We were part of the group which _changed_ the standards - leading to
> IDNA2008 - precisely because we saw flaws in the original standard. This
> hardly counts as "blindly following".

Who's "WE"? If you had an interest in providing security to your users, maybe you should have invited the reporter of bug #279099 to participate.

> > The core issue we have here is the registries. IT IS NOT THEIR JOB TO
> > AUTHENTICATE a domain name to a business.  SSL can do that (or in some
> > cases, only domain validate via email), but the core business of a registry
> > is to sell names, not ensure that they don't conflict. 
> 
> This seems to be the fundamental philosophical disagreement. We believe that
> registries are best placed and have the best information to prevent one of
> their customers attacking another one, and it is part of the role a
> responsible registry will take on. And if a registry is not responsible in
> this matter, then people will take that into account when choosing from the
> many registries and TLDs available.

Oh, see this isn't philosophical, it's based on legal precedent and policy.  Can you show me any example of any case law, in any court anywhere in the world who has given the authority to determine who is infringing on someone else's domain name to a registry?  Or even a policy which clearly states that?  

The only thing I can find is the "Uniform Domain-Name Dispute-Resolution Policy", which says: " Under the policy, most types of trademark-based domain-name disputes must be resolved by agreement, court action, or arbitration before a registrar will cancel, suspend, or transfer a domain name."

http://www.icann.org/en/help/dndr/udrp

"ya'll" have created a situation where the only method of stopping an ongoing phishing attack on a business is to take them to court and win. This is very short sighted. 

> > While it's difficult to whitelist each TLD based on policy manually, I don't
> > see any other option right now.
> 
> Is the Shmoo group offering to provide manpower to maintain the manual
> whitelist system?

heh, no, but we are not in the business of offering web browsers.  Clearly, this is problematic.

> 
> Have you been as vocal in attacking the policies of the other browser
> vendors who implemented similar no-script-mixing systems some time ago?

See bug #840882

> > I could envision a system utilizing TLD based resolution (eg a record
> > attached to .name) which defines an electronic policy which communicates to
> > the browser how it should behave when it receives an IDN for that TLD.  That
> > system would need to be built and reviewed, of course. 
> 
> This is a key question: why should this check be done millions of times a
> day by browsers (with exactly the same results on each occasion, for a given
> domain), when it could have been done once at registration time by the
> registry? You are advocating a highly complex system which has exactly the
> same weak point as the one you are pointing out - after all, who sets that
> "electronic policy"? The registry. If you say we shouldn't trust them, how
> do you know they will set a sensible policy? And if you agree they will,
> then why can't they enforce it at registration time, once?

I was not proposing that the registries maintain this.  Some other centralized org could (eg:  ICANN, unicode, etc.). If you really want to have a "seamless experience" then there should be some common method of filtering and accessing IDNs - Not each browser implementation handling things wildly differently.  That's not a good path to accessibility.

To be clear:  

 - I don't think browser should implement IDN until it's been completely gutted from a standards perspective and rebuilt from the top down using a common, clear set of guidelines for security.  Yes, that means some companies might loose their money in domains they already purchased.  It also means you've protected your customers (the users of mozilla stuffs).
(In reply to 3ric Johanson from comment #13)
> If you try to be forward thinking for a minute, you can see how enabling
> thousands of duplicate domain names could be a major problem. 

 
> > b) The controls we plan to put in place prevent all of it except full
> > homograph spoofing
> 
> Are you saying the test urls here:  http://www.shmoo.com/idn will or will
> not work? 

.com is an unusual case because, unlike most other TLDs, they did not begin issuing IDNs with sensible restrictions in place. (Most other people, I would suggest, learned from what happened to them when you reported the problem as you did.) Therefore, we are currently figuring out what to do about .com specifically. More news soon.
 
> .. and you are specifically excluding recommendations outlined in TR39 to
> detect confusable characters? 

I'm not sure what the question is here. TR39 helps you to compare two domain names to see if they are confusable or not. "The tables in the data file [confusables] provide a mechanism for determining when two strings are visually confusable." Say I am visiting a domain. What is the second string with which the browser should compare it?

> Do you receive any funding from anyone who is in the business of selling
> domain names?

I'm not aware of the names of every company which has a commercial relationship with Mozilla, nor am I aware of the full scope of the activities of some of the very large companies with which we do have a commercial relationship. However, I can tell you that the financial interests of any company are not a factor in my thinking here. I hope you will choose to believe me.

> It seems like you might be in a conflict of interest.  Are
> you really recommending that companies to register all of the variations
> (thousands? millions in some cases) of all international character sets?? 

No, no, and a third time no. If you are going to start kicking up a ****storm about this topic, it would be awesome if you did so from a position of actually being well-informed. Almost all of the homograph spoofs you can imagine, such as single-letter changes, are outlawed by the current registration policies of the registries - which you should feel free to check by trying to register some. Therefore, it's not possible for anyone to register them - offensively or defensively.

There are only two potential problems:

1) Historical registrations, like your current test URL - a problem only in the small set of 
   TLDs which started with rules which were too loose;
2) Whole-script spoofing, as permitted already by several other browsers

> > We were part of the group which _changed_ the standards - leading to
> > IDNA2008 - precisely because we saw flaws in the original standard. This
> > hardly counts as "blindly following".
> 
> Who's "WE"? 

Mozilla. If you mean "who was the group", that was the IDNA2008 group. 

> If you had an interest in providing security to your users,
> maybe you should have invited the reporter of bug #279099 to participate.

I joined the public mailing list and contributed without Mozilla needing to be a member of anything; you could have done the same if you'd wanted to.
http://www.alvestrand.no/mailman/listinfo/idna-update

> > Have you been as vocal in attacking the policies of the other browser
> > vendors who implemented similar no-script-mixing systems some time ago?
> 
> See bug #840882

Having re-read that bug, I can't see anywhere where you explain how you've been similarly vocal about the policies of the other browsers. Can you give me a specific comment reference?

> I was not proposing that the registries maintain this.  Some other
> centralized org could (eg:  ICANN, unicode, etc.). 

And how would they decide what is acceptable in a particular TLD? By asking the registries? Or some other way?

>  - I don't think browser should implement IDN until it's been completely
> gutted from a standards perspective and rebuilt from the top down using a
> common, clear set of guidelines for security.  Yes, that means some
> companies might loose their money in domains they already purchased.  It
> also means you've protected your customers (the users of mozilla stuffs).

I'm afraid stopping the world is not an option here - and even if we, Mozilla, wanted to, it's not a power we have.

Gerv
I'm sorry I was not able to attend the meeting, but I was wondering if the notes could be posted here.
Depends on: 843689
Blocks: 843689
No longer depends on: 843689
I am digging them  up now and will make sure you get them if somebody else doesn't post them first.

-r
at some point in the near future they will move to here: https://wiki.mozilla.org/Security/Reviews/IDN
Depends on: 843739
No longer blocks: 843689
Depends on: 843689
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [pending secreview][start mm/dd/yyyy][target mm/dd/yyyy] → [completed secreview][start mm/dd/yyyy][target 02/21/2013]
So all of the risks Mozilla is willing to accept?
(In reply to 3ric Johanson from comment #19)
> So all of the risks Mozilla is willing to accept?

That is not what this bug means, this bug just means we did a security review, documented happened in the review and filled any bugs we thought should be thought more about or changed based on the conversation in the review.

Since all of that occurred this bug is considered resolved. This does not mean we are accepting any given risk or that a given mitigation has been selected.
We agreed whitelisting .com was a mistake--introduced more risks than we wanted to accept--and will change that: bug 843739

We agreed the changes in bug 722299 under review here made IDN less risky than the current scheme of trusting registrars.
(In reply to Daniel Veditz [:dveditz] from comment #21)
> We agreed whitelisting .com was a mistake--introduced more risks than we
> wanted to accept--and will change that: bug 843739

Verisign told us when they applied that they had gone through a procedure to deal with any outstanding historical problems. as noted in the public discussion on the topic. However, prompted by 3ric's report, we did further investigation into that procedure and discovered that it was, in fact, inadequate to deal with those issues. On that basis, what Dan says is correct.

Gerv
Can you define what was inadequate?

(In reply to Gervase Markham [:gerv] from comment #22)
> (In reply to Daniel Veditz [:dveditz] from comment #21)
> > We agreed whitelisting .com was a mistake--introduced more risks than we
> > wanted to accept--and will change that: bug 843739
> 
> Verisign told us when they applied that they had gone through a procedure to
> deal with any outstanding historical problems. as noted in the public
> discussion on the topic. However, prompted by 3ric's report, we did further
> investigation into that procedure and discovered that it was, in fact,
> inadequate to deal with those issues. On that basis, what Dan says is
> correct.
> 
> Gerv
Here is a older (~7 months) list of about 900.000 IDN names in the .com zone. This data can be useful for unit tests and verification of assumptions and ideas.

https://moo.mx/stuff/dotcomidn.txt.gz
3ric: I posted more details of what they said in bug 840882.

Given that it's no longer possible to register such confusable domains, and given that Stefan's list shows that there are a large number of legitimate IDN domains in .com which now display correctly in Firefox and which we would rather not break, we think the best thing is to remove .com from the whitelist at the same time that we implement the new algorithm. That will provide continuity for those IDN domain owners. 

It's not yet clear exactly which release of Firefox that code will end up shipping in; it should be much more clear in a week or so.

Gerv
This code has landed in mozilla-central and is currently on track to ship in Firefox 22. We may uplift the fix to Firefox 21 but that's unsure. It will definitely NOT be in Firefox 20 which ships in a couple of weeks.
Whiteboard: [completed secreview][start mm/dd/yyyy][target 02/21/2013] → [completed secreview][start mm/dd/yyyy][target 02/21/2013][Fx]
You need to log in before you can comment on or make changes to this bug.