We can't yet remove this because chrome can still speak QUIC v31. We're actively working to remove old QUIC versions now that m51 is stable which lets us remove 25-29 (internal CL in flight to do that). I think we'll be able to remove v31 when m52 makes it to stable.

(I suppose my comments should have read "once QUIC 31 is remove"

I'm not really sure how to make sense of your comment.

Why wait until M52 making it to stable to remove code from trunk, today? Why can't you remove the code for those versions of QUIC - which you don't intend to negotiate on M53 (trunk)? Why not add code, to trunk, to make it so that it doesn't speak QUIC v31, if you can't delete the code (e.g. it's a shared repo).

I'm having trouble connecting why trunk is prevented from removing something that doesn't even matter for the current Beta branch, based on your comment.

The code is shared between client and server. We currently have clients speaking QUIC 31 which means the server needs that code, which means the client will have the code. 

And you can't simply disable this in Chrome side?

I would point out that we're talking TransportSecurityState (Chrome-only) and HttpStreamFactoryImpl::JobController::IsQuicWhitelistedForHost (Chrome-only). I'm not sure the relevance of the need to share code here or your Comment #3.

Put differently: Can Chrome, trunk, not ensure that https://cs.chromium.org/chromium/src/net/http/http_network_session.h?rcl=1466162237&l=164 is never less than QUIC v31, and, with such a check added, remove the related code from TransportSecurityState and HttpStreamFactoryImpl because it's guaranteed that QUIC will never be less than v31?

Since v31 is on stable we're confident that it works as expected. It's likely that v33 (on beta) and v34 (on dev/canary) are totally good too. But it's always possible that we'll discover a bug in 33 or 34 which might cause use to switch back to 31 via finch. We've done this on occasion, though hopefully we won't need to. But we have a process that we follow for managing QUIC versions and I'm inclined to follow it here. Other than being aesthetically gross, is this issue causing problems?

(By the way, IsQuicWhitelistedForHost will go away when IsGooglePinnedHost goes away since it's all part of the DROWN mitigation)

"But we have a process that we follow for managing QUIC versions" - for what it's worth, that process seems at odds with Chromium, given this and other QUIC cleanups attempted, in that it prevents Chromium contributors from removing code which is unused in Chrome (or cleaning up code in the Chromium codebase, since it's used by external codetrees which can't be viewed by any contributor)

It's now been 6 months since https://chromium.googlesource.com/chromium/src/+/74da0e1aeef5b431bc533c2a0bb24c94fd664e3c landed. I would like to cleanup TransportSecurityState and remove this, so that this doesn't ossify or get used elsewhere. Issue 576402 is still not closed out, 6 months after the CL landed - so it's unclear what's going on here.

This isn't aesthetic. This is code health. And I don't think the process QUIC is presently using is helping contribute to good code health, but in either event, it seems useful to file a bug to track its removal, and hopefully I'll be more naggy than sheriffbot :)

Marked Issue 576402 fixed.

Since we used finch to control QUIC versions (And we do this regularly) the code in question is NOT unused in chrome; it's just unused by default. 

You were proposing something we could do to make the code unused. We *could* do that, but it would make QUIC more risky. I'm sorry that our risk aversion is causing this method to hang around longer than you would like. 

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This was fixed with https://codereview.chromium.org/2914223002