It’s bad enough that our web browsers connect to third parties “on our behalf” without our consent or knowledge, but it’s even worse that those third parties can continue to “keep tabs” on us in some way (without browser tabs!) while we’re not even actively web browsing
How would an open (idle) TCP connection still request updates over HTTP? The only contrived example I can come up would be websockets…
Also not sure if the author ever heard of TCP socket timeouts and how reliably unreliable they are.
It can be used to track you across websites, i.e. it is a short lived super cookie. Which also means that the state separation to protect against super cookies should help.
Even if it does not close the connection, such a protection would need to not reuse the connection for a different website with separated state. Also clearing state (“cookies” in UI speak) for the website for which the connection is left open needs to from then on never use this connection until it is closed at the normal time out. (Closing the connection before the normal timeout sends the information of this user interaction to the server, but I’m not sure if it is worth it to prevent that, so maybe it is fine to just close it early.)
I don’t know if this is all correctly implemented in Firefox, might be worth it to test and report any deviation as bugs.
I still don’t really follow. How would anything with cookies (HTTP, stateless) work via a shared TCP connection. I’m completely missing the point where this is not just a hanging connection (where the website under certain circumstances would assume you’re there for 20min longer than you are) and nothing else.
Also in the super cookie you mentioned wouldn’t the problem be the reuse of the connection and not the “not closing”?
Yes, it is the reuse. To reuse connections is the reason browsers doesn’t close connections immediately in the first place. Also anything where there is a noticeable behaviour difference, like closing the connection early on some user interaction where it would otherwise idle longer until close.
Half closed TCP connection, sometimes called hanging, have a different state than fully open, idling connections that can start to transmit at any time again. Normal http-cookies are per request, multiple requests can share the same connection. With HTTP keep-alive in serial fashion, with HTTP version >2 generally in parallel. Super cookies do not rely on http-cookies, sometimes they only track users by measuring timing differences.
If you never use that web browser again then it makes no difference. But if you reopen it, the process was not terminated (otherwise the connection would have been closed by the kernel), the connection is still idle and then gets reused.
When the connection to a third party gets reused for a request that is for a different first party than the one it was opened for, that can be used for tracking across the web.
Stale connections don’t really worry me; those new “notification” permissions do. I’d normally expect it to mean that the tab in question can show me desktop notifications while it’s open, but it actually means it can fetch stuff while it’s closed!
I don’t get it.
How would an open (idle) TCP connection still request updates over HTTP? The only contrived example I can come up would be websockets…
Also not sure if the author ever heard of TCP socket timeouts and how reliably unreliable they are.
It can be used to track you across websites, i.e. it is a short lived super cookie. Which also means that the state separation to protect against super cookies should help.
Even if it does not close the connection, such a protection would need to not reuse the connection for a different website with separated state. Also clearing state (“cookies” in UI speak) for the website for which the connection is left open needs to from then on never use this connection until it is closed at the normal time out. (Closing the connection before the normal timeout sends the information of this user interaction to the server, but I’m not sure if it is worth it to prevent that, so maybe it is fine to just close it early.)
I don’t know if this is all correctly implemented in Firefox, might be worth it to test and report any deviation as bugs.
I still don’t really follow. How would anything with cookies (HTTP, stateless) work via a shared TCP connection. I’m completely missing the point where this is not just a hanging connection (where the website under certain circumstances would assume you’re there for 20min longer than you are) and nothing else.
Also in the super cookie you mentioned wouldn’t the problem be the reuse of the connection and not the “not closing”?
Yes, it is the reuse. To reuse connections is the reason browsers doesn’t close connections immediately in the first place. Also anything where there is a noticeable behaviour difference, like closing the connection early on some user interaction where it would otherwise idle longer until close.
Half closed TCP connection, sometimes called hanging, have a different state than fully open, idling connections that can start to transmit at any time again. Normal http-cookies are per request, multiple requests can share the same connection. With HTTP keep-alive in serial fashion, with HTTP version >2 generally in parallel. Super cookies do not rely on http-cookies, sometimes they only track users by measuring timing differences.
If you never use that web browser again then it makes no difference. But if you reopen it, the process was not terminated (otherwise the connection would have been closed by the kernel), the connection is still idle and then gets reused.
When the connection to a third party gets reused for a request that is for a different first party than the one it was opened for, that can be used for tracking across the web.
Stale connections don’t really worry me; those new “notification” permissions do. I’d normally expect it to mean that the tab in question can show me desktop notifications while it’s open, but it actually means it can fetch stuff while it’s closed!