Every one of the requests that 43920 listed in a request in service of you, the user. The first is to detect captive portals, which is something you'll find very important if you're behind a captive portal. The second is for OCSP certificate validation, which helps ensure your safety while browsing. The third is checking for updates, which again is for your benefit.

Don't get me wrong, I do agree with the 2nd two, though I haven't really thought through the first use case. :)

I'm mainly just replying to the poster that attempted to say that since Firefox already makes network requests, ~anything should be ok.

A captive portal is a login screen of a service that prevents other activity unless logged in.

My guess is that Firefox will not try to check for updates or other things if it notices that the detectportal-request was not successful (i.e. the user is not logged into the hotel-wifi or something like this yet).

It also then can prompt the user to go to the captive portal page and log in, without the other redirection methods of the captive portal breaking anything (e.g. if they spoof DNS responses to redirect you to the login page) or the user being confused why they can't use the web despite being in the network.

Thinking about that OCSP cert validation, that's done on a per-domain basis isn't it?

So... guessing here, that particular request would be checking if the domain for the Firefox update check itself has a valid cert.

If that's not what it's checking, hmmm...

Every request is a way for tracking you. We don’t want to be tracked when we open Firefox.

Then turn those off? These things are a tradeoff for usability, Firefox is trying to be competitive for the masses, I have a feeling your ideal Firefox would feel pretty clunky to someone who's not familiar with tech.