>I don't really see a problem with any of these?

You seriously don't have an issue with being fingerprinted and tracked every single time you open an application on your computer?

The point is that there should be zero. I should not have a single outgoing network request triggered by opening a web browser to a blank page until interacting in some way. The fact that we've lost this as a standard is terrifying to me.

The whole point of Firefox _is_ to make network requests. All of the features above aren't leaking your user data or fingerprinting you, they're assisting you in what the applications purpose is... to make network requests. Not to mention firefox is an open-source project, so you could go look at all the network communication it makes when it starts up. All of these options are configurable anyways.

I think you're looking in the wrong direction. Try the closed-source (or partial closed source) operating systems you interact with on a daily basis: Windows, Android, macOS, iOS- that's where you'll find the "fingerprinted and tracked every single time you open" sort of thing you speak of. :)

> The whole point of Firefox _is_ to make network requests.

Just to point out, that "the whole point of Firefox" is to make the network requests I want.

eg from my perspective it's a tool like (say) cURL that has a specific purpose.

It's a subtle difference, but an important one. :)

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.

>All of the features above aren't leaking your user data or fingerprinting you, they're assisting you in what the applications purpose is... to make network requests.

And you can prove this how?

All I'm saying is think twice before blindly trusting a tech company, because Mozilla is no longer the fun and friendly company we once knew. They are very much a rank and file data mining company now, generating tons of cash, and being infiltrated by CEO and marketing types.

What kind of objectionable data mining do you claim they do? The requests cited above don't exactly give much potential for that.

You can configure Firefox such that there is zero outgoing connection. That's better than everything else.

Firefox, like most mass market software, is designed for normal people.

Yeah, portal checking and update checking are surely things 99% of people appreciate.

Captive portal popup seems like an obvious UX improvement for 99% of people. I wonder how many people on HN even know how to trigger it if the browser didn't try to do it for you.

Update checking and over the air updates make obvious sense to me given that my mother and girlfriend will click "Remind me tomorrow" for years on the macOS update popup, and there's nothing user-friendly about making it so easy for users use old browser versions.

The rare user can turn both off if they want, so what's the big deal?

> I wonder how many people on HN even know how to trigger it if the browser didn't try to do it for you.

For anyone wondering: Just try and open literally any http page (note: no s). I use groklaw.net.

That's getting harder and harder as people add HSTS.

There's still neverssl.com, but with the most popular pages using HSTS like Google Facebook and Reddit, captive portal detection is essential for your average user.

Although I wish the IETF would make a standard for doing this at the network level as part of DHCP rather than the current ridiculousness we have. Captive portals are just the buggiest shit.

How often do you open a web browser to then not interact with it? Does it make a meaningful difference if it instead slows down the first request triggered by you to make the captive portal and OCSP checks, and moves the update request to a random time?

Honestly you sound paranoid. What if a dev wants to add instrumentation to make sure a page is loaded? What if you have some weird OS version, CPU, or kernel that might crash 1% of app opens?

A web page is not an app. It is a sandboxed rendered template that should not be able to crash due to a web page nor care about what OS, CPU or kernel the user is running. If a user wants to give that information away, then they should be prompted.

The "app" is Firefox, not the web page.