Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

Matt Harris matt at netfire.net
Tue Dec 31 16:16:09 UTC 2019


On Tue, Dec 31, 2019 at 9:11 AM Seth Mattinen <sethm at rollernet.us> wrote:

> On 12/31/19 12:50 AM, Ryan Hamel wrote:
> > Just let the old platforms ride off into the sunset as originally
> > planned like the SSL implementations in older JRE installs, XP, etc. You
> > shouldn't be holding onto the past.
>
>
> Because poor people anywhere on earth that might not have access to the
> newer technology don't deserve access to Wikipedia, right? Gotta make
> sure information is only accessible to those with means to keep "lesser"
> people out.
>

The better solution here isn't to continue to support known-flawed
protocols, which perhaps puts those same populations you're referring to
here at greatest risk, but rather to enable access to open technologies for
those populations which ensures that they can continue to receive security
updates from a vendor that doesn't have a big financial motive to deprecate
devices and force users to purchase upgraded hardware instead of just
receiving security updates to their existing devices.

On Tue, Dec 31, 2019 at 10:07 AM Mike Hammett <nanog at ics-il.net> wrote:

> If you want the increased security and can afford so, by all means use it.
>
> If you cannot afford the increased security, I guess the response is to
> just bugger off...  we don't need your kind?
>

I'm curious how increased security necessarily costs significant amounts of
money. The bandwidth used to download a package or the source code for the
latest version of OpenSSL (or any number of other crypto libraries) is
relatively negligible. The issue only arises when folks are trapped in
expensive upgrade cycles by vendors with the aforementioned financial
motives.

I don't have a great solution to income inequality and economic disparity
on a whole, but the solution to this specific issue is definitely not to
put those populations at risk by encouraging them and others to continue
using known-flawed technology.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20191231/8d523e74/attachment.html>


More information about the NANOG mailing list