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.
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'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".
>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.
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)
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.
> 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.
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.
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.
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.
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.
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.
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?
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.
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.
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:
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.
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.
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.
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.
>> 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.
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).
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.
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.
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.
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.
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.
> 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.
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.
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.
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…
>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).
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.
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?
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.
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.
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.
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?
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)
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.
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'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.
> 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.
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.
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.
- 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.
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 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?
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
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.
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 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.
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.
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.
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.
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 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.
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.