2049252 - Move captive portal detection to new domain

Status: RESOLVED FIXED

(Cloud Services :: Operations: Miscellaneous, enhancement, P3)

Description

[Simon Friedberger [:simonf]]

We want to enable HSTS preload for firefox.com (see bug 1551966) but since it hosts detectportal.firefox.com and the HSTS preload list requires includeSubdomains we cannot add it.

We need to decide on a URL. Some questions:

1. Does the URL have to be popular to not get blocked?
2. Should we have multiple URLs and fall backs?
3. Should the URL change to not get blocked/redirected? Maybe, random subdomains?

I don't see a good reason for any of this but at least we have had weird issues like bug 2036862.

Comment 1

[Valentin Gosu [:valentin]]

(In reply to Simon Friedberger [:simonf] from comment #0)

We want to enable HSTS preload for firefox.com (see bug 1551966) but since it hosts detectportal.firefox.com and the HSTS preload list requires includeSubdomains we cannot add it.

We need to decide on a URL. Some questions:

1. Does the URL have to be popular to not get blocked?

I don't think so.

2. Should we have multiple URLs and fall backs?

That's probably overkill. If a network blocks one captive portal domain, it would probably block all of the ones we have.

3. Should the URL change to not get blocked/redirected? Maybe, random subdomains?
   I don't see a good reason for any of this but at least we have had weird issues like bug 2036862.

I would argue that no. Blocking random subdomains is trivial.
If a network does this by mistake (like it seems to happen in bug 2036862) the best course of action would be to contact them and request they fix their network, rather than trying to bypass a broken behaviour. But hopefully bug 1898891 will mitigate the issue.

Comment 2

[Jon Buckley [:jbuck]]

Once someone has picked a domain (not it!) it can be added to our existing captive portal infra easily. If you need to purchase a new domain, please file a ticket in https://mozilla-hub.atlassian.net/browse/IO (and don't mention the domain in public tickets, people snap them up before us when that happens). If you need help adding the new domain to the captive portal, please ask for assistance in Slack #mozcloud-support or file a ticket in https://mozilla-hub.atlassian.net/jira/software/c/projects/SREIN/form/1344

Comment 3

[Simon Friedberger [:simonf]]

New domain seems to have been purchased. Can you add it to the captive portal endpoints, Jon?

Comment 4

[Jon Buckley [:jbuck]]

PR up in https://github.com/mozilla/webservices-infra/pull/11740

Comment 5

[Jon Buckley [:jbuck]]

My PR has been merged and the service is now active:

% curl -v http://firefox-portal-detection.com 
* Host firefox-portal-detection.com:80 was resolved.
* IPv6: 2a04:4e42::347, 2a04:4e42:600::347, 2a04:4e42:400::347, 2a04:4e42:200::347
* IPv4: 151.101.129.91, 151.101.1.91, 151.101.193.91, 151.101.65.91
*   Trying 151.101.129.91:80...
* Connected to firefox-portal-detection.com (151.101.129.91) port 80
> GET / HTTP/1.1
> Host: firefox-portal-detection.com
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 200 OK
< Connection: close
< Content-Length: 8
< Server: Varnish
< Retry-After: 0
< Content-Type: text/plain
< Accept-Ranges: bytes
< Date: Sat, 18 Jul 2026 16:20:39 GMT
< Via: 1.1 varnish
< X-Served-By: cache-yyz4525-YYZ
< X-Cache: MISS
< X-Cache-Hits: 0
< X-Timer: S1784391639.258305,VS0,VE0
< Cache-Control: public, must-revalidate, max-age=0, s-maxage=3600
< 
success
* Closing connection

Comment 6

[Valentin Gosu [:valentin]]

Attachment: Bug 2049252 - Move captive portal detection to new domain (firefox-portal-detection.com) r=#necko

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/0c0064798418
https://hg.mozilla.org/integration/autoland/rev/b99f279dd439
Move captive portal detection to new domain (firefox-portal-detection.com) r=necko-reviewers,jesup

Comment 8

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/b99f279dd439

Comment 9

[Valentin Gosu [:valentin]]

Release Note Request (optional, but appreciated)
[Why is this notable]: Domain historically used for captive portal detection has been changed to firefox-portal-detection.com
[Affects Firefox for Android]: Yes. While on Android the Operating System is in charge of captive portal detection, we also use this domain to check connectivity (IPv4, IPv6, DNS).
[Suggested wording]: Firefox now uses firefox-portal-detection.com instead of detectportal.firefox.com to detect captive portals and check network connectivity, so network allowlists referencing the old domain need updating.
[Links (documentation, blog post, etc)]:

• https://support.mozilla.org/en-US/kb/captive-portal/
• https://firefox-source-docs.mozilla.org/networking/captive_portals.html

Comment 10

[Ryan VanderMeulen [:RyanVM]]

Added to the Fx155 relnotes.

Comment 11

[Simon Friedberger [:simonf]]

Valentin, could you add a patch which adds the new URL on https://firefox-source-docs.mozilla.org/networking/captive_portals.html as well?

Comment 12

[Valentin Gosu [:valentin]]

Attachment: Bug 2049252 - Update source docs with the new captive portal domain r=simonf

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/dc30e4f50072
https://hg.mozilla.org/integration/autoland/rev/b6383f7ac6bf
Update source docs with the new captive portal domain r=necko-reviewers,kershaw

Comment 14

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/b6383f7ac6bf

Comment 15

[Daniel Holbert [:dholbert]]

FWIW, Martin (:mt) ran into an issue on the Adobe corporate office's guest-wifi-network that might have been caused by us using this new domain. See bug 2036862 comment 10 through bug 2036862 comment 17 (and perhaps more comments afterwards, if more are added).

(Superficially, it seems likely that this particular Adobe corporate guest-network is redirecting firefox-portal-detection.com to an error page, while letting the rest of the internet largely work just fine. I don't think we know right now whether the old detectportal.firefox.com/canonical.html URL would have hit the same issue or not; but it's possible they have a broad allow-list of sites that lets *.firefox.com resolve just fine, but rejects our brand-new firefox-portal-detection.com domain as unrecognized/untrustworthy.)

Comment 16

[Frederik Braun [:freddy]]

Aside: It's great that we finally managed to change the domain and that we updated the SUMO articles. But I think this should have been in our release notes as well.

Comment 17

[Sylvestre Ledru [:Sylvestre]]

(In reply to Frederik Braun [:freddy] from comment #16)

But I think this should have been in our release notes as well.

it is
Firefox now uses firefox-portal-detection.com instead of detectportal.firefox.com to detect captive portals and check network connectivity, so network allowlists referencing the old domain need updating.

https://www.firefox.com/en-US/firefox/155.0beta/releasenotes/