First: Please remember that my statement was made at a time when https://helloworld.letsencrypt.org was just offering TLS 1.1 and TLS 1.2, so this already set the bar quite high. In the meantime, the site’s security bar was lowered significantly by enabling support for TLS 1.0.
Of course, sales teams don’t care about security concerns. And security teams don’t care if the door is locked for everybody.
I think, there are two ways to define the term: Currently used browsers, or currently maintained browsers. However, a line in between these two should be drawn for defining a sustainable security border.
A lot of people still use their old XP computer or Android 4.1 smartphone to browse the web, and they expect that to work till the dawn of time. And the expectation of marketing people is that no-one is locked out just because he cannot afford a new OS or even new hardware.
OTOH, all major platforms can be upgraded with a modern, a maintained browser. This applies to Android, XP and even OS X, but AFAIK not to all versions of iOS. Just download Firefox or Chrome and you can browse even with your buggy and lousy XP securely. I think, on the transition to TLS 1.3 next year we will see that more and more servers drop support for TLS 1.0, suggesting that their users either upgrade their OS or at least their browser. This will put a significant shift towards maintained browsers.
Here is a list of users:
Users browsing with up-to-date browsers. The browsers are actively maintained by auto-update from either the OS or the browser itself. They deserve the best support, and they can use the highest standard in cryptography.
Users browsing with yesterday’s browsers. The browsers are not maintained and might not support the latest bells and whistles but this group of people is big, and they have never seen a problem on other sites, so they’d suspect the site’s admin to be in error if your homepage cannot be reached anymore. Just be nice, support them as the security they’re requesting is still good enough.
Users browsing with ancient browsers. They are in fact used to getting an error message here and there, and if not for their TLS support, then for their lack of the most recent http/js features. They are like people with dermatophyte who get used to scratching their toes and take a long time to finally seek medical help.
Users forced to browse with ancient browsers. They are not free to upgrade due to a requirement for backward compatibility of some old website or plugin (Active X).
Users using CLI-based or language-embedded TLS engines, e.g. PHP scripts calling a web API on an ancient OS. They might have invested some money into bringing up the system that time and don’t want to afford the upgrade for some reason.
I think every admin has to choose the list of users he wants to catch, and of course, to honor their security concerns (which might differ from the admin’s concerns, depending on data direction).
IMO, group (5) has a scalability problem already, and since they’re running some business on that, it will hurt one day. It should be clear by now that security has a limited period of time for ROI and has to be rolled out freshly every now and then. Only those who have learned to handle that in a scaling way will survive.
Group (4) is typically aware of the limits they are enforced to handle. They most likely have an alternative browser on their computer which they do for anything else than handling this f*cking old intranet web app. So in fact, their public identity might be more from type (1).
Group (3) is the one who is really in danger. If you really care for your valued users, you could put a filter on the website right now, detecting the cipher they connected with and redirecting them based on the result to a website telling them that you’re happy to have them as a user and that you’re really sorry about the change you have to apply in … whatever, 6 months from now, where it seems you won’t be able to serve them anymore as expected. You could put some hints about solutions they could apply on their side, like suggesting to upgrade their browser or changing to something that handles upgrades better. But one final day, you will disable support for them, either just by your declared schedule or just because of this new TRICKSSL, or FISTLS, or what ever the next successful security breach will be called. The better prepared you and your users are, the easier the migration is.
Group (2) should definitely be supported for as long as possible, until they fall into group (3) one after the other.
I’d suggest to support groups 1 and 2, and offer time-limited support for group 3. These would be the current browsers which should be considered a moving target. Now and always. Everything stays different.