I'm actually fairly confident this is WontFix.

We've never had guarantees that deleting history would flush socket state. Deleting history has (historically) been about the on-disk representation, and that invariant is maintained. As such, even if you clear history, sites can still link your past actions, based on established connections you have that may have exchanged data (for example, HTTP/2 coalescing). This makes perfectly logical sense when you consider that history state can be based on origin or recency of activity, and there's no meaningful way to associate any state associations between those activities and connections.

Clearing cookies has also, historically, had zero guarantees about flushing connections. As such, even if you clear cookies, your existing connections are maintained, and thus servers can link your new (cookieless) activity to past activity.

Channel ID, by virtue of being a TLS connection-bound method, forces clearing of the TLS socket pools. A more efficient solution would have been to only clear those connections on which we negotiated Channel ID (I think we had a bug open on that?), but it was not a high-priority efficiency win, since clearing channel IDs is a rare event. Channel IDs are treated as cookies, thus clearing cookies clears Channel IDs, and clearing Channel IDs forces a flush of the socket pool.

The ChromeSSLHostStateDelegate has a way of persisting status to disk (by way of recording content settings), thus was glued up to the history mechanism to ensure those resources were cleared from disk when history was cleared. It did not, nor has it ever, flushed existing connections AFAICT.

All of these make sense in a model in which clearing history, or cookies, is linked to clearing the representation on disk. My understanding is that this also matches cross-browser behaviours. A change for "Clear History" or "Clear Cookies" to mean a stronger invariant about 'reset tracking state' is, in my mind, unreasonable and unrealistic, but hopefully this explains the relationship between these.

This hopefully explains why the behaviour is, and what the invariants are regarding "Clear History" and "Clear Cookies" are that our code and behaviours have been built around. If it's desired to change those, that seems like a rather large product shift, and so hopefully will be communicated and discussed widely :)

Thanks for your input, Ryan. I would very much prefer the "reset tracking state" semantics over "clear on-disk state". (Imho the former is better aligned with user expectations.) Why is that unreasonable and unrealistic? For example, among the team we've already discussed closing open tabs to prevent state from being re-created (do we have a bug for that, Christian?). Why shouldn't we clear socket pools as well?

The levels of granularity are very different. I would be surprised and disappointed if clearing any cookie (or Clear-Site-Data, which is presently wired up to similar mechanisms), or even the last 10 minutes of browsing activity, or history for a given domain, would close all tabs, clear all socket pools, flush all memory state, etc.

From an unreasonable and unrealistic, our code architecture is modeled around the idea that in-memory caching is acceptable (of which socket pools are simply a variation thereof). To obtain the desired semantics, minimally you'd need to flush all forms of memory caches, in all layers. And if you want to have those reliably applied, it would either have to happen for any degree of clearing, or you would need to bake that granularity (and the ability to track it) into all the layers. Hence the broader architecture/product shift question.

Hm, maybe my description of the issue was unclear. I don't expect that deleting history resets tracking information. 
We were figuring out why neither deleting cookies, cache or history resets ssl warnings and figured out that ssl warnings only properly reset if both, cookies and history are deleted. 
Maybe we could simply solve this issue be resetting ssl warnings with cookie deletion instead of history deletion as they can potentially be used for tracking?

I don't think resetting with cookie deletion is a good solution - nor is it clear how such warnings can be used (meaningfully) for tracking. They're not state that can be directly set by the server - it's a 1/0 state based on user interaction (much like the disk cache)

This again goes back to the expected invariants around cookie and history :)

I'm not advocating for anything here, but clearing cookies does flush the socket pools (It also clears the auth cache, which doesn't really guarantee much unless you also flush the socket pools).

https://cs.chromium.org/chromium/src/content/browser/browsing_data/browsing_data_remover_impl.cc?type=cs&sq=package:chromium&l=109
https://cs.chromium.org/chromium/src/content/browser/browsing_data/browsing_data_remover_impl.cc?type=cs&sq=package:chromium&l=499

