A quick look at Turnillo shows that use of Firefox 1-3 is approximately 580K per week across the wikis, with no particularly high usage in any given country. Based on this, I think we can go forward with the task as suggested.

Note that filter will also include 3.6 so our target here is even lower than that. In relative terms it is <0.25% of FF users, and FF is about 13% of desktop or 5% overall, so <0.033% of desktop or <0.013% overall.

I suspect the Firefox versions in question are actually not able to access Wikipedia due to insufficient TLS/HTTPS connection protocol support. If true, then these entries are noise from bots or crawlers faking their user agent and/or from bugs in the ua-parser we use.

/cc Traffic @ema Do you know what our expected compat is with Firefox for our currently supported TLS ciphers?

Outreach with Product and Traffic on-going.

It looks like we require TLS 1.2, which means anything less than Firefox 27 will fail to load. I verified this on crossbrowsertesting.com:

Here's the support matrix for TLS 1.2: https://www.caniuse.com/tls1-2

That matrix claims IE9/10 don't have TLS 1.2 enabled by default, but it can be enabled, as was enabled by default crossbrowsertesting.com & browserstack.com.

It probably doesn't make sense to continue MediaWiki support for browsers which Wikimedia doesn't serve to anymore.

This would mean bumping Grade C for the following browsers:

• Firefox 27
• Chrome 29
• Safari 7
• Opera 16
• Android browser none (Chomium WebView only)

It looks like maybe we dropped TLS 1.0/1.1 in January: T238038

Safari 7

Which also bumps Safari grade A. A good chunk of the compatibility matrix to the right of the fast-release cohort could use some grade A review in general.

This would mean bumping Grade C for the following browsers:

Almost catches up to the versions in the handful of tasks for grade A support at T178356, T75714, and T237688.

@Izno You're right. But even if that's the case right now, there will be gaps in the future again.

While awaiting the final feedback from Traffic and @ema, point in case with the necessary TLS 1.2 support (second time verified of Wikipedia not being accessible by Safari 6.2 on OS X Mountain Lion) were to broaden this task with bumping the Grade A browsers to the list already shared by @Esanders in T262946#6512792 –
if we agree to intertwine MediaWiki support with Wikipedia traffic/ops support.

Right now, Firefox 3 basic support vs proposed 3.6 is holding current needs like relying on rem back. So I'm open for both ways, limiting the task to the current description or – personally leaning slightly towards – broadening it up to be more future-facing in our development limitations.

In T262946#6517529, @Volker_E wrote:

@Izno You're right. But even if that's the case right now, there will be gaps in the future again.

Oh sure, just passively suggesting that it might be convenient to bump the majority of the items once rather than consider what is now 4 separate tasks of bumping.

broadening it up to be more future-facing in our development limitations.

(I still have been unanswered w.r.t. this thread about a standardizing discussion of supported browser versions rather than the ad hoc discussion that occurs now.)

In T262946#6517529, @Volker_E wrote:

@Izno You're right. But even if that's the case right now, there will be gaps in the future again.

While awaiting the final feedback from Traffic and @ema, point in case with the necessary TLS 1.2 support (second time verified of Wikipedia not being accessible by Safari 6.2 on OS X Mountain Lion) were to broaden this task with bumping the Grade A browsers to the list already shared by @Esanders in T262946#6512792 –
if we agree to intertwine MediaWiki support with Wikipedia traffic/ops support.

Right now, Firefox 3 basic support vs proposed 3.6 is holding current needs like relying on rem back. So I'm open for both ways, limiting the task to the current description or – personally leaning slightly towards – broadening it up to be more future-facing in our development limitations.

TLSv1.2 or TLSv1.3 are the only valid TLS versions to access Wikipedia. On January 16th We (Traffic) disabled TLSv1.0/TLSv1.1 support and enabled TLSv1.3 support on April 16th.

Please note that as part of T258405 we are deprecating the TLSv1.2 cipher suite ECDHE-ECDSA-AES128-SHA. As a result OSX 10.11 / Safari 9 (https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&version=9&platform=OS X 10.11&key=111) will be the minimum version supported to access Wikipedia

Mentioned in SAL (#wikimedia-operations) [2020-10-06T14:45:15Z] <vgutierrez> Bump ECDHE-ECDSA-AES128-SHA pageview replacement to 5% - T262946

Task description:

• Statistics: To be collected.

@Volker_E Which statistics would you like to document and use to inform this decision?

Would make sense to limit/widen the proposal to sync browser support for MediaWiki with WMF production traffic TLS requirements?

I suppose in that case we could do due diligence in verifying the stats are low and/or have explanations for existing. In my experience, data on TLS support tends to be flaky and contradictory at times since it's not always straight-forward how OS vendors and/or browser vendors update TLS protocols/chipersuites etc.

I can also see it being simpler to do just Firefox, depends on the third-party aspect I suppose. Your call :)

For quicker progress, I'd pledge for continuing with the simple bump of Firefox here to unblock using rem and solidifying CSS assumptions already made in our codebase and will file a task taking the TLS 1.2 impact and question on how we bind MediaWiki core to those browsers to a follow-up RFC.

Splendid. Is this good to go on Last Call next Wednesday?

Definitely from our side!

This is now on last call, due to be approved on November 4th.

Cross-referencing https://caniuse.com/rem and https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix, to guarantee rem support the following have to be bumped as well:

• Safari from 3 to 5
• possibly Chrome from 1 to 4

Is this handled in this ticket as well or separately?

In T262946#6510325, @Krinkle wrote:

I suspect the Firefox versions in question are actually not able to access Wikipedia due to insufficient TLS/HTTPS connection protocol support. If true, then these entries are noise from bots or crawlers faking their user agent and/or from bugs in the ua-parser we use.

Or workplaces / countries with man-in-the-middle requirements.

Here's a caniuse comparison tables:

• Grade C FF3.0 & FF3.6: https://www.caniuse.com/?compare=ie 9,edge 12,edge 79,firefox 3,firefox 3.6,chrome 4,safari 3.1,opera 15,ios_saf 5.0-5.1,android 4.1&compareCats=all

The following are newly fully supported:

• contenteditable attribute (basic support)
• CSS3 Multiple backgrounds
• querySelector/querySelectorAll

The following are newly supported, some with prefixes:

• CSS3 2D Transforms
• CSS3 Box-Shadow
• CSS3 Background image options

The following are newly supported, some partially

• CSS3 Media Queries
• TTF/OTF - TrueType and OpenType font support

Note that rem support is not in any of these lists due to Safari 3 support.

In T262946#6570349, @Demian wrote:

Cross-referencing https://caniuse.com/rem and https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix, to guarantee rem support the following have to be bumped as well:

• Safari from 3 to 5
• possibly Chrome from 1 to 4

Is this handled in this ticket as well or separately?

Handled under impact of TLS 1.2 requirement at T266866: Remove "Basic" support (Grade C) for browsers without TLS 1.2 (MediaWiki core and WMF infra).

Approved per today's TechCom meeting and async confirmation on Wikitech.