Articles index

Closing web browser windows doesn't close connections

March 17 2021 by Jeff Johnson
Support this blog: StopTheMadness, Link Unshortener, Underpass, PayPal.Me

Months ago I noticed something strange in the Little Snitch Network Monitor: Safari was still connecting to web sites after every window had been closed. At the time, I thought this was just a Safari bug. I brought the issue to the attention of some Safari engineers, who I had hoped would look into it. Since then, Safari has seen several software updates, and recently I remembered to check again to see whether the issue was resolved. Unfortunately I could still reproduce it, so I decided to investigate further. To my horror, I discovered that Chrome and Firefox were doing it too. That's too much a coincidence to be a bug, right? Could it be that web browsers are keeping open connections after windows are closed on purpose? If you don't have Little Snitch installed on the Mac (you should!), you can still see the open (ESTABLISHED) connections using the lsof (list open files) command-line tool in Terminal:

lsof -i TCP

You can also see the resulting web traffic by taking a packet trace with tcpdump or a GUI such as Wireshark.

My next thought was to compare regular browser windows with private (incognito) windows. And this made a world of difference! Closing the private window closed the connections associated with the window, in every browser. Thus, it seems pretty clear that this behavior must be intentional. Searching on the web, I found a very suggestive document about the Chrome networking stack:

Socket reuse: persistent TCP connections are retained in the socket pool for some time after servicing the request to enable connection reuse, which avoids the extra DNS, TCP, and SSL (if required) setup overhead imposed on each new connection.

The quoted document was written back in 2013. It's utterly predictable that some people will respond to my blog post by saying that this is nothing new, it shouldn't be a surprise, web browser socket reuse has been known for a long time, Jeff is a nitwit, yadda yadda. And it may be true that this was known for a long time in certain technical circles. After all, the web browser engines are all open source. Nonetheless, I didn't know it until very recently, and I'm "technically sophisticated". Certainly most technically unsophisticated web browsers users don't know it at all. And more importantly, this behavior seems contrary to the expectations of web browser users. Show me a user who closes their browser window after visiting a web site but expects that the browser continues to communicate with the site indefinitely. You might argue that these aren't private windows, and thus users shouldn't have any expectation of privacy, but are we really committed to the principle that "anything goes" in this case? In the default case, since private browsing is not the default for some reason.

I feel that many decisions made by web browser developers in the past — sometimes more than a decade ago — need to be reevaluated now that browsers are finally starting to care about user privacy. The browser vendors have always loved to compete and brag about whose browser loads pages faster, but the pursuit of speed at all costs can lead to compromises in other areas, such as privacy. And it's still too often the case that the browser vendors tend to favor the interests and demands of web developers over web users. Web developers and web users have very different ideas about what makes a "good experience".

What I find most disturbing about browsers keeping connections open after closing windows is that so many web sites load the same tracking scripts from third parties such as Google and Facebook, notorious privacy violators. It's bad enough that our web browsers connect to third parties "on our behalf" without our consent or knowledge, but it's even worse that those third parties can continue to "keep tabs" on us in some way (without browser tabs!) while we're not even actively web browsing. I don't yet understand the full privacy implications of these connections (which are invariably https and thus difficult to probe), but I think they need much greater public scrutiny than they have received, which heretofore seems to have been almost no scrutiny. It's time to shine a light on these dark corner cases.

Support this blog: StopTheMadness, Link Unshortener, Underpass, PayPal.Me

Articles index