1913022 - network.IDN_show_punycode stopped working

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect)

Description

[Marco]

Attachment: firefoxissuepuny.gif

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:129.0) Gecko/20100101 Firefox/129.0

Steps to reproduce:

1. Downloaded and installed Firefox 130.0b4 64 bit

2. Visited the website https://www.xn--80ak6aa92e.com
   Result: The website is showed as apple.com

3. Digited in a new tab about:config

4. Searched for network.IDN_show_punycode and set from false to true

5. tested again https://www.xn--80ak6aa92e.com in the browser but still load apple.com instead of show the URL address https://www.xn--80ak6aa92e.com

This seems a BUG or please tell me now how can I show puny code domain that are danger on my opinion and Firefox show badly in a risky way on my opinion.

Actual results:

After setting network.IDN_show_punycode to true, the website https://www.xn--80ak6aa92e.com that is a puny code still be showed as apple.com

Expected results:

The website https://www.xn--80ak6aa92e.com should be showed as https://www.xn--80ak6aa92e.com because I set to true the settings network.IDN_show_punycode

Comment 1

[Marco]

The issue affect also Firefox Developer for Android.

Comment 2

[Marco]

Could I say that I feel very unsafe in Firefox about puny code domain and the possibility of phishing?
Now with this bug I'm unable to protect myself on Android where I can't also install any of the two extension that exist to be alert or block puny code domain. Extension of third part that also I'm not happy to install.

On the PC also in the developer version is now impossible detect puny code domain as the settings to show puny code domain in about config is not working.

On Android i stop to use the stable Firefox version because don't have about config and so I cannot say to Firefox to show puny code domain but now also the developer is no more working about showing puny code domain.

I hope in a fix or in a solution soon.
With Chrome every puny code domain get an alert to keep the user safe, in Firefox not and https://www.xn--80ak6aa92e.com/ is showed as original apple website. Also other puny code domain show as other website no visual difference.

Now I have to understand if you fix this issue / bug or why the settings is no more working.
I hope in the future Firefox can be more secure regarding puny code domain also on the stable version without the user has to change a settings to be alerted, to see puny code domain that can be showed as other domain and create a potential phishing attack.

Comment 3

[Marco]

Without the ability to show puny code the domain http://xn--mozlla-r9a.com/ is showed as a domain similar to mozilla.com , similar because the i is not a i and the domain seems to be not registered but if was can maybe be dangerous.

This issue never happen on Chrome that alert immediately this is a puny code domain but Firefox show as http://mozılla.com/ domain.

Comment 5

[Alice0775 White]

Regression window w/ network.IDN_show_punycode=true:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ebb04323fe3390d814ca8ac0c73b663b78ffe007&tochange=87d0e483dd8c374b25c66d0e74858f3f5ecd4cf5

Comment 6

[Gregory Pappas [:gregp]]

Not sure it's totally accurate to say that this is a duplicate of bug 1332714? It seems like the real complaint here is that network.IDN_show_punycode no longer works. My understanding is that this was an intentional consequence of bug 1889536 (see also bug 1911935 where the already broken pref was cleaned up).

Comment 7

[Marco]

Sorry but i don't understand, the bug has been flagged as resolved but is not.
Why puny code settings is no more working?

Comment 8

[Marco]

Sorry but i don't understand, the bug has been flagged as resolved but is not.
Why puny code settings is no more working?

Comment 9

[Robert Longson [:longsonr]]

Because it's a whole script. The same domain is in the duplicate.

Comment 10

[Henri Sivonen (:hsivonen)]

network.IDN_show_punycode is not a security solution for our userbase in general: It only works for the (presumably very) small number of users who've toggled the hidden pref (and whose language is sufficiently ASCII-ish that they can tolerate the resulting user experience). We could consider re-implementing network.IDN_show_punycode, though, but it would be good to have an idea of how many people (evidently more than zero) used it.

There's no generic solution that doesn't break all Cyrillic .com domains for whole-script confusables like https://www.аррӏе.com/ . A blocklist of lookalikes for very well-known names (like apple) is, I gather, the solution that Chrome uses. My understanding of our policy stance is that we're not willing to break all Cyrillic domains on TLDs that aren't themselves Cyrillic-affiliated.

For domains like http://mozılla.com/ , there also isn't a generic solution that wouldn't break legitimate Turkic-language domains under generic TLDs. Recently, though, we've taken a number of case-by-case measures to limit ə to .az, to limit middle dot to .cat, and to limit eth and thorn to .is and .fo. Valentin, is that ad hoc, or do we have a principle?

Comment 11

[Marco]

You have removed the network.IDN_show_punycode settings? Is no more working?
I never use the Firefox stable for Android because I cannot see punycode domains and now I'm unable to do also on the developer version as the settings stopped to work.

I use to show punycode domain and there are different web article that explain how to manually enable that as Firefox never show any alert to the end user while Chrome do.

