Depending on exactly what we can get out of Android N, my proposal is:

Goal: I don't really want to deal with making CanPool asynchronous. It's possible this is hopeless, but that state machine keeps getting more and more complicated. If we can keep it synchronous, that'll stave off some complexity.

I propose that CertVerifier gain a second hook:

  bool CanReuseResult(old_hostname, old_result, new_hostname);

Possibly other parameters. The semantics are: "I would really like to call Verify again, but this is annoying. I already have this result. Is it good for this other hostname too?". Most platforms would just do the name match again. (If we move pinning into CertVerifier, it'd repeat that.)

On Android, *if* we can get synchronous access to the trust config, we would also check if old_hostname and new_hostname have identical parameters. Trust anchors, etc. If not, we'd return false.

What complexity are you talking about w/r/t CanPool being async? Because that's unclear.

I feel like it's *far* worse to try to access the trust config on Android and re-implement the logic checks its doing. That seems counter to the very design goal of why the trust config was introduced.

How much performance (latency, memory) impact are we talking about if connection pool is disabled

> How much performance (latency, memory) impact are we talking about if connection pool is disabled

Anyone one the network team wanna respond to that ^^

I don't think we have A/B data with it disabled anymore, because the benefits were so good. Given that this is a public bug, I will simply remark that from a Google standpoint, the answer was "Significant". 

Happy to expand on comment #5 offbug (rch@ is probably better for it, he knows better the impact when we last disabled pooling)

ok, I will ping rch or you after holiday season.

Agreed with what sleevi said. I should also mention that with the use of Alt-Svc I expect both google and other providers will end up wanting to take advantage of this pooling functionality.

had a long offline chat with Sleevi. I will look into it (or delegate if I cannot)

sgurun: Did you ever look into or delegate this per comment #9? In particular, did this never happen?

"One possible solution is to disable connection pooling when in a WebView, until such a time as we figure out a more suitable interface."

never happened sorry, and I am leaving webview team at the end of month - I think it is best if somebody in network stack team can address that as the code base is not very familiar with anybody in webview team.

Does network team any help from WebView team on this issue?

I'll tentatively take this, but I'll actually need guidance from network team to know what needs to be changed.

ntfschr: There's not a public/blessed Android API that I'm aware of yet that would allow us to match this.

There is an undocumented, internal API that can be detected via reflection - namely, RootTrustManager.isSameTrustConfiguration ( https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/security/net/config/RootTrustManager.java ). This method comes from X509TrustManagerExtensions ( https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/net/http/X509TrustManagerExtensions.java ), where it's annotated as a SystemApi and hidden.

This wrapper can be constructed around a TrustManager (per https://developer.android.com/reference/android/net/http/X509TrustManagerExtensions.html ), but I believe would have to be reflected into to pick up that method, and I'm not sure the policies regarding calling SystemAPI-annotated aspects, given that it's not officially blessed.

Adding cbrubaker@ in case I missed anything.

Does Chrome not build with SystemAPI? It was intended to be in the exposed API for this specific case.

You should probably be fine to call it with reflection, just make sure your code is robust to the method not being there.

> Does Chrome not build with SystemAPI?

No, chrome builds with the public sdk.

@Comment 21: Can you explain why you restricted this? Considering how long it's been open, this restriction doesn't provide much security value, but limits our openness to the community.

The main reason I restricted it was that I expect more discussion around whether we want to publish new Android APIs, for which we usually restrict from public knowledge. But yes, I agree that opening this bug has more value. Let's take it separately and not discuss here, then.

rsleevi@ do we need any work on WebView side here, or can network team handle most of this?

This would have to be fixed in //net, but is not on our priority list for the next few quarters (as shown by this bug being nearly 18 months old). It's a bug that primarily would manifest for Android WebView consumers - it would not manifest for Chrome on Android, because Chrome on Android does not use the manifest configuration.

Unassigning because I'm not actively working on this.