From:  Patrick McManus <>
Date:  17 Mar 2016 22:38:31 Hong Kong Time

Re: A network-change detection and IPv6 quirk - on Windows


Hi Christopher,

On Thu, Mar 17, 2016 at 8:38 AM, Christopher Barry <> wrote:

> Should all network applications behave in this manner,

Only firefox (and gecko) is in scope here.

myriad implementations and redundancies? Is it in fact the domain of
> network *applications* to do this?
when necessary to ensure security, performance and usability applications
have always availed themselves of customizations beyond that provided by
the operating system. Firefox will do so on a case by case basis.

> Isn't this a systems function that should be left to the system itself?

That's always a judgment call. I mean we have our own set of PKI roots
bundled in firefox - so we aren't purists on the issue when we think we can
bring value.

> I seem to remember another out-of-scope foray where FF was using
> built-in dns server addresses behind the user's back a while ago,

I don't believe that is true - I would be interested in any citation you
had. That being said, we don't do that because at this point in time we
don't think it would be a good user experience. If we had a model where it
added value we would consider doing so openly and likely with user choice.

> still happening too? Why is FF going here? Why does it *need* to? Do

sometimes the underlying services and even standards they implement have
trouble at web scale - especially at the tail.

The issues Daniel are working with are correlated with network mobility -
that's why he is using changes in addressing as a proxy for mobility. This
can manifest itself in some odd ways: TCP can simply stall for minutes (or
hours) before figuring out the connection isn't working any more, that's a
bad user experience. Your proxy selection may or may not be relevant after
such an event. Same thing with your DNS cache because of split DNS. Some
unauthenticated data that you used in one location might want to be flushed
from cache when you move, etc.. We see this when you wake from a sleep with
an open H2 session - an attempt to reuse it can just hang for a long time
without any feedback Daniel's code provides a framework for when more
aggressive timeouts are appropriate.

And we are actively working on this stuff in the standards space where

> This kind of stuff is out-of-authorized-and-expected-scope for a user
> program, and frankly is more than a little creepy. I know others will
> share this concern if/when they are aware of it.
I don't share your concern that awareness of local addressing is out of
scope for a user space application. Indeed, enforcing security around that
kind of thing is the role of the operating system and we wouldn't attempt
to subvert that. The OS provides an unpriv'd interface to learn about
address changes and we're listening to it - not a big deal.