My understanding is we did that because of the NTLM/Kerberos being connection-based auth (i.e. the same problem as Channel ID), rather than an intrinsic guarantee.

That is, if we only supported request-oriented auth, we would only need to flush the auth cache, without clearing socket pools.

I'm not entirely sure that's the case - proxies can use basic auth as well, when establishing tunnels, so we still would implicitly keep auth-ed connections around without those schemes.

In my opinion when deleting all cookies the goal of that user action is "prevent reidentification" and I think we should deliver on that user goal. This means reloading tabs (it's not necessary to close them), clearing caches and any other kind of state and dropping connections. Why do you think this involves an architecture shift? -- If some caches/state don't support partial deletion, we can always drop them wholesale.

Maybe dropping a lot of state is overkill when the user deletes an individual cookie, but usage of the clear browsing dialog imho is a clear enough sign of user intent to warrant that kind of overhead.

Cf. issue 620500 why not deleting cert warning state can be a problem in practice.

That bug seems like a giant WontFix. I'm surprised it wasn't closed out already.

Regarding the rest, I guess we fundamentally disagree on what the reasonable product direction is. Privacy is certainly y'alls area, so my only request is that if your goal is to change those guarantees to be something different, that a design doc and broader discussion is had to weigh those tradeoffs. I think dropping all possible in-memory state for the deletion of a single cookie is not a sensible design decision, but I realize that's just my opinion, and defer to the Chrome design process as to whether that's seen as a product direction to engage in.

Note that we have never enforced a promise of deleting all browser state on clearing cookies, nor attempted to do so.

If we really wanted to prevent any issues, we'd have to cancel any pending network requests, while blocking new requests from being issued (Including from extensions, XHRs, navigations, etc).  We'd need to block write access to the document.cookie API.  And block prefectes/preconnects as well.  We'd then need to clear the cookie store, and destroy all RenderFrames (Still blocking document.cookie access, so they couldn't save any state once we're done deleting cookies), and then we'd need to hard-reload open tabs.  We'd probably want to clear the disk cache, too, before that.  That still doesn't prevent open sites from keeping track of the user through use of the URL, of course.

> Note that we have never enforced a promise of deleting all browser state
> on clearing cookies, nor attempted to do so.

Which I consider a bug and not a feature. Chrome's promise is to get better over time, so let's work on closing the gaps in our state deletion functionality.

Any comments on plans about blocking cookie modifications while in the process of killing everything?  Or killing all network requests?  Just reloading tabs really doesn't seem to get us much, if we want to make hard guarantees.

We don't plan to close, freeze or reload tabs when deleting cookies or history. 

We are thinking about ways to formalize privacy guarantees for Clear Browsing Data but these would require all tabs to be closed. Maybe we would add an option to Clear Browsing Data that close all tabs before initiating a deletion.
As you mentioned, clearing cookies does close network connections, so I think it should be possible to provide some guarantees about removal of all state when no tabs are open.

This bug in particular doesn't bother me much as deleting history+cookies correctly resets ssl warnings. I was just confused that two options are required to do this.
If there is no agreement whether it makes sense to reset ssl warnings with cookies instead of history, then we should just close it.

Certificate warnings seems history-like to me (in that they record a user action) and not cookie-like (in that the website has no way to "write"). As such, I'd argue that the state should be reset when history is cleared and I'd suggest to clear socket pools on history deletion iff there is non-empty cert warning state.

I think the path forward in Comment #14 is a good path - we should close this as WontFix.

If there's disagreement on that plan, we should identify why and a clear path to resolving this disagreement. I think Comment #11 articulates well the problem space and why the expectations are not reasonable or realistic, which Comment #14 seems to confirm. I do not think we should pursue further activity on this path unless we're willing to close and freeze all existing tabs when clearing history - otherwise, we are not getting better over time, we're simply adding more complexity for developers, decreasing product excellence, without achieving any formalized guarantees.

Thanks everyone!