Closing web browser windows doesn't close connections | Hacker News Reader

Closing web browser windows doesn't close connections

lapcatsoftware.com

276 pointsalsetmusic153 comments

This post is basically ‘I observed some behavior and I don’t understand it, so here’s some speculative fearmongering.’ The browser is not letting trackers “continue to "keep tabs" on us in some way”; about the only info that the site can get is that if the connection drops unexpectedly then maybe the user entered a tunnel. (In fact, closing the connection the instant the user clicks 'X' would actually give the site more information.) The reason that the behavior isn’t communicated to users (and that “Jeff is a nitwit”) is because it’s utterly irrelevant to them, and not really a privacy concern. Just because the connection was used to load an analytics script at some point in the past does not mean that the TCP socket pair somehow becomes an instrument of spying.

Incidentally, there actually is some work being done to reduce the need to hold on to these connections. 0-RTT (zero round-trip-time) session resumption with QUIC (HTTP/3) should allow the browser to instantly pick back up a previous communication without needing to hold a socket open in the meantime.

So if I close the browser then open a private browsing window to the same site, the destination can't use that open connection to determine positively that the non-private window and the private window to the same IP are definitively the same machine?

Sites might use IP address information to guess that the sessions are correlated. But they can do that whether or not the connection remains open.

Sure, but this removes any guess work on their end. It's the same connection.

Do you have evidence that connections opened in non-private mode are re-used in private mode?

>> Sites might use IP address information to guess that the sessions are correlated. But they can do that whether or not the connection remains open. [emphasis added]

Responding to OP's "whether or not the connection remains open". IFF it remains open, then it's no longer a matter of correlating.

There is nothing to correlate unless the connection is actually re-used in private mode. Merely leaving an unused connection open doesn't change much of anything.

Why are you belaboring the obvious? Are you simply after arguments? Of course, the concern is switching to private mode and visiting the same site. What else?

Neither you or anyone else that I've seen have provided any evidence that the same connection is re-used.

Imagine this scenario:

1. User visits a site in normal mode. Browser opens connection A. Browser uses connection A to fetch the site. Browser leaves connection A open.

2. User opens private mode. User visits the same site. Browser opens connection B to fetch the site.

How does it matter that connection A was left open if some other connection was used to fetch the site in private mode? If that's not the case, then its a big deal - but that requires some sort of evidence and not just wild hand waving that it could be the case.

Am I to understand you do not know what “IFF” means?

https://en.wikipedia.org/wiki/If_and_only_if

Iff it remains open is irrelevant. It's only relevant iff it is reused - and I'm still waiting for evidence of that.

No, because the connection pool for private and non-private windows are not shared. So when you open the site in a private window, a new connection is created.

There are other ways of correlating those connections (like browser fingerprinting), but the connection pool isn't a problem.

I can't speak for certain, but I believe that's correct, the socket pools are separate for private browsing vs non-private for that reason.

The server sees your IP regardless of your browser being in private mode or not. And yes if they have the IP in the logs and have them accessible to query, they could easily correlate all requests from the same IP and determine what they were accessing inside private windows or not.

CGNAT is more common than you'd think. The IP address alone is not a definitive indicator it's the same user.

Sure, but why risk it. If you're really paranoid about browsing anonymously then use Tor.

There's a gulf between the "I don't want companies tracking me" use case of the OP and the "If I get caught spying I'll be executed" use case that Tor addresses.

But each request is logged if an ip is reused any website will be able to link your requests.

Naturally there is.

That gulf is readily filled with a garden-variety VPN, which works if you're doing the kind of thing where you don't want the web site keeping tabs on you but figure the VPN's reputation is enough to keep them logging your connection and doing something nefarious with that information.

For the uninitiated, don’t use tor to solve the second goal here without doing proper research. Just using tor is not effective against nation state actors:

https://www.theguardian.com/world/2013/oct/04/tor-attacks-ns...

This is privacy nihilism. Tor is effective against many state-level actors.

Not everyone is the five eyes, and Tor is useful in some limited cases against them, too.

If your failure mode is execution, it's best not to count on it unless you understand what you're doing.

Yes, I would hope that anyone whose freedom or life is at risk isn't depending on Tor to keep them safe without knowing what they're doing.

