Comment by wolfgang42 | Hacker News Reader

Comment by wolfgang42 | Hacker News Reader

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 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

> 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.

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.

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.

Reply on news.ycombinator.com