Ivory-tower arrogance in the false pretense of "security"

Wikipedia's arrogant rejection of older client browsers
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: info@wikimedia.org,
   accessibility@wikimedia.org,
   donate@wikimedia.org,
   business@wikimedia.org,
   legal@wikimedia.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 <info-en@wikimedia.org>
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.


_H*   191216