In fact, I'd go one step further and recommend that if your freedom or life is at risk, then don't use computers or phones to do things that states might execute or imprison you for at all.

Can we please stop using the term paranoid to refer to people who desire privacy?

None of the major browsers reuse connections between private and non-private tabs

That isn't definitive at all. My phone and desktop have the same IP due to a dedicated VPN.

They just know that anyways in case you didn't rotate IPs via TOR or I2P.

Additionally, lots of analytics services do TCP fingerprinting.

So they likely know it was you, if you didn't change TCP window sizes, TTLs and options (which I assume due to web browsers reusing the native OS's tcp stack).

Also if you didn't use ublock0, they will get an even better footprint via fingerprintjs (most common) that's probably as unique as it gets across your commune without having to know your exact IP.

> In fact, closing the connection the instant the user clicks 'X' would actually give the site more information.

How so?

You now know exactly the moment that they left your site. (It’s not much more information, granted.)

I used to set points every paragraph in my blog, where once it came into the viewport would let me know how far down the page people got. It was very insightful to write better blog posts. Letting people know when someone closed a tab, changed networks, or who knows what with the network isn’t any useful information.

Because it would tell them exactly when the user clicked the "x" -- the exact point the connection was closed -- which the current behavior does not do, as it's probably not predictable (sanely or possibly at all) exactly when the 'x' was clicked based on when the connection was closed.

Not that that's particularly useful info. But technically it's more info revealed.

I think you can already do this using the unload event in the Page Lifecycle API and the Navigator.sendBeacon() function. It won't be reliable on mobile, though.

https://developer.mozilla.org/en-US/docs/Web/API/Navigator/s...

They'll know exactly when we stopped interacting with their website.

Imagine a phone system that didn't make an audible noise when the other person on the line hung up. At some point you realize that they've chosen to stop listening and you've been talking into to the void, but you don't know for how long.

Old phones didn’t tell you when someone hung up. It took a few minutes for the phone to make an annoying beep that there was no longer a connection. This used to happen quite a bit back in the day...

I remember it take a bit after someone hung up before you got the annoying beep beep beep beep.. but I don't remember it being minutes.. maybe like 30 seconds? 20?

you could usually hear the phone rattling into the cradle if it was that type of phone, and if so you would not if they just used thier finger to push down the disconnect/hangup switch..

I seem to remember you would get a dial tone when someone hung up on you too.. not immediately, that might take 8 seconds? and if you just left the phone off the hook listening to the dialtone after a while it would go to that super annoying loud beep beep beep thing..

Kind of like a warning that your phone was 'off the hook' and doing nothing - which meant you should hang it up if you wanted to be able to get a call or call out.

> I seem to remember you would get a dial tone when someone hung up on you too.. not immediately, that might take 8 seconds?

It's very dependant on where in the world you were. The dial-tone on hang-up thing that you get all the time in (older) movies and TV shows for example is because that's what happened in California (at least parts of, I forget the details) where movies were made. This didn't generally happen in other places.

Where I'm from IIRC you got a rapid beep. And the whole thing about the caller having to hang up was never a thing there either. Different places, different equipment.

There was also the cordless phones, some of which didn’t tell you the other person would hang up. I can remember talking to my girlfriend and taking her silence as her wanting a more in-depth description of whatever... only to have a phone ring in my ear halfway through it when she called me back.

It started taking longer in the 90s to 00s, I don't know why.

But back in the 80s if the other side hung up, they could pick up the handset again in a few seconds and keep talking to you, since it was a physically switched connection. But it didn't take too many seconds (maybe 10?) for the phone company switches to disconnect and throw a busy tone.

That's actually how phones used to work for the person who was called; the connection would remain until the caller hung up (or some fairly long timeout after the callee hung up). There were various party-tricks one could do that way (e.g. prep a phone with a friend calling you, hang up, then bet someone that if they give you a name, you can dial a person with that name).

Which was useful, if you had more than one phone. You could catch a call in the kitchen, put the phone down, and pick up another phone in the office or bedroom.

I agree in most cases it's not too bad.

But are there any packets still flowing? What if you close a site, then an attacker starts passively sniffing your traffic. If browsers didn't keep the connection open, the attacker wouldn't be able to know what sites you visited. By keeping the connection open, I think it allows the attacker to know the IPs of the sites you visited (and thus maybe know the sites).

