Closed Bug 1913022 Opened 2 months ago Closed 2 months ago

network.IDN_show_punycode stopped working

Categories

(Firefox :: Address Bar, defect)

Firefox 130
defect

Tracking

()

VERIFIED FIXED
131 Branch
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)

Attached image 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

The issue affect also Firefox Developer for Android.

Component: Untriaged → Address Bar

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.

Status: UNCONFIRMED → RESOLVED
Closed: 2 months ago
Duplicate of bug: 1332714
Resolution: --- → DUPLICATE

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?

Status: RESOLVED → UNCONFIRMED
No longer duplicate of bug: 1332714
Resolution: DUPLICATE → ---

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

Flags: needinfo?(longsonr)

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?

Flags: needinfo?(valentin.gosu)

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

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.

Status: UNCONFIRMED → RESOLVED
Closed: 2 months ago2 months ago
Duplicate of bug: 1912865
Flags: needinfo?(valentin.gosu)
Resolution: --- → DUPLICATE
Status: RESOLVED → UNCONFIRMED
No longer duplicate of bug: 1912865
Resolution: DUPLICATE → ---

The punycode settings is not working.

(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.

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.

Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → 1911935
Summary: Puny code settings no more respected. Puny code domains not showed → network.IDN_show_punycode stopped working

I'll write a patch.

Assignee: nobody → hsivonen
Status: NEW → ASSIGNED

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

I'll write a patch.

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

Attachment #9419140 - Attachment description: WIP: Bug 1913022 - Restore the network.IDN_show_punycode pref. → Bug 1913022 - Restore the network.IDN_show_punycode pref.

(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.

Pushed by hsivonen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/1400784cd682 Restore the network.IDN_show_punycode pref. r=necko-reviewers,valentin
Status: ASSIGNED → RESOLVED
Closed: 2 months ago2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 131 Branch

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?

Flags: needinfo?(pstanciu)

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

Flags: needinfo?(pstanciu)

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

Status: REOPENED → RESOLVED
Closed: 2 months ago2 months ago
Resolution: --- → FIXED

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/
  1. Observe that the URL bar says https://www.аррӏе.com/
  2. Via about:config, flip the pref network.IDN_show_punycode
  3. Reload the page from step 1
  4. 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
Attachment #9419271 - Flags: approval-mozilla-beta?
Flags: qe-verify+

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 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.

Attachment #9419271 - Flags: approval-mozilla-beta? → approval-mozilla-beta-

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

(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.

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

QA Whiteboard: [qa-triaged]
Attachment #9419271 - Flags: approval-mozilla-beta- → approval-mozilla-beta+
Attachment #9419271 - Flags: approval-mozilla-beta+ → approval-mozilla-beta?

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.

Attachment #9419271 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

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.

Status: RESOLVED → VERIFIED
Flags: qe-verify+

(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.

(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.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: