Alex's approach

For example TLS 1.3 as designed has Downgrade prevention, if you try to *pretend* by meddling with the TCP data that somebody else's server doesn't know TLS 1.3, then either you tip off the server that you're interfering or you tip off the client, or both. There is no way to get to a scenario where the client thought it asked "Do you speak TLS 1.3?" but the server thought the client asked only "Do you speak TLS 1.2?" without the session being torn down.

But, of course idiot middleboxes broke this. Because they don't implement TLS properly, they'd hide the client's real question about TLS 1.3 from the server, but they'd pass through its answer to the question they did ask, thus exactly performing a downgrade, which sets off the downgrade prevention, your browser just closes the session. This was discovered after TLS 1.3 shipped, because Downgrade prevention obviously can't be enabled pre-standard, that's a DOS against yourself in the standards development process.

So, Google shipped builds of Chrome with a hack, _if_ you turned on the hack and _if_ the server says "I'm a TLS 1.3 server but you claimed not to know TLS 1.3 so that's fine, unless you were downgraded" this Chrome ignores the problem. Temporarily. This damages your security, but you're using a middle box, you already don't have any security, that's what you paid money for, to destroy your security.

Google told the affected vendors that their customers could enable this hack (in their installed Chrome builds) and *crucially* it told them that in a fixed period of time this hack would just be summarily deleted from Chrome. They were not going to reify this nonsense as part of the protocol design, it was a temporary hack to get some people working while these companies fixed their shit.

And they did it. Years ago now Chrome just deleted the hack. If your middle box vendor didn't fix their bug in a reasonable timeframe, or you couldn't be bothered to install their fix - now Chrome doesn't work, too bad. Everybody gets reliable TLS 1.3

Without making it clear that this stops working in (say) 12 months, there is *no* incentive for Apple to fix it, for Apple's developers to care that it's a problem, for anybody to do anything except dump on the Python maintainers whatever they can't be bothered to fix. They're making their own lives worse.

If they set a specific deadline and stick to it, it's clear what the problem is, that doesn't mean Apple will care, but too bad, you offload the problem onto exactly the people who wanted it, Apple developers, people who are used to and have accepted that they have an unhealthy masochistic relationship to an unfeeling corporation. There is no reason why anybody involved in Python who doesn't share that weird relationship should be inconvenienced.