> But are there any packets still flowing?

No (except TCP keepalives and a FIN when your browser finally decides to close the connection).

> What if you close a site, then an attacker starts passively sniffing your traffic. [...] By keeping the connection open, I think it allows the attacker to know the IPs of the sites you visited

Huh? Each TCP socket only connects your computer to a single host, and will only be reused if your browser needs to send more traffic to that same host. Your computer isn’t going to randomly send packets to the wrong website, whether or not you have an open connection to that website.

>No (except TCP keepalives and a FIN when your browser finally decides to close the connection).

These could reveal to future eavesdroppers what sites you visited in the past.

>Huh? Each TCP socket only connects your computer to a single host, and will only be reused if your browser needs to send more traffic to that same host. Your computer isn’t going to randomly send packets to the wrong website, whether or not you have an open connection to that website.

I'm talking about an attacker that is passively sniffing your traffic. For example someone on the same wifi network as you who is listening to your traffic. Not some random website.

The behavior is disabled in private browsing. That suggests some acknowledgement of a privacy risk.

What is creepy here is that a random website which I closed ten minutes ago get to know when I unplug my ethernet cable. I am happy to tell a website when I close it - that is its purview. But when I close a website I want it to be closed. Now I know it lingers.

>I am happy to tell a website when I close it - that is its purview.

No it isn't. As far as I'm concerned a well behaved website/page isn't even going to have a live connection once everything is loaded. Provided it's not a video stream or something. If data the user requested isn't actively being transferred there shouldn't be a connection.

>Provided it's not a video stream or something.

there are lots of "or something" out there to require live connections.

Yes, there are. But for a huge number of sites there isn't.

Subsequent page loads? SSL initiation is slow because of round trip times.

I'd take the "slow" load any day over live connections to the web page.

Not sure if a human could even notice it, when I load HN over SSL it is virtually instant.

HN honors `Connection: keep-alive`, so this probably does not mean what you think it does.

Even if I take that as an argument it is relevant during the initial load, while fetching the assets. (Also mind: reduce number of assets, improve caching of assets etc.) But for that the connection doesn't have to be kept up longer. For the next click it's almost neglectable.

Now we've gone in a circle. Because as was already said, if you're holding a connection open in case of future loads, the most private way is to always keep it open for the same amount of time.

By usage I disagree; I think most usage is rich content. Even news sites refresh their advertisements. (Of course, today they do a lot others, but I'm mentioning a case that most should agree is justified)

> As far as I'm concerned a well behaved website/page isn't even going to have a live connection once everything is loaded.

HTTP 1.1 specified the “Connection: Keep-Alive” header two decades ago, and it has been in widespread use ever since. It’s a fairly critical performance optimization.

Want to have some fun? Look into WebRTC https://webrtcforthecurious.com

I'd guess the reason it's disabled in private browsing is because when you close the private window it's supposed to clean up the tracks of what sites you visited while doing private browsing, not that it leaks more information to the site.

>What is creepy here is that a random website which I closed ten minutes ago get to know when I unplug my ethernet cable.

Not really, since the connections aren't kept around forever[1], and can be closed for a variety of other reasons (eg. closing the browser), so it's a really poor indicator of "ethernet unplugged". If anything, since nothing's being sent over the connection, it's impossible to distinguish between "ethernet unplugged", "computer going to sleep/hiberate", or "middlebox killing idle connection".

[1] https://news.ycombinator.com/item?id=26565134

I think the writer falls into the "privacy paranoid" category of users. Something vaguely looks like it could be used for nefarious purposes, so they imagine it must be for nefarious purposes.

Also as much attention as privacy gets, those users are far outnumbered by the performance oriented users. So it would be a mistake to kill a performance improvement for an imagined privacy improvement to satisfy (the even smaller segment of) privacy paranoid users.

> Something vaguely looks like it could be used for nefarious purposes

If it can be used for nefarious purposes, it will eventually be... so it should be considered a bug.

I'm not sure what world you live in...

“vaguely looks like it could” and “can” are not the same.

closing a browser should definitely close all connections associated with it... that is one reason why I don't use Google applications on Linux... because they (used to) keep a process running even when you closed the application (that was years ago and I don't know how it is today).

I just tried it and Chromium, at least, closes all processes when the last window is closed.

