network.IDN_show_punycode stopped working
Categories
(Firefox :: Address Bar, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr115 | --- | unaffected |
firefox-esr128 | --- | unaffected |
firefox129 | --- | unaffected |
firefox130 | --- | verified |
firefox131 | --- | verified |
People
(Reporter: vqrhxw35a, Assigned: hsivonen)
References
(Regression)
Details
(Keywords: regression)
Attachments
(4 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:129.0) Gecko/20100101 Firefox/129.0
Steps to reproduce:
-
Downloaded and installed Firefox 130.0b4 64 bit
-
Visited the website https://www.xn--80ak6aa92e.com
Result: The website is showed as apple.com -
Digited in a new tab about:config
-
Searched for network.IDN_show_punycode and set from false to true
-
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
Updated•2 months ago
|
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.
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.
Updated•2 months ago
|
Comment 5•2 months ago
|
||
Regression window w/ network.IDN_show_punycode=true:
Comment 6•2 months ago
|
||
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).
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 hidden (duplicate) |
Updated•2 months ago
|
Comment 9•2 months ago
|
||
Because it's a whole script. The same domain is in the duplicate.
Assignee | ||
Comment 10•2 months ago
|
||
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 hidden (duplicate) |
Reporter | ||
Comment 12•2 months ago
|
||
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•2 months ago
|
||
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.
Reporter | ||
Comment 14•2 months ago
|
||
The punycode settings is not working.
Reporter | ||
Comment 15•2 months ago
|
||
(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.
Assignee | ||
Comment 16•2 months ago
|
||
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.
Updated•2 months ago
|
Comment hidden (admin-reviewed) |
Comment hidden (advocacy) |
Assignee | ||
Comment 19•2 months ago
|
||
I'll write a patch.
Assignee | ||
Comment 20•2 months ago
|
||
Reporter | ||
Comment 21•2 months ago
|
||
(In reply to Henri Sivonen (:hsivonen) from comment #19)
I'll write a patch.
I love you, thank you! This is a great news!
Updated•2 months ago
|
Comment 22•2 months ago
|
||
(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•2 months ago
|
||
Assignee | ||
Comment 24•2 months ago
|
||
Assignee | ||
Comment 25•2 months ago
|
||
https://phabricator.services.mozilla.com/D219259 is for beta.
Comment 26•2 months ago
|
||
bugherder |
Reporter | ||
Comment 27•2 months ago
|
||
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 hidden (duplicate) |
Comment hidden (duplicate) |
Comment 30•2 months ago
|
||
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
Updated•2 months ago
|
Comment hidden (duplicate) |
Assignee | ||
Comment 32•2 months ago
|
||
I tested Nightly on Mac, and the fix really is in Nightly now.
Updated•2 months ago
|
Assignee | ||
Comment 33•2 months ago
|
||
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/
- Observe that the URL bar says https://www.аррӏе.com/
- Via about:config, flip the pref network.IDN_show_punycode
- Reload the page from step 1
- 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
Assignee | ||
Updated•2 months ago
|
Reporter | ||
Comment 34•2 months ago
|
||
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•2 months ago
|
||
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 hidden (metoo) |
Comment hidden (metoo) |
Reporter | ||
Comment 38•2 months ago
|
||
The fix Is now also on Android, nighty version.
Good!
Assignee | ||
Comment 39•2 months ago
|
||
(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?valentinThe 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.
Assignee | ||
Comment 40•2 months ago
|
||
Hmm. Does Bugzilla have some rule that I can't re-request approval-beta if it has been denied?
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Comment 41•2 months ago
|
||
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.
Updated•2 months ago
|
Updated•2 months ago
|
Comment 42•2 months ago
|
||
uplift |
Comment 43•2 months ago
|
||
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•1 month ago
|
||
(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•1 month ago
|
||
(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.
Description
•