Bureaucrats, canmove, Confirmed users
642
edits
Security/Reviews/IDN: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 4: | Line 4: | ||
{{SecReview | {{SecReview | ||
|SecReview feature goal=See: https://wiki.mozilla.org/IDN_Display_Algorithm#Background for details. Let us know if you need more. | |SecReview feature goal=See: https://wiki.mozilla.org/IDN_Display_Algorithm#Background for details. Let us know if you need more. | ||
|SecReview alt solutions=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. | |SecReview alt solutions=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. | ||
|SecReview solution chosen=See: https://wiki.mozilla.org/IDN_Display_Algorithm#Background | |SecReview solution chosen=See: https://wiki.mozilla.org/IDN_Display_Algorithm#Background | ||
Our primary goals were to: | Our primary goals were to: | ||
a) protect users from spoofing attacks | a) protect users from spoofing attacks | ||
b) treat all languages and scripts equally, in line with Mozilla's principles of inclusiveness | 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. | 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. | 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.) | 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.) | ||
|SecReview threats considered=The design considers the same security threats as previous implementations, informed by eight years of additional experience. | |SecReview threats considered=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. | |||
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. | 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. | 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. | ||
|SecReview threat brainstorming=* Does the IDN display algorithm ever allow unicode combining marks? | |SecReview threat brainstorming=* Does the IDN display algorithm ever allow unicode combining marks? | ||
| Line 36: | Line 44: | ||
** plugins are a world of hurt, but mostly don't display domains. There are APIs where the plugin requests that the browser load things for it, in which case we'd use our own domain-name conversion/canonicalization code. | ** plugins are a world of hurt, but mostly don't display domains. There are APIs where the plugin requests that the browser load things for it, in which case we'd use our own domain-name conversion/canonicalization code. | ||
*** Flash - camera/mic request dialog, domain foo.com would like to access cam/mic. This is the case I worry about. | *** Flash - camera/mic request dialog, domain foo.com would like to access cam/mic. This is the case I worry about. | ||
**** Worst case they show the raw domain name? Yes. | **** Worst case they show the raw domain name? Yes. | ||
}} | }} | ||
{{SecReviewActionStatus | {{SecReviewActionStatus | ||