Closing Web Browser Windows Doesn’t Close Connections

What days is going over these connections though? If this is socket reuse then the answer is no data at all, so who cares.

Yeah, it's not clear to me why this is an issue. I don't think there are any privacy implications. It's not as if the code on the closed tab kept running, and kept communicating with the server.

"What [data] is going over these connections though?"

That's my question! Are you comfortable with not even knowing?

"If this is socket reuse then the answer is no data at all"

Metadata is data. That has become painfully clear in recent years. Notice how Google now seems ok with losing 3rd party cookies; could they be planning to track us in other ways?

"I don't think there are any privacy implications."

If there are no privacy implications, then why do private/incognito windows close the connections?

"It's not as if the code on the closed tab kept running, and kept communicating with the server."

Do we even know that for certain at this point?

Let me also suggest that keeping connections open while the window is open is not necessarily ok either. Is there any reason for a site to maintain a connection to your computer after all of the page resources have finished loading? The reason I highlighted window closing behavior is that it's unexpected to users, and it's also easy to detect once you start looking for it.

Again, the reason for this behavior is undoubtedly "speed", but we need to have a real debate about the costs and downsides of this speed, and ask whether the tradeoffs are worth it. Speed is not the only consideration.

>Do we even know that for certain at this point?

I would go with "yeah" here. This is an actual issue for developers, where it is very difficult to do cleanup tasks for web applications when the user closes the browser window. Often the best option is to ping the server regularly, assume the user closed the window when the pings stop, and do the cleanup then, precisely because browsers are generally pretty good at valuing user privacy over expressive power for developers.

>Is there any reason for a site to maintain a
>connection to your computer after all of the
>page resources have finished loading?

Performance, I guess? There are very few modern websites that load all resources, and then don't talk to the server again.

Plume said: "it is very difficult to do cleanup tasks for web applications when the user closes the browser window"

As a web developer, I'm not sure what kind of "cleanup tasks" you mean. Besides, wouldn't this be better served by closing connections immediately, like private browsing windows do, instead of deferring for an unknown amount of time?

"There are very few modern websites that load all resources, and then don't talk to the server again"

I would think that nearly all websites, though, should stop sending resources once the user has closed the window.

"As a web developer, I'm not sure what kind of "cleanup tasks" you mean"

Releasing server-side resources, for example.

"I would think that nearly all websites, though, should stop sending resources once the user has closed the window."

I don't see how this relates to the point Jeff made, to which I responded.

Just because most server-side web developers don't know about and may not have access to socket state information in their server-side stack doesn't mean that no one does or that no one could.

One issue I can see is that it gives middlemen visibility into your browser state; it's one more signal an ISP can measure and track.

If I'm not mistaken, this isn't new: I remember encountering this problem back in the 10.4 - 10.5 days. I thought the tool I was coding needed to know which network accesses were for which page, and it wasn't obvious when a page stopped making requests: Javascript from previous pages still seemed to request connections some time after the user had navigated to another page.

Eventually I found that ignoring the problem usually worked sufficiently well for my purposes, and I gave up on tracking down the problem. I never figured out when Javascript code was well and truly flushed by WebKit because it was hard to replicate: the Javascript code served in "advertisements" seemed to be amongst the most gnarly and prone to doing such things, but that meant that each new page load gave me a different random advertisement which might or might not include code that outlived its welcome.

"Just because most server-side web developers don't know about and may not have access to socket state information in their server-side stack doesn't mean that no one does or that no one could."

Sure, the specific point I made was that there is no more communication once the window closes. I'm still not seeing an actual practical way in which this is a problem.

Yeah, this just looks like keepalive.

I'd be all right with closing the socket once the last outstanding connection to a first-party host was made by a closed non-private tab. For that to work, you have to record connections made by every tab. I don't think getting rid of connection reuse entirely is such a great idea because then you'd miss the most obvious benefit during origin page loads or simple navigation. There again, Gemini does, it's modern and privacy-focussed, and probably had the same concerns in mind, so maybe we should at least consider the possibility that requests during a session leave a trail worth hiding. As long as a private mode exists with maximum paranoia, I'd be all right with a compromise though; ultimately it's a trade-off, and speed is kinda nice ...

me: "As a web developer, I'm not sure what kind of "cleanup tasks" you mean"

@Plume: "Releasing server-side resources, for example."

That's just another way to say "cleanup tasks". Can you be more specific? I've been a professional web developer for 15 years and I've never needed such a thing.

@Plume: "I don't see how this relates to the point Jeff made, to which I responded."

We're getting into "X disagrees with Y disagrees with Z disagrees with ..." territory and I can't follow what you're claiming. Can you explain what kind of architecture you're talking about where it's beneficial for the server to keep a connection open after the window closes?

Wouldn't shock me if it wasn't related to protocols like WebRTC - just do some reading into "modern" stuff like that. Yikes...