1653951 - Whitelist by default .eth and .crypto TLDs

Status: RESOLVED DUPLICATE of bug 1635062

(Firefox :: Address Bar, enhancement)

Description

[neiman]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Install Almonit Browser Extension (https://addons.mozilla.org/en-US/firefox/addon/almonit/) and load 'almonit.eth from the address bar.

Actual results:

Firefox refers to search engine results of 'almonit.eth'

Expected results:

Firefox should have let the extension handle almonit.eth URL request.

Comment 1

[neiman]

Further motivation and details:

.eth and .crypto are Ethereum-based TLDs that are common for ipfs, swarm, Skynet, and other peer-to-peer websites. See a partial list of such websites in almonit or in blockscan .

Currently, to use those TLDs, users need to install a browser extension. However, since Firefox 77 (if I'm not mistaken) the browser forwards .eth and .crypto requests to search engine results, instead of letting extensions handle them.

The reason is that those TLDs are not in the public suffix list of Mozilla, neither there is a pref for whitelisting them by default.

This can be fixed manually by setting browser.fixup.domainsuffixwhitelist.eth and browser.fixup.domainsuffixwhitelist.crypto prefs to True. However, there is at the moment no browser extension API for setting it (see issue #1635062).

Due to the growing popularity of peer-to-peer websites, and the common usage of .eth and .crypto TLD, I suggest to whiltelist those TLDs by default in Firefox. This can be done by setting browser.fixup.domainsuffixwhitelist.eth and browser.fixup.domainsuffixwhitelist.crypto prefs to True.

Comment 2

[Shane Caraveo (:mixedpuppy)]

ni myself for next week in case no one else steps in.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 4

[Mark Banner (:standard8)]

Moving across to address bar for better visibility.

Comment 5

[Marco Bonardo [:mak]]

There are many providers of TLDs, if we start adding one, we'll soon end up getting requests to add all of them. These lists have a cost anyway, that's why we only picked the most commonly used one.
Are these TLDs recognized by any other major browser without modifications? Are these TLDs described in an RFC? Will these benefit a vast majority of our users?
I suspect the answer to these is "no", that imo pretty much boils down to bug 1635062 as a solution, if a WebExtension could register multiple TLDs at once (or at least the ones it cares about), it would provide a nice solution for these add-ons.
Note complete URLs (with a protocol) will work regardless, the only missing thing is typing a partial url/origin without a protocol and not ending with a / (just typing almonit.eth/ will solve your problem). We already provide solutions like delegating to a DNS and the prefs you pointed at. But those can't be integrated in a WebExt.

tl;dr: I think we should dupe this to bug 1635062.

Comment 6

[neiman]

Are these TLDs recognized by any other major browser without modifications?

They are recognized by Opera (1, 2). Personally I tried to use .eth domains with Opera in the past with moderate success.

Are these TLDs described in an RFC?

.eth is described in an EIP 137 (Ethereum Improvement Proposal), which is kind of the Ethereum version of RFC. There are many other documents describing the whole mechanism. If needed I could ask someone from heir team to provide it.

.crypto does not have something equivalent to RFC as far as I know.

Note complete URLs (with a protocol) will work regardless, the only missing thing is typing a partial url/origin without a protocol and not ending with a / (just typing almonit.eth/ will solve your problem)

Yes, I described it in the request. However, this "only missing thing" is quite crucial in the user experience in my opinion.

I don't comment on the remarks regarding bug 1635062, since I feel it is for Mozilla people to hold this discussion, not me.

Comment 7

[Shane Caraveo (:mixedpuppy)]

How likely is this whitelist functionality to remain in the long term? If we expose setting those to an extension api, it needs to be long lived.

Comment 8

[Marco Bonardo [:mak]]

Honestly I don't see it going away.

Comment 9

[Shane Caraveo (:mixedpuppy)]

In that case, I'm duping this over to the other bug.