Maybe combine the two so as to be something to give said IT admins something to go on?

Wikipedia is tightening its security measures, please update your device or contact your IT administrator about using forward-secrecy cipher suites.

@Jdforrester-WMF the short message should be addressed to non-technical users on their language (if possible) but we will be also providing a long explanation in English addressed to technical users and IT administrators explaining the details and the technical reasons behind AES128-SHA deprecation.

English grammar nits: it would be forward secret ciphers (meaning "ciphers which have the property of forward secrecy"). But these terms "forward secret" and "cipher" belong to fairly small-scope technical fields, so they probably don't translate easily (if at all, in some cases). With English being the normal language of technical matters on the Internet (for better or worse!), it may make sense to split this up into a simpler translatable message, followed by a more-accurate English-only explanation to be placed at the bottom that's intended for the more-technical (in some cases, what will get copied to some forum or tech support person to ask what it's about).

Timing race, now this sounds redundant with the above, sorry! :)

Long explanation:

We have removed support for non forward secret ciphers, specifically AES128-SHA, which your browser software relies on to connect to our sites. This is usually caused by using some ancient browsers or user agents like old Nokia smartphones or Sony Playstation3 gaming consoles. Also it could be interference from corporate or personal "Web Security" software which actually downgrades connection security.

You must upgrade your browser or otherwise fix this issue to access our sites. This message will remain until Aug 1, 2018. After that date, your browser will not be able to establish a connection to our servers at all.
See also the HTTPS Browser Recommendations page on Wikitech for more-detailed information.

In T196371#4255350, @Johan wrote:

The message should also clearly state that this means they won't be able to access Wikipedia in the future (or won't be able to access Wikipedia because of this, depending on when they can see this warning). That's not necessarily obvious otherwise. Something roughly like this?

Wikipedia is making the site more secure. You are using an old web browser that won't be able to connect to Wikipedia [in the future]. Please update your device or contact your IT administrator.

I'm ok with this version of the message.

Potentially with the addition "There's a longer and more technical update in English below."

Last time we didn't need to explicitly say that we were providing a longer message at the end of the page, but maybe here makes sense

So we plan to do this gradually, like we did with the 3DES deprecation, right?

Yes, but on a shorter timescale. The 3DES one, in retrospect, dragged on a bit longer than it had to, and in this case (a) We're starting at a lower percentage of real end-user UAs affected (b) there's a timing correlation with the PCI-DSS cutoff disabling most of these same devices for a lot of commercial sites as well, for slightly-different reasons. We're looking at ~6 weeks total process: 3 weeks ramping out the message percentage, 3 weeks of total blockage with the message, then disabling at the protocol level.

OK. So I'll ask for

Wikipedia is making the site more secure. You are using an old web browser that won't be able to connect to Wikipedia in the future. Please update your device or contact your IT administrator.

and

Wikipedia is making the site more secure. You are using an old web browser that can't connect to Wikipedia. Please update your device or contact your IT administrator.

and

There is a longer and more technical update in English below.

if we're all OK with these messages.

The second instance of Wikipedia should be replaced with the project name in each case. I don't like the explanation "Wikipedia is making the site more secure." (how so? Wikipedia content caused the singularity in the servers? ☺), preferring something like "We are making Wikipedia connections more secure.", but I'm afraid it's the kind of sentence most visitors would expect…

The first sentences should be really simple – they're mainly aimed at people who use old, outdated browsers, who might not get a translation and are reading this in a foreign language. This is the kind of audience where simplicity is probably better than precision, especially when we can count on the longer explanation towards the bottom for that.

Will this message be the same for the non-Wikipedia wikis?

In T196371#4259443, @Johan wrote:

Will this message be the same for the non-Wikipedia wikis?

Yeah, all projects

We faced this issue last time and went with "Wikipedia" as well, because:

• Explaining "Wikimedia" and the projects quickly in a translated message is tricky
• Doing i18n translations of all the project names and templating them in dynamically is hard (for this simple solution)
• Wikipedia statistically dominates all the other projects in pageviews, so it's the most-likely to be luckily-correct when these ~0.08% of requests come through we're trying to send messaages to.

In T196371#4259493, @BBlack wrote:

• Doing i18n translations of all the project names and templating them in dynamically is hard (for this simple solution)

The first part is a solved problem. https://github.com/wikimedia/mediawiki-extensions-WikimediaMessages/blob/master/i18n/wikimediaprojectnames/en.json