I don't like Chrome but on Firefox feel not very safe thinking in a browser that show an apple website address when is not apple website. This never happen only with apple website but with many other different website where on Chrome user get alerted. Feel much safer on Chrome about that.

Will be terrible if now Firefox never let user choose to show punycode domain and mask any punycode domain.
Will be terrible on my opinion.

Comment 12

[Marco]

Please give some solution to be able to use again network.IDN_show_punycode.
By ignore the settings you forbid to user who want see puny code domain to choose to see it and there is no more way to see punycode domain.
Also 131 is affected, all next Firefox generation. I hope in a fix or in a solution.
Thanks

Comment 13

[Valentin Gosu [:valentin] (he/him)]

I recommend https://addons.mozilla.org/en-US/firefox/addon/punycode-domain-detection/
We've shipped a bunch of IDN spoffing improvements in Nightly and they'll ship in Firefox 131.
The cyrillic fix for https://www.аррӏе.com/ will land in bug 1912865.

Comment 14

[Marco]

The punycode settings is not working.

Comment 15

[Marco]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #13)

I recommend https://addons.mozilla.org/en-US/firefox/addon/punycode-domain-detection/
We've shipped a bunch of IDN spoffing improvements in Nightly and they'll ship in Firefox 131.
The cyrillic fix for https://www.аррӏе.com/ will land in bug 1912865.

*** This bug has been marked as a duplicate of bug 1912865 ***

This extension doesn't work. I commented also in a review.
This bug is not a duplicate of the bug mentioned.
I see the same issue in Firefox 131, puny code settings is not working and suggested extension is not working, works only for few domains.

Comment 16

[Henri Sivonen (:hsivonen)]

Confirming and keeping open for now for a decision on whether to bring network.IDN_show_punycode back. Making isLabelSafe return early on a pref-bound atomic bool check does not seem as bad as all the previous mutex stuff there.

Comment 17

[bo0od]

So the concept of the attack has been firstly addressed in 2001.

Discussed again in 2017 [1], [2], [3].

Noticed by top privacy/security projects like TorProject and Whonix.

So, after about 23 years of real phishing threat, what did the Mozilla security team decide to do? Yep, exactly—close the related tickets and remove the ability to display fake URLs from browser.

Comment 18

[Marco]

Looks very strange also to me that an organization of free and hope safe Internet do that: remove now also the only settings that allow to see a potential phishing puny code domain.

I'm happy to see that Henry confirmed the topic and keep this opened after many others tried to close my topic.

I really hope to see the settings go back and I hope Firefox will manage better this in future.

For now the priority step is have the manual setting to show puny code URL in the URL bar back again.
I'm really deluded to see this bad changes in the new Firefox 131 and all next version.
On my phone I'm already vulnerable to this, on my PC just in the developer browser and soon I will be vulnerable also on the stable version.

Comment 19

[Henri Sivonen (:hsivonen)]

I'll write a patch.

Comment 20

[Henri Sivonen (:hsivonen)]

Attachment: Bug 1913022 - Restore the network.IDN_show_punycode pref.

Comment 21

[Marco]

