[millstone]

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.

[SahAssar]

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.

[gruez]

>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

[NaturalPhallacy]

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

[bryanrasmussen]

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

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

[johannes1234321]

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

[jhanschoo]

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)

[foota]

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

[johannes1234321]

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.

[Dylan16807]

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.

[tyfon]

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.

[WJW]

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

[tatersolid]

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

[EricE]

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