As @BBlack said, I think considering other projects for our scope (0,08% of the requests) it's a little bit of an overkill, so let's go with Wikipedia

In T196371#4258991, @Johan wrote:

OK. So I'll ask for

Wikipedia is making the site more secure. You are using an old web browser that won't be able to connect to Wikipedia in the future. Please update your device or contact your IT administrator.

and

Wikipedia is making the site more secure. You are using an old web browser that can't connect to Wikipedia. Please update your device or contact your IT administrator.

and

There is a longer and more technical update in English below.

if we're all OK with these messages.

can we move these forward? :) Thanks @Johan

Since no one has protested, I'm going to take it that yes, we can move them forward, and start asking for translations later today.

Translations are being collected at https://meta.wikimedia.org/wiki/User:Johan_(WMF)/AES128-SHA

Isn"t there a way for the wiki server to autodetect those browsers that are still using the legacy TLS implementation and add some flag whose fvlue that can be used to conditionally display the warning?

And may be the technical link could bring to a lsit of known browser versions that should not be affected by this change (apparently this mostly concerns smarphones/tablets or "smart" TVs with old firmwares that are no longer supported by their manufacturer or reseller and offer no firmware upgrade (it's common for them to stop delivering updates about 2-3 years after the end of production and sale, they just want us to buy another device and block any attempt to refurbish/recondition them, posisbly with alternate opensource firmwares; Android with Selinux enforcement also reject alternate firmware installations if they are not digitally signed by the manufacturer, and it's generally impossible to get the installation keys; moreover, Google Android services will block some requests and signal to applications and websites those that are using "rooted" smartphones or unsigned firmwares).

So people will just continue to use their device even if it does not support the latest security requirements and contain security holes. At least Wiki sites should remain usable without forcing them to use HTTPS: an alert can be displayed, and then dismissed to continue the navigation with HTTP only (and people must be informed that their privacy will not be kept on these devices).

So we need both:

• a technical page (containing possibly links on how to upgrade their browser or list some alternatives)
• an end-user page, less technical, containing details about why their security and privacy cannot be warrantied, so they will use safe edits or simple visits on the wikis (they will have to moderate themselves if they don't want to reveal information associated to their private account).

The implementation over HTTP shoulmd still make all efforts possible to protect users' privacy. And each edit or attempts to connect on their personal account may have a warning stating that this is not secured: before the user sees the logon form, there would be a first notice and a button to continue with the logon or dismiss the attempt: the logon form should then be hidden, not delivered immediately (this will also block tools, like password managers, to send data too fast as they won't detect the logon form, users will have a chance to cancel the logon attempt)

If users want to edit without being connected (i.e. publicly identified by IP only), that warning should be displayed at top of page before they start editing below, and then submit the data.

I don't think this will be blocking non-browser editing tools, notably bots, as they should secure their connection in all cases with updates of the tool implementing "state of the art" TLS (these tools using directly the API render any notice for now, but the MW API should provide a way to insert a preliminary notice and block the early conenction attempt with old security keys and algoriothms, before they attempt to create an authenticated session and use the API with a valid editor session cookie for this API. Bot users will have then to update their system (refresh their installation of Python or similar scripting engines, or recompile their native application to use better protocol parameters).

Note that because of ULS, using "Wikipedia" instead of "Wikimedia" is still accurate: the secure logon will be made on other wikis simultaneously, including Wikipedia, when you are on any other Wikimedia site (there's a small exception for some internal Wikimedia wikis that are not connected with ULS but use a separate logon, these internal wikis are used mostly by English-speaking users, except possibly the WM conference wikis created each year and whose users may be using another local language, and some old wiki projects whose editing has been stopped and kept online as a readonly archive where no logon is necessary via ULS, and their few administrators will very likely have the way to use decent alternate browsers if needed, or can contact another admin in case of problems to perform some emergency action).

So with ULS enabled now by default everywhere this will be OK (are there still normal non-admin users not using ULS on Wikimedia wikis?)

@Verdy_p: IMO your question is already answered in the task description. Apart from that it seems unclear which actual problems your latest comments try to solve, but as your long comment is unstructured I only skimmed it (while other people that you maybe wanted to reach might skip it entirely).

In T196371#4282728, @Verdy_p wrote:

Isn"t there a way for the wiki server to autodetect those browsers that are still using the legacy TLS implementation and add some flag whose fvlue that can be used to conditionally display the warning?

Not realistically, and not at the layer we'd like to handle this. It's a deeply complex issue when you get into the low-level details, but the key facts here are:

1. There may be common cases for certain browser UAs (e.g. Nokia Symbian devices of a certain age, PlayStation 3), where the UA itself fails to implement the necessary level of TLS support. However, there's also cases where the TLS support of the UA is fine (e.g. latest Chrome release), but some other middleware is interfering with the connection and causing the downgrade (e.g. corporate outbound TLS proxies, some "web security" software installed on home routers and/or home computers, etc). Because of this, matching on UA alone isn't sufficient to catch all the cases this impacts.

2. Even if we brought the live TLS connection properties down to MediaWiki in the form of a header it could parse in place of the UA string, conditionally displaying a warning requires javascript interference, which wouldn't work correctly on some of the truly-legacy devices/UAs affected, or for a static warning requires splitting our anonymous page caches on TLS properties in a deep way that echoes back through the edge-caching layer and also into the MW page cache, which is also undesirably complex.

And may be the technical link could bring to a lsit of known browser versions that should not be affected by this change [...]

The fuller English explanation at the bottom explains some of this, but is too complex for reasonable translation. We're keeping it very generic in the translated version, and hoping that those who need/want more detail will seek out an English speaker (perhaps on forums/wikis, or in person) to understand the stuff at the bottom, as it's the technological lingua franca.

So people will just continue to use their device even if it does not support the latest security requirements and contain security holes. At least Wiki sites should remain usable without forcing them to use HTTPS: an alert can be displayed, and then dismissed to continue the navigation with HTTP only (and people must be informed that their privacy will not be kept on these devices).

I'm not sure which meaning you're using here for Wiki sites (or how other readers might interpret it), so to be clear: all of this is about the technical infrastructure that handles connections to the Foundation-hosted projects, and is not in any way related to general changes for MediaWiki use in other settings. For Foundation-hosted projects, we're already long past the point where HTTPS is the forced, and only, option for connecting.

Also, a couple of contextual points to keep in mind about scope/impact on this:

1. This isn't a drastic move towards enforcing only modern TLS. It's a relatively-tame removal of only the worst-case extremely-legacy stuff (non-forward-secret ciphers, of which we only support this one anymore), which in practice affects very few users. In the past week, the cipher being deprecated here was used for ~00.08% of all requests to our sites. Within that percentage, it's roughly an even split between the "Legacy UA" and "Proxy interference" sub-cases.

2. This is happening in the context of the PCI-DSS deadline of July 1st (during our deprecation period here) for all commercial payment-processing sites on the Internet (which in practice ends up impacting almost everyone) to drop support for TLSv1.0. The primary foundation sites (fundraising aside) are not required to meet that deadline, and TLSv1.0 is a different thing to deprecate than the AES128-SHA we're killing off here in this action, but in practice the legacy UAs we're impacting with this move also happen to only support TLSv1.0, and thus they're about to get a whole lot less useful everywhere else on the Internet anyways, and WIkipedia not working for them will just be a drop in the bucket of the many other sites that will also cease working for them.

Not able to even read the wiki in an enforced incognito mode (removing all private session keys, disabling some scripts, just render the content)?

Then we should revert them to use some alternate read-only mirrors (but most of these mirrors are augmented with advertizing and do not preserve the privacy of their visitors, unless they follow the new European RGPD rules strictly: we copuld divert them by sending them to a mirror hosted in a respectable site in the EU where at least RGPD is respected and enforced).

If we don't, then users will just see some contents cached by Google (and with various site trackers enabled).

We can also send them to a WM promotional website managed by some chapters (or by the Wikipedia Zero program), or send them to an offline archive (possibly via an external application and a downloadable database of contents).

Blocking simple visitors only is IMHO very brutal and opposed to our common objectives: making the data available to anyone anywhere. OK we can block contributors (including pseudo-anonymous IP users).

We could also promote the use of a web proxy for read-only access to the live content.

Also I propose creating a read-only instance of each wikimedia project (e.g. the domain "en.wikipedia.org" becomes "read.en.wipedia.org") and connects to a proxy that will only deliver the content, will deliver no access to the various tools around, no preferences, no logon, just a basic search bar at top of page, no edits and a side bar limited to visit some read-only portals or pointing to other related websites not restricted by this limitation.
This website would just have a local standard cache of generated pages, with long expiration date (about one week is a minimum), it would be semi-live. But at least we continue delivering the content.

And to preserve privacy, this red-only edition should propose to extract some large navigatable extract (e.g. by collecting pages from a start page, plus some randomly selected start pages, up to some level of depth or a maximum downloadable file size) that can be browsed offline (with the existing offline Wikipedia reader apps). Users could then navigate freely from some wellknown Wikipedia portals of from any subject they are interested in. This extraction can be made on top of the caching proxy, maximizing the use of its cache (filled by contents requested by any other random visitors).

Which format will be used for the download ? Basically a collection of prerendered HTML pages, plus images and some common CSS stylesheets, no javascript at all or a minimal one not absolutely necessary for using it, packed in an archive and freely installable on any webserver, or in a desktop storage folder. The metadata of these pages would only contain the date of production, no history at all. It could also contain the licence info (and for listing the contributors, one would have to browse them online with a decently secured browser, we would just display the URL to follow to get that history list online).

Note that a read-only edition of Wikipedia should be available to any one (including blocked users! They have the permanent right to know and still have an access to the data they contributed and which is still present, or know when they are cited on the live editable edition, we cannot legally block them).

We can also redirect some known bad indexing engines and bots to this limited read-only edition, so that the live editable ecdition is still protected from their abusive usage, and we can also force them to pace down their usage by limiting the speed of request replies, if this affects the performance of the local cache of the read-only edition, or indirectly the performance of the underlying standard front cache of the live editable edition.

We've got some overlapping timelines on these long-form posts :)

I assume most of the most-recent one above is in the context of an HTTP-only site option, which again we're past the point of doing. It's a debate worth having (enforcing privacy via HTTPS, vs the loss of information access to non-HTTPS users it could exclude), but we've already had that debate and moved past that decision point in a fairly permanent way.

Part of the disconnect in our viewpoints here is that HTTPS protection is not just about editors and cookies, it's also about the reading patterns of anonymous users, which is highly valuable metadata which can be mass-collected from insecure connections to form profiles on users (e.g. A totalitarian regime asking itself: which users in my country read about subjects I consider subversive, so I can put them on a watchlist?), and it's also about preventing censorship (HTTPS is an all-or-nothing arrangement for the site, whereas over HTTP a government or other access-controlling entity can selectively filter subversive/unacceptable topics while maintaining the appearance of allowing unfiltered access to the rest of our information). Preventing snooping of and interference with users' reading habits is part of preventing the chilling effects of privacy invasion, too.

In general, though, this is wandering pretty far off the narrow scope of this ticket, which is about developing and translating the messaging we're using, not about broader policy and/or technical debates.

At https://en.wikipedia.org/sec-warning why does the English text not refer to the section at the bottom with technical info? I can see that the French text (for example) has "Des informations supplémentaires plus techniques et en anglais sont disponibles ci-dessous.", which roughly translates to "Additional technical information in English is available below." But English readers are not invited to scroll to the bottom of the page.

Will that affect Wikipedia Zero, given it is freely hosted by third party volunteer ISPs that provide their own caching proxy? Can their proxies support the new security requirement for conencting to Wikimedia sites and delivering their contents (and optionally allow their users to contribute via their proxies)?

(Note: I'm confident that providers of Wikipedia zero are already compliant on their outbound proxies and will have no problem getting the content after the update with the new security requirement; I just wonder if they enforce or will enforce the same level for usage by their clients, at least for read-only access; contributing should require full end-to-end encryption and the new security requirements also from clients of these proxies, or at least very careful inspection and filtering to protect the privacy, and compliance of their services to the new European RGPD rules about usage tracking, or similar measures now largely adopted elsewhere by wellknown worldwide providers, such as Facebook or Google when they republish some Wikipedia contents on their sites and portals).

If their users pass via proxies, these proxies may not require the same HTTPS level and may stiull be able to get the content (and optionally contribute). Can we then inform them that they'll still be able to conenct using such proxies?

And if these proxies are restricted for use only by the third party ISP, can we have other volunteer proxies we could advertize in case of problems? Or will users of unupgradable browsers will just experiment a connection failure/no reply from server/connection refused, and will then have to use one of the advertizing mirrors (which rarely support contribution, only basic reading)?

Example of useful proxy (used notably in Turkey after the Turkish authorities banned and blocked all Wikipedia editions):
https://en.vikiansiklopedi.org/

There may be similar examples of useful proxies used in China, Russia, or islamic countries, but that are not restricted for use from a single country and are left open to everyone in the world (but I'm not sure about their privacy compliance). But these proxies which are used to circumvent a ban are most probably already implementing the best end-to-end encryption algorithms and so they already require using modern browsers and OSes...