But the linked post is talking about a Mac, where the expectation is explicitly that the application keeps running even if it has no windows at present; if you want the process to go away then tell it to quit.

But do they still have that update process running constantly? It would be trivial to send the interesting information once the main process (chrome) is back in memory.

If you really want to close the browser then by all means exit the application. Otherwise these lingering connections are mostly worthless to anyone but a developer as they eventually drop within a few minutes.

Exactly. Users have unfortunately learned to fear the worst. And judging by many reactions here, presumable some from developers, a good number of developers don’t understand their users expectations of privacy and transparency.

have you seen https://www.nothingprivate.ml tech and internet are more hostile now days. company like google/fb will do anything to get user info legally or illegally, as the fine for bad behavior is usually slap on wrist.

I question the view that being privacy and performance oriented are at odds. In practical terms, there is likely to be some correlation as surveillance often uses more client-side resources.

The post is written in a way that might mislead some into thinking that 1) connections are kept after closing the browser, 2) connections are kept indefinitely.

This is not true:

- Firefox keeps it for ~2 minutes and Chrome for ~5 minutes [1].

- Note there's nothing special about closing a browser window. It's the same as closing a tab, from browser's perspective. Many things are kept for a while in memory as well.

[1] https://fastmail.blog/2011/06/28/http-keep-alive-connection-... (blog post is 10 year old but the values were the same last time I checked)

> Note there's nothing special about closing a browser window. It's the same as closing a tab, from browser's perspective.

This is definitely a non-obvious behavior. Browsers historically were tied to their windows - if you closed them all, there was no browser process running anymore. This seems to have changed some time ago, and doesn't seem to be well-communicated to the users.

What I mean is: when you have n>1 windows, and close one of them, it's a non-event (unless it was last window / last incognito window). You can even revive the closed tab/window (in Firefox even an incognito tab). By default in Firefox you can revive 25 last closed tabs IIRC (configurable).

Window is just a different UI for a tab. Closing a tab drops some resources from memory, but not all / not immediately.

When you close last window, then you close the whole browser, and the story is different. Closing whole browser = dropping all memory, connections etc.

Note in particular: when you have n>1 incognito windows, they share in-memory cache, cookies etc. (Incognito tabs put more restrictions on certain things than normal tabs, for example no disk writes, but unless you close all incognito windows, stuff still lives there in memory).

Yes, what I mean is what happens when you close the last window. I've been surprised to discover over the past year that both Chrome and Firefox sometimes linger in the background. In case of Fx I suspected it's a bug; Chrome on Windows creates a tray icon under some conditions, that remains after all Chrome windows are closed, so I assume it's deliberate.

Hmm never experienced that. Do you have some PWAs installed by any chance?

I know that Opera does stuff like that (some "speed launcher") though.

Do you have chrome://settings/system Continue running background apps when Google Chrome is closed enabled? I see this pref on Linux and Windows, but not Mac. I believe it's enabled by default…

Note that the article author is on macOS (using Safari). On macOS, closing the last window does not necessarily close the application and this is an established pattern.

TIL, thanks!

>This is definitely a non-obvious behavior. Browsers historically were tied to their windows

Maybe in Windows, but as long as OS X has been around, and maybe in classic MacOS (Not sure, wasn't a user) applications have been uncoupled from their windows. Closing the last windows has never closed the application. This isn't surprising, and while it's not obvious, it's not like browser are doing something different than any other application.

In my opinion, this has always been a feature of MacOS. I can close the last window of an application without quitting the application (requiring startup again if I want to open another one).

Yeah, OS X copied this behavior from classic Macs. It’s worked like this for over three decades now.

BTW: new cold connection latency over HTTPS is brutal, takes 4 RTT. Over high-latency connection, it can take much longer than server download time of the resource.

https://blog.cloudflare.com/introducing-0-rtt/

This is ongoing "communication" in the loosest sense right?

It keeps the connection open but it's not like the connection is being actively used to pass data, so surely the only information for the server is simply that the user is still there (and thus you could infer they haven't turned their computer off). That might be deeply interesting in some obscure edge cases but it's not sounding like anything that would keep me up at night. Or am I missing something?

Yes, exactly. There might be some keepalive messages to prevent timeouts, but unless the browser is explicitly instructed to make an HTTP request no data is passed.

