1218179 - Flip the switch from transitional to non-transitional IDNA2008 processing

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Simon Montagu :smontagu]

After checking in bug 479520 with transitional processing, we will flip the switch to non-transitional processing (bug 479520 comment 152)

Comment 1

[Simon Montagu :smontagu]

Attachment: Patch

Comment 2

[Simon Montagu :smontagu]

Attachment: Patch v.2

I would have preferred to skip the test depending on ENABLE_INTL_API, but apparently that is not doable in xpcshell. Making it depend on os == "android" has the same effect in practice.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=416c2d070cf9

Comment 3

[Anne (:annevk)]

See bug 479520 comment 166 for why this is a bad idea from a security and user perspective.

Comment 4

[Jonathan Kew [:jfkthame]]

The patch here looks OK as far as the (minimal) code is concerned; but as for whether we should actually do this, or if this bug should simply be WONTFIX'd, it's clear from the comments in bug 479520 that there are still strongly-held opinions on both sides. It would be good to hear what Jungshik (as co-owner of the i18n module) thinks.

It would also be good to try and find out whether it's likely Blink/Chrome will make the corresponding change. Jungshik, any insights?

Comment 5

[Wil Tan]

I have voiced my concerns (in bug 479520 comment 155) about the need to include other communities who will be affected by this decision, namely communities using the four deviant characters ESZETT, GREEK FINAL SIGMA, ZWJ and ZWNJ.

Marcos Sanz replied in bug 479520 comment 163 that the .GR registry will be bundling the final sigma with small sigma.

I also found bug 479520 comment 166 from Mark Davis, author of UTS46, particularly insightful.

Comment 6

[Marcos Sanz]

Here is the position of our colleagues from the IR registry:

ZWNJ is a character extensively used in the Persian language. At the moment IRNIC is allowing ZWNJ registrations, but since there is no effective software support at the moment for it, they are bundling with the respective domain without ZWNJ at registration time and mapping them together at the DNS level according to IDNA2008. The Iranian registry would welcome a Firefox non-transitional behavior wrt ZWNJ to satisfy the needs of their language community.

Since I haven't found a public document to refer to, I have asked them to testify this statement here.

Comment 7

[Marcos Sanz]