(In reply to Henri Sivonen (:hsivonen) from comment #19)

I'll write a patch.

I love you, thank you! This is a great news!

Comment 22

[:glob ✱]

(In reply to bo0od from comment #17)

bo0od, this is a polite reminder that this is our professional working environment as much as it is our issue tracker, and I'm asking you to refrain from making further comments that don't move this bug towards a resolution.

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1400784cd682
Restore the network.IDN_show_punycode pref. r=necko-reviewers,valentin

Comment 24

[Henri Sivonen (:hsivonen)]

Attachment: Bug 1913022 - Restore the network.IDN_show_punycode pref. r?valentin

Comment 25

[Henri Sivonen (:hsivonen)]

https://phabricator.services.mozilla.com/D219259 is for beta.

Comment 26

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/1400784cd682

Comment 27

[Marco]

I downloaded Firefox nighty 131.0a1 (2024-08-15) (64 bit) and in the about:config the settings network.IDN_show_punycode is no more present so why this BUG has been marked as solved and how can I test it?

Comment 28

[Marco]

The BUG looks to me to be not resolved.
If I look at https://hg.mozilla.org/mozilla-central/rev/1400784cd682 I can see the fix should be present in Firefox milestone 131.0a1
that seems the version I tested.

In about:config the settings network.IDN_show_punycode is not found, not present.
The BUG looks to be not resolved to me.

In any case, present or not is not working for me.

Comment 29

[Marco]

Attachment: firefoxissuepunyafterfix.gif

After the fix and bug closure the issue is not resolved.

Comment 30

[Thorin [:thorin]]

Marco - https://hg.mozilla.org/mozilla-central/rev/1400784cd682 only landed 1 hr ago - updates to Nightly are twice a day AFAIK - definitely not every minute - be patient and wait for the next update

And please don't change internal status flags

Comment 31

[Marco]

Strange, some days ago when I tested 131 the settings was present, now seems is no more present.
I tried to add but still not work. For me is not fixed but let's monitor this.
The version number that I can see in the fix are the same of the version I tested and on that version is not working.
I will monitor here.

Comment 32

[Henri Sivonen (:hsivonen)]

I tested Nightly on Mac, and the fix really is in Nightly now.

Comment 33

[Henri Sivonen (:hsivonen)]

Comment on attachment 9419271 [details]
Bug 1913022 - Restore the network.IDN_show_punycode pref. r?valentin

Beta/Release Uplift Approval Request

• User impact if declined: Users who, for security reasons, have previously set a preference to display all internationalized domain names in Punycode form would not have their preference honored.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: 1. Load https://www.xn--80ak6aa92e.com/

2. Observe that the URL bar says https://www.аррӏе.com/
3. Via about:config, flip the pref network.IDN_show_punycode
4. Reload the page from step 1
5. Observe that the URL bar now shows https://www.xn--80ak6aa92e.com

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is about as low-risk as it gets: The patch adds a well-understood early return based on a boolean pref that has no Web-detectable impact (UI only).
• String changes made/needed: None
• Is Android affected?: Yes

Comment 34

[Marco]

Thank you, tested and today seems working also on Windows.
Thanks for the fix and sorry for my next messages.
I'm really happy to see a fix has been made and I feel grateful to Henry, Alice and all people that helped or was with me in this bug / issue.
Thanks for fixing.

Comment 35

[Pascal Chevrel:pascalc]

Comment on attachment 9419271 [details]
Bug 1913022 - Restore the network.IDN_show_punycode pref. r?valentin

The patch does not graft cleanly to the beta branch.

Comment 36

[Marco]

When the patch will work also on Android Firefox Nighty? I tested and on Android still not have the fix. Firefox 131.0a1 (Build #2016038543)

Comment 37

[Marco]

The fix will work also on Android or need report the issue about Android elsewhere?
When should be available also on Android? I tested in Firefox 131.0a1 (Build #2016038543) just in this hours but here still have the issue on Android.
Thank you.

Comment 38

[Marco]

The fix Is now also on Android, nighty version.
Good!

Comment 39

[Henri Sivonen (:hsivonen)]

(In reply to Pascal Chevrel:pascalc (PTO until August 27) from comment #35)

Comment on attachment 9419271 [details]
Bug 1913022 - Restore the network.IDN_show_punycode pref. r?valentin

The patch does not graft cleanly to the beta branch.

I tried it just now, and D219259 applied cleanly to beta. I reuploaded to Phabricator after rebasing, just in case. (This Phabricator revision isn't the same as the one that landed on central.)

I'll re-request approval-beta.

Comment 40

[Henri Sivonen (:hsivonen)]

Hmm. Does Bugzilla have some rule that I can't re-request approval-beta if it has been denied?

Comment 41

[Cristian Baica [:cbaica], Release Desktop QA]

The issue is verified fixed using the latest Fx 131.0a1 on Windows 10 and Ubuntu 23.04. After the network.IDN_show_punycode pref is flipped, the correct address is displayed in the URL bar.

Comment 42

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/b636a8339603

Comment 43

[Cristian Baica [:cbaica], Release Desktop QA]

The issue is verified fixed using the latest Fx130.0b8 on Windows 10 and Ubuntu. After the network.IDN_show_punycode pref is flipped, the correct address is displayed in the URL bar.

Comment 44

[Daniel Veditz [:dveditz]]

(In reply to Marco from comment #18)

Looks very strange also to me that an organization of free and hope safe Internet do that: remove now also the only settings that allow to see a potential phishing puny code domain.

Mozilla is an organization of a free and safe internet for everyone in the world, not only English-reading folks happy to ignore sites in other languages. Displaying punycode may work for you personally but combating phishing has to work for everyone. Some examples of work we've done include the Safe Browsing detection service and our involvement in developing the standards for phishing-proof "passkeys" to log into sites.

As our Manifesto says

We are committed to an internet that includes all the peoples of the earth

That said, I'm glad the pref is back.

Comment 45

[Daniel Veditz [:dveditz]]

(In reply to Henri Sivonen (:hsivonen) (not reading bugmail until 2024-09-02) from comment #40)

Hmm. Does Bugzilla have some rule that I can't re-request approval-beta if it has been denied?

Flags can have permission groups to prevent bug vandalism, and given our release management reliance on them, some approval and tracking flags can only be set by the "release drivers" group. But also once set those decisions can't be unset without the group permission.

In the case of uplift approval it would make logical sense to let the bug assignee or patch author have the right to set it back to '?' as an "appeal", but that's not a capability of the generic flag feature and wouldn't make sense for other flag uses. Hopefully it's rare enough that a "needinfo?" appeal can work OK, because changing the code behind flags or creating a variant field type is unlikely any time soon.