If either LOAD_DO_NOT_SAVE_COOKIES, LOAD_DO_NOT_SEND_COOKIES, or 3rd-party cookie blocking is enabled, HTTP requests will be forced through the "privacy mode" socket pool.

This is done at https://cs.chromium.org/chromium/src/net/url_request/url_request_http_job.cc?rcl=7fe06f0c134410166e13a5b27b0401d42a83a7b7&l=353

If Privacy Mode is enabled, Channel ID is disabled.

This is done at
https://cs.chromium.org/chromium/src/net/http/http_network_session.cc?rcl=7fe06f0c134410166e13a5b27b0401d42a83a7b7&l=422


For requests that set LOAD_DO_NOT_SAVE_COOKIES, with the intent to send cookies but not save them (e.g. for personalization purposes), these will be sent over sockets that do not include the channel ID that the cookie is bound to.

If the server is configured to reject bound cookies that aren't accompanied by their channel ID (as unauthorized/hijacked), then these cookies are rejected, making them pointless to send.

This is simply one symptom/bug resulting from the overall inconsistency described in https://docs.google.com/document/d/1ntn9N7Ce2jozvvpWI0XbzJ7lJdwUjJXK07wp7rxrIN4/edit , which also discusses proposals for how to address this. There is no 'easy' fix, satisfying the case of (Send existing cookies, send existing Channel IDs) would require a new dimension of socket pools - either within the network stack itself (challenging due to late binding) or through additional URLRequestContexts for this purpose.

This is not an issue for Token Binding, the successor to Channel ID. This is because the creation-or-binding of the Token Binding key is done at request time, rather than at socket connect time, allowing for requests to have this permutation. However, there is no timeline scheduled for the transition from Channel ID keys to Token Binding, or their migration for existing cookies.