1116907 - Investigate detecting firewall/antivirus blocking Firefox's network access and alerting the user to this issue

Status: UNCONFIRMED

(Firefox :: General, defect)

Description

[FredMcD]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141126041045



Actual results:

In the support forums, a lot of users complain that Firefox is not working. After,
it is discovered that the problem is with the proxy settings, or the firewall.


Expected results:

Since Firefox can't access the web, have an alert box come up saying so.
I think there is a ping in the about:config. That can be used to trigger the alert.

Comment 1

[:Gijs (he/him)]

Pulling this back out of Core as implementing this would be a UI responsibility. I don't think the networking code will have enough information about what's going on.

I like this idea. We could at least investigate to what extent we can detect these kinds of situations and warn the user. Not sure how it ties into existing self-support things. Verdi/dolske, do you know?

Comment 2

[FredMcD]

If I may offer a suggestion; when the user does something on a web page, the page sends a message
out onto the web. If this signal is not answered, Firefox could then send out a ping to several
different major sites. If none are answered, the user gets an alert saying so.

Comment 3

[Justin Dolske [:Dolske]]

Sounds like a variation of the existing bugs on captive portal detection (with the twist being that this is the "broken captive portal" case), or that it should be handled through existing network error pages (eg if you have a proxy configured but it's not responding).

Not sure that this bug is very actionable, covering a number of broad cases.

Comment 4

[Verdi [:verdi] Best to slack me]

I don't really have anything to add other than this has been a problem for a long time. I guess it's possible this could helped by the self-heal project but I'm not the expert. What Dolske said makes sense to me.

Comment 5

[Patrick McManus [:mcmanus]]

valentin has been doing some captive portal work on the platform side and probably has perspective to add here

Comment 6

[Valentin Gosu [:valentin] (he/him)]

While there's clearly some overlap, I think the issue here is a bit different.
Most firewalls that get in your way make connections time out, instead of hijacking them as a captive portal would. And differentiating between a bad AV/firewall, and a bad network connection could be quite difficult.

Comment 7

[:Gijs (he/him)]

(In reply to Justin Dolske [:Dolske] from comment #3)
> Sounds like a variation of the existing bugs on captive portal detection
> (with the twist being that this is the "broken captive portal" case), or
> that it should be handled through existing network error pages (eg if you
> have a proxy configured but it's not responding).
> 
> Not sure that this bug is very actionable, covering a number of broad cases.

Mm, this would be one way, but...

(In reply to Valentin Gosu [:valentin] from comment #6)
> While there's clearly some overlap, I think the issue here is a bit
> different.
> Most firewalls that get in your way make connections time out, instead of
> hijacking them as a captive portal would. And differentiating between a bad
> AV/firewall, and a bad network connection could be quite difficult.

because of this, I figured it might make more sense for Firefox to do some detecting of its own on the frontend side and figure out if/what firewall software is installed. I would hope there are separate Windows APIs we could use for this (it does after all yell at you if you don't use any firewall / antivirus). Alternatively, we could build hacky path/running-process detection stuff for the most common software, but that idea seems less attractive. Either way, that doesn't strike me as networking's job. :-)

Does that sound more plausible?

Comment 8

[Justin Dolske [:Dolske]]

I don't know what you're asking.

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to Justin Dolske [:Dolske] from comment #8)
> I don't know what you're asking.

Comment 10

[:Gijs (he/him)]

This discussion is now wildly out of date. We do currently have captive portal detection, but I doubt it'll detect cases where the proxy settings or a firewall are the issue. Nihanth, is there anything tracking expanding the captive portal stuff?

Comment 11

[(inactive) Nihanth Subramanya [:nhnt11]]

(In reply to :Gijs from comment #10)
> This discussion is now wildly out of date. We do currently have captive
> portal detection, but I doubt it'll detect cases where the proxy settings or
> a firewall are the issue. Nihanth, is there anything tracking expanding the
> captive portal stuff?

At the moment, no (even if there is, it'll be out of date).

Expanding Captive Portal is on the priv/sec roadmap for next year, but its priority and scope hasn't been discussed yet. Detecting firewall/antivirus could be interesting, I'll keep it in mind.