Most http logs just store request info. It is quite possible to capture detailed connection info, but web logs at scale are not free and better deliver some value. Akamai for example only logs connection termination errors for failed transactions--and it needs a valid header to do so, or it will not get logged.

I am not too worried about the described behavior.

isn't this just a keepalive on the socket? no content actually being requested? If so I don't really see the problem. I had to write a reverse proxy the other day in nodejs to handle an unusual set of requirements that couldn't be satisfied by nginx\HAProxy and I did exactly the same thing - use an httpagent to keep connections alive to clients for a period of time (I think I chose 10 minutes or thereabouts) - without it sequential requests are about 10x slower due to SSL key calc overhead.

Wait until Jeff hears about Service Workers. :)

That was my immediate impression as to what was going on. This guy doesn't know about service workers...

What's the deal with service workers? I read up on them and do not see how they keep connections open when the page is closed.

Service workers run in the background independent of any website pages open.

So your computer can get slower without the hassle of you having to actually install anything!

They do not, though. Chrome terminates any idle (or too-busy) service workers after some time.

For the uninitiated:

1) uMatrix can block these.

2) about:serviceworkers lets you manage/remove individual ones.

3) about:config key dom.serviceWorkers.enabled lets you disable the whole thing altogether.

edit: fixed #3

Thanks for "about:serviceworkers", found around 30.

thank you, I learned about service worker lately while doing some web development(not my usual cup of tea) and I backed off and used a rss feed instead because I found modern web too intrusive/google centric. Just disabled service worker in my firefox (+no script)

I hadn't heard of Service workers until now. I'm fairly privacy conscious and it's become such a hassle trying to keep up with these measures. It seems every other month there is a new feature I need to know to disable in Firefox. I'm so tired of it. How does one keep track of all this without having to be a professional web dev?

>How does one keep track of all this without having to be a professional web dev?

I've got some bad news here.

I would suspect you'd have to keep up with the browser developer's pages as well as several security blogs. AKA just about impossible.

ublock can inject this to every opened page before js starts running

    delete Object.getPrototypeOf(window.navigator).serviceWorker
    delete window.ServiceWorker
    delete window.ServiceWorkerRegistration
    delete window.ServiceWorkerContainer

I'm don't think "keeping the connection open" has the consequences or effects the author thinks it has.

(edit: the other comments here overwhelmingly agree with me. How did this get so many upvotes to get on the front page I wonder?)

It's still there, but I don't know if it works since it's been deprecated, but for Chrome, see: chrome://net-internals/#sockets

There's buttons there to close sockets and flush socket pools. I imagine this also means there's an API somewhere you could call from an extension.

I thought that this would talk about Chrome, but I am not surprised that it is about Safari...

Not sure why this is surprising. The author is using macOS where closing a window almost always just closes the window while the application itself continues to run.

Browsers maintain active connections for a number of reasons, the main two these days being notifications and service workers.

If you want to kill the connections then terminate the application via Cmd+Q or the App menu.

Depends. Safari will re-use a whole TLS session even if you change hosts/origins (if the IP address/port is the same).

That's just a bit too much in my book. Nevermind that it randomly breaks TLS client certificates selection, because pre-existing TLS session may have been started with a different SNI, and you don't get a chance to re-negotiate TLS session parameters based on SNI. Some websites just randomly break depending on time passed from last visiting another hostname/website served on the same multi-host/load balancer.

Hopefully someone will find a way to abuse this, so that they stop doing it. I had enough of the misdirected request 421 errors from nginx already, due to this.

Not sure what is the point they are trying to make. Specifically, I don't see any strong argument tying not closing persistent connections right away to any tangible privacy concern - seems like the post considers it an assumption.

Is for performance: Re-use already established connections. It is common on the server side as well and with other TCP clients beside browsers.

Isn't this because Mac keeps the app open even after all the windows are closed?

I wonder if this explains the occasional "Ghosts in the machine" behavior I've seen in Fiddler. Hoo boy.

If this type of BS bothers you, check out the Gemini protocol. Basically a very simple browser concept that cuts out all of the BS. No JavaScript, cookies, secret connections, ads, etc. It's mainly just a simplified markdown over TLS.

Because it's so simple, it is possible for any programmer to make their own client. Unike with web browsers which require you to basically implement an entire operating system. That means if you don't like something a client is doing, it's not a problem finding another good one.

