In December 2019 I began seeing a lot of "WTF?" reactions and comments
from colleagues and family, as they began receiving the above page when
trying to access Wikipedia as they always had done.
This is the text of the complaint I sent off to the Wikimedia foundation
about these incompatible changes they were making to their sites.
It should be fairly self-explanatory -- my good-faith effort to get them
to back off with the uselessly restrictive nonsense, for the sake of
continued greater accessibility.
Date: Sun, 15 Dec 2019 21:17:48 -0500 Subject: Your TLS "upgrade" is not anything of the kind To: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org I must file an objection in the strongest possible terms against what you are doing with regard to SSL/TLS compatibility on Wikipedia. The content there is completely public, and there is NO defensible need to forcibly encrypt all connections to retrieve it. Encrypted transport is appropriate for users performing administrative functions, sure, but that is a small minority of traffic. What you are doing now is arbitrarily EXCLUDING a large class of visitors, and that is just not right when so many are RELYING on unhampered access. There are plenty of old machines/browsers out there which either have no hope of upgradeability, or whose owners don't even know what that entails. Example: my elderly mother, who has always had an academic bent and has developed a deep appreciation for what Wikipedia can provide for her. Upon being faced with your ARROGANT rejection message, she is completely incensed that some shadowy unknown entity has removed her access without any recourse or alternative. She is terrified of computers in the technical context, and certainly not about to rip up her present WORKING client environment and rebuild it just because you say so, or spend frivolous money on new equipment and its steep learning curve. I'm sure this same scenario is now playing out in thousands of other ways for thousands of other victims. You even have the temerity to lie about it. The page that your canned and unavoidable "sec-warning" rejection leads to, https://wikitech.wikimedia.org/wiki/HTTPS/Browser_Recommendations contains this statement: ... This means that if you use an old web browser, you can still read pages on Wikipedia, but your browsing activity cannot always be encrypted in a secure way. Since you are now forcibly redirecting all connections to HTTPS and then rejecting older clients, this is an utter falsehood. In short, you have screwed this up. Even Google isn't imposing any such nonsense on its user base, and while they *encourage* use of SSL encryption on client connections, they do not mandate it for simple lookups. For public domain information it is NOT necessary in the vast majority of circumstances. It is not your place to dictate the computing environments of others, and it is completely disingenuous and discriminatory to claim otherwise. Here's what you should do instead: On an initial client connection via HTTP, present a page with a clear two-button selection: 1> move to an encrypted connection and continue the lookup, or 2> remain in the clear and do NOT try to continually redirect to HTTPS. Set a simple cookie to save this choice, whereupon the client will automatically keep informing your servers of that choice and from then on you don't mess with it. If a visitor assures you that they know what they're doing by making that choice and is fine with their activity proceeding in the clear because that's the only way it will work for them, RESPECT THAT. Your own websites states: ... charitable organization dedicated to encouraging the growth, development and distribution of free, multilingual content, and to providing the full content of these wiki-based projects to the public free of charge. I have recently been researching various estate-planning and/or philanthropic options, and in fact the Wikimedia foundation and similar entities have been on my list of potential considerations. But I could not and would not support an organization that continues to demonstrate this kind of blatant arrogance and disregard for the real-life needs of its user base. Like it or not, Wikipedia has become a critical resource to many. Stop denying access to that just because your dev staff thinks some level of TLS is new and shiny and that "everybody" just has the capability. They don't, and don't care, and you really need to accomodate that.
Whatever volunteer was fielding the "info" address at the time clearly missed the point, preferring to continue drinking the "security theatre" kool-aid that is dismayingly common around the internet just because it's trendy. There is still absolutely no point to enforced transport encryption for completely public-domain content. I had offered them a reasonable alternative, and they just blew it off.
From: Wikipedia Volunteer Response Team <email@example.com> Subject: Re: [Ticket#2019121690076851] Your TLS "upgrade" ... My understanding is that we have been HTTPS-only since 2015, so as far as "forcibly encrypt[ing] all connections" is concerned, we're well past that point. The question now is just what level of security to require in the encryption. (See https://doesmysiteneedhttps.com/ for some rationales.) As you have noticed, our documentation on this is a bit outdated; thanks for pointing that out. I have removed the sentence you referred to, since it is no longer true. I would point to this sentence in the third paragraph: "In the future, Wikimedia may require stronger minimum levels of cryptographic abilities from your computer or mobile device in order to access our sites like Wikipedia." (That will need to be updated too, since the future is now the present.) Yours sincerely, Benjamin Ashburn Wikipedia - https://en.wikipedia.org/ --- Disclaimer: all mail to this address is answered by volunteers, and responses are not to be considered an official statement of the Wikimedia Foundation. For official correspondence, please contact the Wikimedia Foundation by certified mail at the address listed on https://www.wikimediafoundation.org/
Rationales aside, a malicious party interested enough in our content is going to MITM the SSL anyway, likely enough with a verifiable certificate so the process depends less on the user clicking away those annoying security warnings. In most of the proposed attack scenarios, TLS "fixes" absolutely nothing.
Feel free to call or write Wikimedia and add your own voice, especially if you have personal interest in helping the computationally disadvantaged still be able to reach useful content. They appear to have a working phone number, 415-839-6885 -- archived here in case they decide to remove it from their contact page and further distance themselves from their user base.
Of some ironic note, the "accessibility" address that I had CCed *bounced* as an invalid Google address. So clearly, universal accessibility is a secondary concern for them now.