And FWIW in bug 479520 comment 74 (https://bugzilla.mozilla.org/show_bug.cgi?id=479520#c74) we already have a statement from the BE registry about Eszett support.

(German is one of the official languages in Belgium, thus relevant)

Comment 8

[Markus Scherer]

Please keep transitional processing. It is the right approach for sharp s and sigma, and was the right approach in IDNA2003.

Domain names are case-insensitive. In a case-insensitive protocol, you have to match ß=SS=ss=ſs and σ=Σ=ς or else it's a bug.

Besides, for German, de-CH always uses ss rather than ß, and the 1996 spelling reform changed many prominent words regarding ß<->ss. This is very unlike how äöü are used.

In a case-*sensitive* protocol, it is proper to distinguish ß, SS, ss, ſs and σ, Σ, ς but in a case-*insensitive* protocol, they need to match to make sense, just like matching s=S.

I do not have an opinion about ZWJ/ZWNJ.

Comment 9

[Jungshik Shin]

Sorry for the late reply. I tend to agree with Markus about sharp-s. 

Chromium has two bugs on ZWJ/ZWNJ and Greek final sigma. 

http://crbug.com/303404  : ZWJ/ZWNJ

http://crbug.com/303407 : Greek sigma (likely to be closed as WAI). 

Currently, in ICU, all four characters in question are handled together, but there's an ICU ticket about handling them separately. 

http://bugs.icu-project.org/trac/ticket/10543

Comment 10

[Jungshik Shin]

I'm still weary of preserving ZWJ/ZWNJ because enforcing ContextJ rules would not be a perfect defense (afaict). An additional layer of 'protection' might as well be needed.

Comment 11

[Marcos Sanz]

Our colleagues from the CY registry (Greek is an official language in Cyprus) do not support IDNs at all as of
http://www.nic.cy/forms_02_06/EnglishRules_02_07_10.pdf
so they state that they are not affected and have no opinion so far about the non-transitional behavior of final Greek sigma in IDNs.

Comment 12

[Simon Montagu :smontagu]

(In reply to Jungshik Shin from comment #9)
> Sorry for the late reply. I tend to agree with Markus about sharp-s. 

Does this mean that, at least for sharp-s, Chrome doesn't have any plans to change to non-transitional processing at some future date?

Comment 13

[Marcos Sanz]

(In reply to Markus Scherer from comment #8)
> Please keep transitional processing. It is the right approach for sharp s
> and sigma, and was the right approach in IDNA2003.
> 
> Domain names are case-insensitive. In a case-insensitive protocol, you have
> to match ß=SS=ss=ſs 

Markus, I am sorry to disagree. You do know the following better than me but I will bring it up here: In the Unicode Collation Algorithm (UTS10) "ß" and "ss" already DO NOT match at secondary collation strength (though "A" and "a", for instance, still do). Let me run the example with ICU:

 Collator collator = Collator.getInstance();
 collator.setStrength(Collator.SECONDARY);
 if (collator.compare("A", "a") == 0) {
     System.out.println("Strings are equivalent");
 } else {
     System.out.println("Strings are NOT equivalent");
 }

 > Strings are equivalent

But on the other hand:

 Collator collator = Collator.getInstance();
 collator.setStrength(Collator.SECONDARY);
 if (collator.compare("ß", "ss") == 0) {
     System.out.println("Strings are equivalent");
 } else {
     System.out.println("Strings are NOT equivalent");
 }

 > Strings are NOT equivalent

This means there is a difference between "ß" and "ss" that trascends case (since it is the next tertiary collation strength that implements the case-sensitivity). Thus and accordingly, in a case-insensitive protocol, you do NOT have to match "ß" and "ss".

I know this is a special case (and so does UTS10 document it, tracking it back to the DIN German sorting standard), but it's all about special cases that we are talking here.

Comment 14

[Markus Scherer]

(In reply to Marcos Sanz from comment #13)
> In the Unicode Collation Algorithm (UTS10) "ß" and
> "ss" already DO NOT match at secondary collation strength (though "A" and
> "a", for instance, still do).

This is true, and I consider it unfortunate. The DUCET (Default Unicode Collation Element Table) treats ß as specified in DIN 5007.

This is inconsistent with toLower(toUpper("ß"))=="ss", which is why Unicode CaseFolding.txt has always mapped ß->ss (and also ſ->s and ς->σ). This is used in normal case-insensitive string comparisons (e.g., icu::UnicodeString::caseCompare() or u_strCaseCompare()), which is much more common than collation-based matching.

Unicode Case_Folding was also one of the main inputs to IDNA2003.

Some time after IDNA2003 was created, Unicode standardized the NFKC_Casefold normalization form which maps away both case (including the above) and compatibility variants (width, CJK ligatures, etc.). It is a good basis for protocols like IDNA.

Many years ago I did petition DIN to change the ß vs. ss sorting difference to only tertiary, so that it's consistent with case-insensitive matching, but they rejected it because they think of it as a ligature, and DIN 5007 gives ligatures a secondary difference. For collation, we decided to stay close to DIN 5007 so that we would not have to tailor it for German.

Incidentally, in the DUCET, there is also a secondary (not tertiary) difference between ſ and s, another pair that matches in standard case-insensitive matching (via Case_Folding), as well as in IDNA. IDNA2003 and UTS #46 mappings mostly follow the Unicode NFKC_Casefold normalization form rather than the DUCET.

By the way, even in collation there is only a tertiary difference between σ, Σ, ς.

PS: I am one of the maintainers of the UTS #10 spec, as well as the ICU implementer of case folding, case-insensitive matching, collation, and UTS #46.

Comment 15

[Marcos Sanz]

(In reply to Markus Scherer from comment #14)
> (In reply to Marcos Sanz from comment #13)
> > In the Unicode Collation Algorithm (UTS10) "ß" and
> > "ss" already DO NOT match at secondary collation strength (though "A" and
> > "a", for instance, still do).
> 
> This is true, and I consider it unfortunate. The DUCET (Default Unicode
> Collation Element Table) treats ß as specified in DIN 5007.
> 
> This is inconsistent with toLower(toUpper("ß"))=="ss", which is why Unicode
> CaseFolding.txt has always mapped ß->ss (and also ſ->s and ς->σ). This is
> used in normal case-insensitive string comparisons (e.g.,
> icu::UnicodeString::caseCompare() or u_strCaseCompare()), which is much more
> common than collation-based matching.

With the collator code I was just illustrating the special UTS#10 distinction ß/ss, and by no means trying to imply that comparison is often implemented that way. What developers actually use for normal case-insensitive string comparisons is

Java's String.equalsIgnoreCase()
PHP's strcasecmp()
Python's regex with re.IGNORECASE

to name a few I could quickly test, and... know what? They don't match ß/ss either, just like the collation-based matching.

Putting all pieces together: for me it's both, practice (ICU collator, Java, PHP, Python...) and theory (RFC 5892, DIN 5007, UTS#10), that back up my argument "even in the instance of a case-insensitive protocol, you don't match ß and ss".


> PS: I am one of the maintainers of the UTS #10 spec, as well as the ICU
> implementer of case folding, case-insensitive matching, collation, and UTS #46.

About UTS#46: I am shocked by the fact that your statement "you have to match ß=SS=ss=ſs and σ=Σ=ς or else it's a bug" is mutually exclusive with UTS#46 itself, which explains

"Once the transition for Deviation characters is over, Nontransitional Processing can be used exclusively."

All in all, that is my claim: transition is over. Flip the switch.

Comment 16

[Mark]

> All in all, that is my claim: transition is over. Flip the switch.

That is far too facile (the English word, not the French).

As I wrote before, it is almost completely beside the point whether ß and ss "should" be equated on this level. (I do agree with Markus on that, but it is a not a significant factor.) IDN already *cannot* meet the linguistic expectations for phrases/names in all languages: it fails badly even with English. It can do far better than ASCII, but it can't do everything.

The main reason for caution is whether there will be security/spoofing issues. Now, the cynic in me says: "Fine, have Mozilla be the guinea pig. Let it flip the switch, and see if there are problems. Then a year or two later, if the water's safe, the other browsers can follow."

But the security repercussions could be pretty bad for the very sizable population of people that use Mozilla. It would be far better to only change for known "safe" TLDs, where the registry guaranteed that all formerly equivalent labels *at every level* were either bundled or blocked if they had that TLD. If DENIC did that, then it would be straightforward for all browsers to support *.de.

And that is something that DENIC could push forward on, if it really wanted this change.

Comment 17

[Markus Scherer]

(In reply to Mark from comment #16)
> But the security repercussions could be pretty bad for the very sizable
> population of people that use Mozilla. It would be far better to only change
> for known "safe" TLDs, where the registry guaranteed that all formerly
> equivalent labels *at every level* were either bundled or blocked if they
> had that TLD. If DENIC did that, then it would be straightforward for all
> browsers to support *.de.

I agree, this would be a safe approach. I don't know whether DENIC can enforce bundle-or-block on all levels.

However, DENIC neither bundles nor blocks even on second level: amt-golssener-land.de != xn--amt-golener-land-mlb.de & messdienst.de != xn--medienst-rya.de

Just imagine this happening with sparkasse-giessen.de (a bank in the city of Gießen) vs. xn--sparkasse-gieen-2ib.de

Comment 18

[Markus Scherer]

(In reply to Marcos Sanz from comment #15)
> Java's String.equalsIgnoreCase()

Java has many i18n deficiencies. That's why anyone who cares uses ICU4J or similar.

> PHP's strcasecmp()
> Python's regex with re.IGNORECASE

I don't know why PHP strcasecmp() does not implement correct matching. I believe it otherwise uses ICU a lot.

For regular expression engines, non-1:1 matches are technically difficult, so they tend to not implement them even if they are the right answer. In UTS #18, matching ß=ss is part of what a level 2 implementation is expected to support. See http://www.unicode.org/reports/tr18/#Default_Loose_Matches

(I believe that the ICU regex code supports this.)

Comment 19

[Jonathan Kew [:jfkthame]]

(In reply to Markus Scherer from comment #17)
> Just imagine this happening with sparkasse-giessen.de (a bank in the city of
> Gießen) vs. xn--sparkasse-gieen-2ib.de

If the bank has only registered sparkasse-giessen.de and not sparkasse-gießen.de, then presumably they will always publish their web address as sparkasse-giessen.de.

I suppose would-be fraudsters could use the address with ß (e.g. in phishing emails), hoping that users will not notice the discrepancy. But that's not so very different from any other "alternate spelling" trick, of which there are many possibilities: e.g., imagine a British business with the domain banking-centre.com; I wonder how many users would notice if a spoof email directed them to banking-center.com instead?

Personally, I'm not entirely convinced that the security threat here is sufficiently serious to warrant a refusal to adopt the nontransitional behavior, if that's what the user community (and registrar(s)) involved generally want. But I can't judge how widespread that desire really is based just on comments from a handful of people in the current bugs.

(FWIW, in the specific case of Sparkasse Gießen, attempting to go to xn--sparkasse-gieen-2ib.de appears to redirect to sparkasse-giessen.de anyway, so that particular bank seems to be safe. But there are doubtless other examples.)

(In reply to Mark from comment #16)
> But the security repercussions could be pretty bad for the very sizable
> population of people that use Mozilla. It would be far better to only change
> for known "safe" TLDs, where the registry guaranteed that all formerly
> equivalent labels *at every level* were either bundled or blocked if they
> had that TLD. If DENIC did that, then it would be straightforward for all
> browsers to support *.de.
> 
> And that is something that DENIC could push forward on, if it really wanted
> this change.

Simon, you're in contact with DENIC, aren't you? How about pushing for this?

Comment 20

[Gervase Markham [:gerv]]

(In reply to Jungshik Shin from comment #10)
> I'm still weary of preserving ZWJ/ZWNJ because enforcing ContextJ rules
> would not be a perfect defense (afaict). An additional layer of 'protection'
> might as well be needed.

We have already taken the position that we are not able to offer perfect defences against spoofing in our IDN implementation. This became true as soon as we deprecated the whitelist and started using an algorithmic method <https://wiki.mozilla.org/IDN_Display_Algorithm>; whole-script spoofs (such as caxap.ru (Latin) and сахар.ru (Cyrillic) are already possible. Therefore, we should not avoid a course of action simply because it means we provide less-than-perfect anti-spoofing protection; we have already admitted that we are not able to provide perfect protection on our own. Keeping users entirely safe from this problem requires both cooperation from registries and wisdom from domain owners.

(In reply to Mark from comment #16)
> It would be far better to only change
> for known "safe" TLDs, where the registry guaranteed that all formerly
> equivalent labels *at every level* were either bundled or blocked if they
> had that TLD.

It is neither possible nor necessary to do this at every level. If the domain administrator of wibble.com allows different people to register both caxap.wibble.com and сахар.wibble.com, he is hurting his organization. Firefox does have a small character blacklist of characters which look like protocol elements such as ., / and :, to make sure there is no confusion about which part of a URL is which. But beyond that, our focus is only on preventing spoofing (as far as we can) at the publicly-registerable level.

Bundling or blocking are desireable and encouraged; but if a registry does not do this and yet requests the change, then it is clear who is responsible if someone is ever spoofed. If the registry is willing to accept that responsibility, I think we should let them accept it.

(In reply to Jonathan Kew (:jfkthame) from comment #19)
> Personally, I'm not entirely convinced that the security threat here is
> sufficiently serious to warrant a refusal to adopt the nontransitional
> behavior, if that's what the user community (and registrar(s)) involved
> generally want. But I can't judge how widespread that desire really is based
> just on comments from a handful of people in the current bugs.

My view is that we should let registries speak for their user populations, because they will also be taking responsibility if their customers are permitted to spoof each other.

Currently, we have the following declared opinions:

Eszett:
.de: non-transitional
.be: non-transitional
(eszett is not used in Switzerland)

Final-sigma:

.gr: non-transitional
.cy: no opinion

ZWJ/ZWNJ:
.ir: non-transitional

I think we need more opinions in the final category, and one might argue that we should consult .at for Eszett. But the trend seems clear to me.

> Simon, you're in contact with DENIC, aren't you? How about pushing for this?

AIUI, Marcos works for DENIC.

Gerv

Comment 21

[Marcos Sanz]

Yes, I speak officially for DENIC. Still trying to get a statement from NIC-AT.

Our colleagues from .LU have asked me to forward this:

Hello everyone,

German is one of the official languages of Luxembourg. As the registry
for .LU we do allow registration of domain names containing 'german'
characters. Currently the Eszett 'ß' is not part of allowed characters
as we do not support IDNA2008 yet.

This said, we do believe that current standard IDNA2008 does deserve
correct and full implementation in browsers in order to help advancing
full adoption and to fulfill the needs of the German-speaking community.
As a result transitional mapping should not be enabled as it would only
slow down natural evolution.

Best regards,
Gilles Massen
DNS-LU
Head of Technical Affairs

Comment 22

[Marcos Sanz]

(In reply to Mark from comment #16)

> It would be far better to only change
> for known "safe" TLDs, where the registry guaranteed that all formerly
> equivalent labels *at every level* were either bundled or blocked if they
> had that TLD. If DENIC did that, then it would be straightforward for all
> browsers to support *.de.

The DNS is a huge decentralized database: DENIC cannot do that, ICANN cannot do that, not even Saint Isidore of Seville -in his duties of patron saint of the Internet- can do that.

Comment 23

[Marcos Sanz]

(In reply to Markus Scherer from comment #17)

> However, DENIC neither bundles nor blocks even on second level:
> amt-golssener-land.de != xn--amt-golener-land-mlb.de

We as a community (that is: the DENIC cooperative together with more than 300 members, the .de registrars), decided that a limited grandfathering time period, widely announced enough in advance, was our transitional strategy. Just that, full dot. It was not an easy decision, it had advantages and risks, it was not perfect... but it was the decision of the community, taken exactly up to the day five years ago (https://www.denic.de/en/domains/internationalized-domain-names/sharp-s.html)

So to speak we have an ß anniversary today! As an anniversary gift I wish that community decisions are respected, pretty much in the way Gerv is doing in comment #20. Thank you for that!


So no, we don't block or bundle at the moment in .DE because we have very effective methods (domain dispute processes in place together with a quick/effective court system) to deal with the otherwise anyway existing problem of domain misuse in its many facettes (like the pretty real and clear examples of Jonathan in comment #19). As a matter of fact, it's against the registration guidelines (and a reason for domain suspension) to provide incorrect whois data. Markus, would you mind double checking/correcting the data of the owner and admin-c of said amt-golßener-land.de? Thanks ;->

Comment 24

[Mark]

> We have already taken the position that we are not able to offer perfect
defences against spoofing in our IDN implementation. 

This is far more insidious than spoofing with something like the infamous "paypal" spoof.
 1. The user picks a bookmarked URL (xxxxßxxxx.de), or types one in that he/she has often used before.
 2. It worked worked fine up until yesterday. 
 3. This morning FF was updated.
 4. That URL (exactly the same characters!) now goes to the wrong website, one that spoofs the original.

> It is neither possible nor necessary to do this at every level.

You are right, I overstated it. DENIC might only guarantee bundling/blocking at the next level, eg x.de, based on the contract with its registrants. In that case, it would be clear that one could allow xxxxßxxxx.de. 

As to the Nth-level possibility, it would depend on the contract that DENIC has with its registrants, as far as what *they* can do with their subdomains.

> My view is that we should let registries speak for their user populations,
because they will also be taking responsibility if their customers are
permitted to spoof each other.​

I would awfully surprised if DENIC took any responsibility at all (financial ​or otherwise) ​for a spoof involving ß​ vs ss URLs.​ (Marcos could confirm, however.)

In any event, I strongly suspect that if anyone were blamed by the customer, FF would be.

Comment 25

[Gervase Markham [:gerv]]

(In reply to Mark from comment #24)
>  1. The user picks a bookmarked URL (xxxxßxxxx.de), or types one in that
> he/she has often used before.
>  2. It worked worked fine up until yesterday. 
>  3. This morning FF was updated.
>  4. That URL (exactly the same characters!) now goes to the wrong website,
> one that spoofs the original.

5. People ask very hard questions of the registry which allowed such divergent registrations.

Do we know of any registries which have deployed any one of these 4 characters but not implemented bundling/blocking, apart from .de?

Gerv

Comment 26

[Marcos Sanz]

(In reply to Gervase Markham [:gerv] from comment #20)

> ZWJ/ZWNJ:
> .ir: non-transitional

Please consider that .IR comments apply exclusively to ZWNJ, they didn't comment on ZWJ since they are not affected.

(In reply to Gervase Markham [:gerv] from comment #25)

> Do we know of any registries which have deployed any one of these 4
> characters but not implemented bundling/blocking, apart from .de?

Besides .de and .be, AFNIC has deployed Eszett for all their ccTLDs (.fr/.re/.pm/.tf/.wf/.yt), so far without issues AFAIK, but I could double-check. S. comment https://bugzilla.mozilla.org/show_bug.cgi?id=479520#c79

(In reply to Mark from comment #24)

> This is far more insidious than spoofing with something like the infamous
> "paypal" spoof.
>  1. The user picks a bookmarked URL (xxxxßxxxx.de), or types one in that
> he/she has often used before
> [...]
>  4. That URL (exactly the same characters!) now goes to the wrong website

This scenario cannot happen with Firefox at the moment. If you bookmark a domain with an ß, FF will convert it to ss and be displayed like this in the bookmark catalogue. If you type domain with an ß, FF will convert it to ss and be displayed like this in the URL bar. After the FF update in your step 3, this wouldn't be the case anymore. I think that's a clean behavior of the software and FF couldn't be blamed for anything.

Comment 27

[Mark]

> This scenario cannot happen with Firefox at the moment.

Remember that I wrote: ", or types one in that he/she has often used before"

I don't think that FF actually corrects your memory for you ;-)

Comment 28

[Wil Tan]

(In reply to Mark from comment #24)
> > We have already taken the position that we are not able to offer perfect
> defences against spoofing in our IDN implementation. 
> 
> This is far more insidious than spoofing with something like the infamous
> "paypal" spoof.
>  1. The user picks a bookmarked URL (xxxxßxxxx.de), or types one in that
> he/she has often used before.

This could manifest in any TLD, not just .de.
The risk is higher for TLDs who are seen as supporting German:

1) TLDs that offer German IDN registrations - .com, .net, .info, .biz and dozens others; or
2) TLDs representing a German speaking territory - .at, .ch, ..

Since ß was not available for registration prior to IDNA2008 being supported by registries as well as registrars, domain registrants trying to register a name like "maß" might have been led to believe that it is equivalent to "mass" and therefore both versions are valid. After all, both versions worked, without the server even being aware of the fact that ß is used to access its resources.


> 4. That URL (exactly the same characters!) now goes to the wrong website,

The other scenario is that the URL no longer resolves.

Comment 29

[Jan V.]

My opinion is that the security issues you are talking about are worth to be discussed, but they are only theoretical. Until version 14, after which Opera switched to Chromium Engine, that Browser did support IDNA 2008 in non transitional mode, at least for ß. I do not remember and couldn't find a single report about a case where this led to a user being phished.

So I encourage you to just flip the switch, like this topic says.

Comment 30

[Alireza Saleh]

(In reply to Marcos Sanz from comment #6)
> Here is the position of our colleagues from the IR registry:
> 
> ZWNJ is a character extensively used in the Persian language. At the moment
> IRNIC is allowing ZWNJ registrations, but since there is no effective
> software support at the moment for it, they are bundling with the respective
> domain without ZWNJ at registration time and mapping them together at the
> DNS level according to IDNA2008. The Iranian registry would welcome a
> Firefox non-transitional behavior wrt ZWNJ to satisfy the needs of their
> language community.
> 
> Since I haven't found a public document to refer to, I have asked them to
> testify this statement here.

As Marcos said, IRNIC has accepted ZWNJ however the domain with ZWNJ is bundled with the one without. For the new round of IDN registration, IRNIC planned to stop doing bundle and recognize domain with ZWNJ as separate domain. I appreciate and support the effort that has been done to move to INDA2008. I've also talked with .bazaar (In Arabic Script) registry and according to their policy there is no bundling for labels using ZWNJ.

Comment 31

[Simon Montagu :smontagu]

(In reply to Mark from comment #27)
> > This scenario cannot happen with Firefox at the moment.
> 
> Remember that I wrote: ", or types one in that he/she has often used before"
> 
> I don't think that FF actually corrects your memory for you ;-)

The spoofing scenario seems excessively farfetched and not an adequate reason to stay with transitional processing. We have to assume (a) that the user is manually typing in the URL from memory, which seems to be rare and getting rarer, and (b) that the user has memorized a URL containing "ss" in the form with "ß" which no browsers currently support! Plus of course (c) that there exists a spoofing site with a "ß" in the first place.

(In reply to Gervase Markham [:gerv] from comment #20)
> (In reply to Jonathan Kew (:jfkthame) from comment #19)
> > Personally, I'm not entirely convinced that the security threat here is
> > sufficiently serious to warrant a refusal to adopt the nontransitional
> > behavior, if that's what the user community (and registrar(s)) involved
> > generally want. But I can't judge how widespread that desire really is based
> > just on comments from a handful of people in the current bugs.
> 
> My view is that we should let registries speak for their user populations,
> because they will also be taking responsibility if their customers are
> permitted to spoof each other.

This is my view also. Jonathan, are you ready to move forward?

Comment 32

[Simon Montagu :smontagu]

Attachment: Patch v.3 (comment-only change)

The patch as posted doesn't apply cleanly because of comments that I added at the last minute in bug 479520, this version takes the comments into account and updates them to be true after the change.

Comment 33

[Jonathan Kew [:jfkthame]]

(In reply to Simon Montagu :smontagu from comment #31)
> The spoofing scenario seems excessively farfetched and not an adequate
> reason to stay with transitional processing. We have to assume (a) that the
> user is manually typing in the URL from memory, which seems to be rare and
> getting rarer, and (b) that the user has memorized a URL containing "ss" in
> the form with "ß" which no browsers currently support! Plus of course (c)
> that there exists a spoofing site with a "ß" in the first place.

Moreover, if such spoofing sites do start to appear, trying to take advantage of the change, I think we might reasonably expect services such as Google's SafeBrowsing to begin flagging them.

> (In reply to Gervase Markham [:gerv] from comment #20)
> > My view is that we should let registries speak for their user populations,
> > because they will also be taking responsibility if their customers are
> > permitted to spoof each other.
> 
> This is my view also. Jonathan, are you ready to move forward?

Let's do it.

Comment 34

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/64f5eb0e56a3

Comment 35

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/64f5eb0e56a3

Comment 36

[Gervase Markham [:gerv]]

Thank you :valentin. Indeed, colleagues at other browser makers, if you are reading this: we hope you will join us and restore consistency, in a way that allows us all to move to respecting the wishes of the affected language communities. There may be a little short-term pain, but the Internet is here for the long run.

Gerv