I haven’t looked at the protocol but how does it prevent ads?

Well, maybe look at the protocol. It doesn't strictly prevent ads, but it makes it a lot harder. And for example since there is no JavaScript, there is no way to pop open another window, or freeze up the page loading an ad. In fact, most clients don't even display images inline, since images aren't part of the spec. There are no cookies for tracking because there are no cookies.

I'll admit that I haven't looked closely at Gemini, but I don't understand how it solves this qua protocol: keepalives and socket reuse are an extension of HTTP that every major client agreed upon as a performance win, and Gemini has response headers[1] that clients could easily use to advertise similar functionality.

Same goes for any number of terrible parts of the modern web: the fact that Gemini doesn't have them now is a function of its niche status and community, not some fundamental restriction. That's how HTTP 1.0 started as well.

[1]: https://gemini.circumlunar.space/docs/specification.html

There's no content-length header in the response. The server has to close the connection to signal the end of the response body.

> There's no content-length header in the response.

I'm not sure I understand -- what's stopping me from adding one? One of Gemini's design goals seems to be client diversity and allowing clients to interpret responses on their own terms.

Edit: To be even more explicit about it: the Gemini specification doesn't include any language that says that clients and servers MUST not use the "meta" field or their response bodies to negotiate additional functionality. The observation that nobody in the Gemini ecosystem currently does is tantamount to the observation that nobody has bothered to yet, just like with HTTP 1.0.

>One of Gemini's design goals seems to be client diversity and allowing clients to interpret responses on their own terms.

No, the design goal is the exact opposite of that. The protocol is intentionally designed to be non-extensible so that other features that go against its spirit are not added.

You can of course add a content-length header to your server and write your own client that parses it, but you wouldn't be writing a Gemini server and client any more.

https://gemini.circumlunar.space/docs/faq.gmi goes in great length about this in section 2, and even specifically about (the lack of) content-length in section 2.12

I tried it, it's somehow nice but:

- not fast enough yet (I expect leaner protocol and data => instant)

- navigation is still crude, directories and text are.. not ideal so far

I'm open minded, it's not a blind critic of gemini (I wish projects like that to succeed, and for instance, I use dillo regularly) but using it threw me off a little bit.

A comparative HTTP page ("comparative" == "same text content, no non-text content, no XHR or JS to delay-load content") is almost always going to be faster. Every gemini page request has to set up a brand new connection, ie brand new TCP handshake and TLS handshake.

It's not clear what problem Gemini solves.

Some webmaster willing to host a Gemini server could also setup an nginx serving static markdown files with no cookies/js/... and the privacy conscious client could use lynx to browse it.

Tell me without clicking if an http(s) uri requires javascript and/or a graphical browser to render properly. Then tell me the same thing for a gemini uri.

I can go host a gemini server with javascript out of spite if you want.

There is no expectation of a gemini server that it can run arbitrary code on the client. There is for an http server. This changes what works and what doesn't work.

Yeah but there's also no expectation that images will work, so "this document won't work right unless you have certain client features" wouldn't even be unique.

So I disagree with your earlier statement even if we exclude javascript. No, I can't tell you without clicking if a gemini URL requires a graphical browser to render properly. Without even being cheeky or pedantic.

I actually think its kind of useful for privacy, as it stops the page from monitoring exactly how long I really had it open, at least, through that avenue.

The important question (imho) would be: What can be done with this still open connection after the client closed the tab?

* Might the server use it for anything without my consent?

(e.g. hacking the sandbox as this state of the browser might open another code-tree with yet unknown security-bugs, or might still running js-scripts keep going in the background even after closing the tab?)

* Might the browser use it for anything without the server's consent?

On the Mac: Closing a window just closes a window. Quitting the application closes all connections sure and true.

Connections can be shared between browser tabs, so two tabs may use the same connection to a single origin.

This obviously has implications for privacy e.g. if that connection is to a third-party so Firefox and Chrome are starting to partition network connections.

If you capture a Netlog in Chrome, you'll a NetworkIsolationKey (?) entry, and consisting of top-level frame origin, frame origin, request origin (or similar) that's used to key the connection an limit it's use

So would this be a sure fire way to detect incognito mode?

No, there is no session sharing between private and non-private tabs.

