That traffic is almost all bots, I called this out in the post. We’ve delayed until user impact is minimal. The number is not millions, we’d be shocked if it was even in the thousands. You’re also forgetting that quite a few technologies prefer TLS 1.0 and upgrade, not downgrade of its missing. This means they default to an insecure protocol. Some of that 0.6% will be just fine because it’s in this bucket…even though it’s almost all bots.

@NickCraver "You’re also forgetting that quite a few technologies prefer TLS 1.0 and upgrade, not downgrade of its missing." — what do you mean? FYI: Google still fully supports Google Search over HTTP, last I checked a couple of weeks ago. I also highly doubt that there's only a thousand of deprecated iPad devices still in operation, and/or some of them may already be denied access due to cipher differences.

Okay let's take that example. TLS 1.2 is supported all the way back to iOS 5. It's install-able all the way back to the iPhone 3GS and the original iPad. So quite literally, there's not an iPad that would not support connecting to us over TLS 1.2. I'm happy to have good faith arguments on this about what we should support, but this seems like we're just really reaching to "why don't you support everything forever"? Remember, all of these devices in the example are from browsers we a) do not support (and haven't for some time), and b) render our pages very badly - they're a decade behind.

On the TLS 1.0 front, some things like older OSes (PowerShell, etc. included) will try TLS 1.0 only based on config, or in order. They are capable of TLS 1.2 though. In short: we're not going to continue supporting these insecure protocols the entire industry recommends against at this point. It's just a bad practice, and has near-zero impact to actual users (which I do care greatly about).

@NickCraver Agreed. Continuing to allow insecure protocols simply to support some hyperthetical user base on very old devices, I would say would be irresponsible.

@cnst, how "older" are you talking about? I've got an Android 4.4 device I keep around for compatibility testing, and the default browser supports TLS 1.2.

You can even argue that support for SSLv3 should be brought back as well for "compatibility with Windows XP" or what have you, even though WinXP has been EOL for nearly 6 years - from when your son entered a primary school to now graduated. In short, there's really little reason to keep obsolete setup forever.

@cnst HTTP is inherently insecure, because it is not encrypted at all. It should not be enabled simply to support old insecure clients. Allowing HTTP on a HTTPS enabled site, weakens the overall security of the site because it allows protocol downgrade attacks, and prevents the use of HSTS headers.

It's also worth considering SE supports only a subset of browsers in a subset of OSes.A significant number of the examples you gave are not or might never be supported. And I doubt the move to http fallback makes any sense at all.

@user1751825 what you say doesn't make sense, because downgrade attacks aren't possible if you already have HSTS, even if HTTP is left undisturbed; and if you don't have HSTS, and are requesting over HTTP already, then there's nothing to downgrade; just because there's no encryption doesn't make HTTP insecure, either, especially if it's all public information being transmitted (most readers don't have accounts), and it's up to the user and their provider on whether or not their traffic is modified (nation states can already permanently block https and proxy https over http, should they want).

Plaintext HTTP is insecure in two ways - attacker can see what's transmitted, and can also manipulate what's transmitted. It's common in China where ISP endpoints insert junk ads into whatever page viewed through HTTP (ref).

@iBugisdisappointedinSE so, your solution is to self-destruct by blocking HTTP in case they decide to block HTTPS? If the nation-state provider controls the communication channel, they can simply never allow HTTPS in the first place, never letting HSTS to get installed, and always run a masquerade proxy on http to proxy https content selectively; in all, plaintext HTTP is just life.

If a state decided to block HTTPS completely, then it's not SE's responsibility to maintain its accessibility by allowing plaintext. HTTP is not life, it's obsolete.

@iBugisdisappointedinSE you're mistaken; TLSv1.2 is obsolete; HTTP is forever. If you block HTTP, you're the one that's blocking access to your resources from your own users, don't shift the blame to any other party for your own actions; it's been shown that retaining HTTP support is easy and harmless. Google Search still works just fine over HTTP; it's the smart thing to do, and it helps to narrow the digital gap.

If TLSv1.2 is obsolete, then what is up-to-date? I agree that retaining HTTP support is easy, but it's meaningless. Let me reiterate: The only reason to keep it is to support legacy clients that don't support SSL/TLS. Since Stack Exchange is no longer supporting those ancient platforms, there's no point in maintaining non-SSL access.

@iBugisdisappointedinSE just note that China has been blocking Google for some time now, and that SE is relying on some JavaScript that is only provided through Google servers. Ergo, Stack Exchange experience in China is very poor but could be fixed by offering an alternative/fallback JavaScript location.

@Cœur There's a separate thread on MSO.

There is an argument to allow HTTP read-only access. If set up properly, such would not be insecure. However, cracked HTTPS protocols are insecure to use for editing, as is HTTP itself. Both allow stealing credentials and injecting malware and all sorts of things. I do lament that sites that don't need it are moving to HTTPS, and that there is no limited functionality fallback to HTTP for most sites, but none of this is an argument to leave the site open to attacks.

@trlkly I migrated my self-hosted website to HTTPS-only a while ago, not for site-internal necessity, but to combat ISPs' ad-injection (looking at you, Comcast)