5 ms·

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 ver

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.

justinclift 8y ago
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.
- _Microft 8y ago
  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).
  - detaro 8y ago
    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.
bromuro 8y ago
Every request is a way for tracking you. We don’t want to be tracked when we open Firefox.
- thatguy0900 8y ago
  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.
justinclift 8y ago
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...

justinclift 8y ago

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.

_Microft 8y ago
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).
- detaro 8y ago
  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.

bromuro 8y ago

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

thatguy0900 8y ago
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.

justinclift 8y ago

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