Right, but if your client immediately kills a session, and that client also needed new cookies, maybe that client was incognito. If the session stays open longer, maybe it was a legit new user.

isn't it a little late to do anything with that knowledge if the user is already gone from your site?

if they posted something and they're a bot, then you want to take that stuff down at some point.

But there's a measurable difference in the browser's behavior between the two modes, so you can determine which one is being used.

Detecting incognito mode always was quite easy.

There are web APIs which suggest they guarantee this. How are you supposed to get notifications you opted into if closing the tab turns off its network access? Stuff that happened in your local tab as a ghost?

Edit: for real though if you’re using chrome or any equivalent browser with its own internal task manager, go on into it and kill everything except the parent task as often as you like. It’s great.

Notifications aren’t done by the browser holding open a socket to individual sites; there’s a somewhat complicated protocol involving a service run by the browser manufacturer.

I’m not aware of any web APIs that explicitly require the browser to hold idle connections alive in a socket pool (server-sent events/websockets are a different matter; but they involve an active worker of some description—and last I knew weren’t available in service workers); this is purely a performance optimization.

I’m sincerely sorry that I so poorly formulated the joke.

I believe this happens all the time in iOS Safari on Reddit. The network “spinner” in the taskbar, top right, will go forever and ever after all tabs are closed. It’ll stop when Safari is not active, and start again when Safari is brought back. I have to kill Safari (long swipe up to show all “open” apps, the. Flick it off the screen) to make it stop.

Safari also automatically downloads pages in the Reading List and occasionally updates favicons, if I remember correctly. No tabs required.

I must have hundreds of Reading List entries on this iPad. Surely they are not cached!

If you open a page, close it, connect to a VPN, then open the page again it will not go through the VPN.

Evidence?

At least with windows and openvpn, TCP connections that are already established prior to the VPN connection being turned on, continue to use the original adapter (rather than the VPN adapter). IIRC on linux the connection either gets reset or hung.

Interesting. On Mac OS, connecting to a VPN seems to terminate all activate connections for me pretty immediately.

This is a strictly "keep open" behavior, right? No connections are reestablished after being severed? I'm thinking about the implications for users who move on and off a VPN a lot.

What do they mean by “socket reuse” in this thread and in tfa? Http/1.x and ws protocols are (to my knowledge) not reusable by design. What else is there for reuse? Http/2+?

In HTTP/1 the server can send a header “Connection: Keep-Alive” to tell the client that it doesn’t have to close the socket after receiving the reply, and can send another request. (HTTP/2+ have this built into the wire protocol and don’t need the header.) If the browser doesn’t have another request to send immediately, it will still keep the connection in a “socket pool” for a while in case it needs to make another request to the server later.

I noticed this just yesterday, Azure Appgateway reported 6 active connections even though I was the only one using it and I had closed my browser.

Simple way to fix:

[x] Allow persisted TCP connections to websites

Make that an option in the settings.

isn't "continue running background apps when Google Chrome is closed" a far worse feature that is enabled by default?

An open socket/connection keep-alive isn't the site spying on you. Jesus. If you are really that paranoid then kill the web browser process after closing the tab.

That doesn't happen to me using Brave on Debian GNU/Linux.

Closing a window on OSX does not close the process. A horrible design choice that other operating systems do not suffer from.

This is how HTTP/2 works by design. There’s one TCP socket per host and the browser will make up to 6 parallel requests over it.

This is nothing to do with HTTP/2. This is just keep-alive behaviour, which applies to HTTP/1.1 just as much as HTTP/2.

Also the 6 is the maximum number of HTTP/1.1 connections most browser configurations will open per origin; HTTP/2 lets you have as many streams open on one connection as you like (up to 2³⁰ or 2³¹ if my memory serves me, but a billion ought to be enough for anyone).

It's possible to have two HTTP/2 connections to the same host.

Where the host is a 3rd-party then credentialed (stylesheets, scripts, images etc) and anonymous connections (fonts, fetch etc.) will be separate

It's also possible to have one connection to multiple origins with HTTP/2 (as long as they are on the same IP/port). I wonder if it's recommended though, since I've noticed this only on Safari so far.

Guess what you're seeing is connection coalescing at work - they also need to share the same cert AFAIK

Reply on news.ycombinator.com