Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read
Dear all, It came to my attention that anyone visiting en.wikipedia.org site from an "old Android smartphone", as Wikipedia puts it, will be redirected to https://en.wikipedia.org/sec-warning ( http://web.archive.org/web/20191217154700/https://en.wikipedia.org/sec-warni...), which, amongst other things, reads the following: #### : 中文: 维基百科正在使网站更加安全。您正在使用旧的浏览器，这在将来无法连接维基百科。请更新您的设备或联络您的IT管理员。以下提供更长，更具技术性的更新（仅英语）。 : : We are removing support for insecure TLS protocol versions, specifically TLSv1.0 and TLSv1.1, which your browser software relies on to connect to our sites. This is usually caused by using some ancient browser or user agents like old Android smartphones. 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 Jan 1, 2020. 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. #### This is yet another assault on the less fortunate folk for absolutely no valid technical reason. Yet another assault on the free flow of information. Everyone should be able to access an encyclopaedia without any such restrictions; wasn't that the whole original premise behind Wikipedia in the first place? Why are they now precluding valid users from having access? What happened with the idea of following Postel's law? http://web.archive.org/web/20191212212040/https://en.wikipedia.org/wiki/Robu... If you have an old iPad device lying around, why should you be precluded from having access to an encyclopaedia? A Google search reveals that there's already iOS users receiving these messages, too. (BTW, Google Search itself still works fine over plain HTTP — FYI — as does Bing and Baidu, but not Yandex.) If anyone is aware of a tracking-free TLS-free mirror, LMK. I cannot link to Wikipedia in good conscience anymore knowing that they block folks left and right now. C.
On Tue, 31 Dec 2019 at 01:40, Quan Zhou <quan@posteo.net> wrote:
On 12/31/19 15:34, Constantine A. Murenin wrote:
removing support for insecure TLS protocol versions, specifically TLSv1.0 and TLSv1.1
This is actually a good thing. There are many *valid technical reasons* behind this. You should do this too.
There's a far better use for port 443. C.
Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why not either let it fall back to 1.0 or to HTTP. This seems like security for no valid reason.
On Tue, 31 Dec 2019 at 02:29, Matt Hoppes <mattlists@rivervalleyinternet.net> wrote:
Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why not either let it fall back to 1.0 or to HTTP.
This seems like security for no valid reason.
Exactly. I used the wording from their own page; but I think it's actually misleading. They're actually going out of their way to prevent users of "old Android smartphones" from accessing Wikipedia; if they did nothing, everyone would still be able to read happily over HTTP. C.
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. Ryan On Tue, Dec 31, 2019, 12:41 AM Constantine A. Murenin <mureninc@gmail.com> wrote:
On Tue, 31 Dec 2019 at 02:29, Matt Hoppes < mattlists@rivervalleyinternet.net> wrote:
Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why not either let it fall back to 1.0 or to HTTP.
This seems like security for no valid reason.
Exactly. I used the wording from their own page; but I think it's actually misleading. They're actually going out of their way to prevent users of "old Android smartphones" from accessing Wikipedia; if they did nothing, everyone would still be able to read happily over HTTP.
C.
Ignoring the obvious reasons why TLS is needed and HTTP should not be used, I guess people who want an HTTP version of Wikipedia that is read-only and knowingly insecure, censorable, modifiable, etc. can donate a few million dollars to the Wikimedia Foundation, before the tax year is over, for the engineers, infrastructure, and everything, and write a special note, and maybe Wikipedia may consider this.. Worst case, you just funded a secure encyclopedia and helped it grow in 2020 and years to come.. :) Let’s see those receipts coming!
On 31 Dec 2019, at 09:50, Ryan Hamel <ryan@rkhtech.org> 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.
Ryan
On Tue, Dec 31, 2019, 12:41 AM Constantine A. Murenin <mureninc@gmail.com <mailto:mureninc@gmail.com>> wrote: On Tue, 31 Dec 2019 at 02:29, Matt Hoppes <mattlists@rivervalleyinternet.net <mailto:mattlists@rivervalleyinternet.net>> wrote: Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why not either let it fall back to 1.0 or to HTTP.
This seems like security for no valid reason.
Exactly. I used the wording from their own page; but I think it's actually misleading. They're actually going out of their way to prevent users of "old Android smartphones" from accessing Wikipedia; if they did nothing, everyone would still be able to read happily over HTTP.
C.
On Tuesday, 31 December, 2019 02:48, Antonios Chariton <daknob.mac@gmail.com> wrote:
Ignoring the obvious reasons why TLS is needed and HTTP should not be used,
I am curious -- what exactly are those "obvious reasons"? (And for the record HTTP *IS* being used, it is just being tunneled inside a TLS connection). I certainly cannot fathom any "obvious reasons" ... -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
On Tue, Dec 31, 2019 at 4:17 AM Keith Medcalf <kmedcalf@dessus.com> wrote:
I am curious -- what exactly are those "obvious reasons"? (And for the record HTTP *IS* being used, it is just being tunneled inside a TLS connection).
For a popular site, it would be doing a disservice to its customers by not using HTTPS, even for static content. https://www.usenix.org/system/files/conference/foci15/foci15-paper-marczak.p...
Not having available for use, yes. But mandating it? On Mon, Jan 6, 2020 at 3:58 AM Yang Yu <yang.yu.list@gmail.com> wrote:
On Tue, Dec 31, 2019 at 4:17 AM Keith Medcalf <kmedcalf@dessus.com> wrote:
I am curious -- what exactly are those "obvious reasons"? (And for the record HTTP *IS* being used, it is just being tunneled inside a TLS connection).
For a popular site, it would be doing a disservice to its customers by not using HTTPS, even for static content.
https://www.usenix.org/system/files/conference/foci15/foci15-paper-marczak.p...
-- Jeff Shultz Central Office Technician SCTC (503) 769-2125 Go Big Ask for Gig -- Like us on Social Media for News, Promotions, and other information!! <https://www.facebook.com/SCTCWEB/> <https://www.instagram.com/sctc_503/> <https://www.yelp.com/biz/sctc-stayton-3> <https://www.youtube.com/c/sctcvideos> _**** This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ****_
"obvious reasons" ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Antonios Chariton" <daknob.mac@gmail.com> To: "North American Network Operators' Group" <nanog@nanog.org> Sent: Tuesday, December 31, 2019 3:47:58 AM Subject: Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read Ignoring the obvious reasons why TLS is needed and HTTP should not be used, I guess people who want an HTTP version of Wikipedia that is read-only and knowingly insecure, censorable, modifiable, etc. can donate a few million dollars to the Wikimedia Foundation, before the tax year is over, for the engineers, infrastructure, and everything, and write a special note, and maybe Wikipedia may consider this.. Worst case, you just funded a secure encyclopedia and helped it grow in 2020 and years to come.. :) Let’s see those receipts coming! On 31 Dec 2019, at 09:50, Ryan Hamel < ryan@rkhtech.org > 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. Ryan On Tue, Dec 31, 2019, 12:41 AM Constantine A. Murenin < mureninc@gmail.com > wrote: <blockquote> On Tue, 31 Dec 2019 at 02:29, Matt Hoppes < mattlists@rivervalleyinternet.net > wrote: <blockquote> Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why not either let it fall back to 1.0 or to HTTP. This seems like security for no valid reason. Exactly. I used the wording from their own page; but I think it's actually misleading. They're actually going out of their way to prevent users of "old Android smartphones" from accessing Wikipedia; if they did nothing, everyone would still be able to read happily over HTTP. C. </blockquote> </blockquote>
Some don't have the fiscal or logistical ability to do better. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Ryan Hamel" <ryan@rkhtech.org> To: "Constantine A. Murenin" <mureninc@gmail.com> Cc: "North American Network Operators' Group" <nanog@nanog.org> Sent: Tuesday, December 31, 2019 2:50:55 AM Subject: Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read 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. Ryan On Tue, Dec 31, 2019, 12:41 AM Constantine A. Murenin < mureninc@gmail.com > wrote: On Tue, 31 Dec 2019 at 02:29, Matt Hoppes < mattlists@rivervalleyinternet.net > wrote: <blockquote> Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why not either let it fall back to 1.0 or to HTTP. This seems like security for no valid reason. Exactly. I used the wording from their own page; but I think it's actually misleading. They're actually going out of their way to prevent users of "old Android smartphones" from accessing Wikipedia; if they did nothing, everyone would still be able to read happily over HTTP. C. </blockquote>
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.
I still don’t see any multi-million dollar donation receipts though.. So if we want to do this, do we sacrifice security for the 99.9% or do we have Wikimedia pay the bill? Oh, BTW, I have some network equipment with only 16-bit ASN support, or no large communities, or no IPv6, or no AES, or no BGP4, or no RPKI, or no [...] so I don’t know if it’s late but maybe we should revert at least some of those, because they’re not really needed.. The internet is broken anyways, so we don’t need more ASNs, or security, or connectivity anyways.. Oh, and it can do only 10 Mbit Ethernet, so my buffers fill up with anything at GbE or above, can we scrap them too? On a serious note, I don’t think TLS does not provide validation of the server just because the Web PKI system is broken, and I don’t think TLS doesn’t provide security or privacy. And I also believe they are needed. There are many scenarios where they are vital.. - They protect against modifying content: now if an anonymous edit is made, everyone will see and revert it, without TLS everyone could see a different thing and we wouldn’t know. - They protect against knowing what people browse (privacy): I don’t want others to know what information I look up on Wikipedia, or at least more people than necessary. Someone mentioned that if I have this requirement I should work towards it. I think most people have this requirement and it’s easier if Wikipedia works towards it, than everyone setting up a network and peering directly with every website they want to use. I am usually in favor of replacing things if possible that hold back everyone else, even if it hurts. We’re not throwing away last year’s phones, but devices closing 10 years in life. If we want devices we want to keep, and reduce e-waste and all that, we should find a way to keep them up to date, not demand that nobody makes any progress.. If Android could get updates (I think it can now) we could just add TLS 1.2 and TLS 1.3 by backporting. No new features, just essentials. But for some reason, someone, not necessarily in the Android team, and for some reason, decided that it’s not a priority. Would we accept network equipment that doesn’t receive updates? Maybe, due to cost. But should we, or just maybe put some pressure on the manufacturer to support it for more than 3 months? There’s a debate on how long the new cars should receive software updates. People keep them for over 15 years. Should we replace our cars every 2? No. The manufacturers should support them for a reasonable period, and then we should accept that some features will stop working. Now you may say if the car manufacturer stops producing parts after 2 years, you can find some third party ones. Well, nobody stops you from operating a reverse proxy for Wikipedia at unsafewikipedia.org, but the pros and cons there are different..
On 31 Dec 2019, at 17:12, Seth Mattinen <sethm@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.
On 12/31/19 07:10, Seth Mattinen 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.
Argumentation on the basis of a tu quoque fallacy doesn't really add much to the dicussion. Depreciating potentialy dangerous and definitely obsolete protocols does not make you a hypocrite. TLS 1.0 is genuinely hard to support at this point. Doing so limits the tooling you can use, It limits the CDNs that you can use. It forces you to use obsolete codes bases.
joel jaeggli wrote on 31/12/2019 18:10:
TLS1.0 is genuinely hard to support at this point. Doing so limits the tooling you can use, It limits the CDNs that you can use. It forces you to use obsolete codes bases.
not just that, TLS 1.2 has been around since 2008, i.e. 1 month before android 1.0 was released. Seems odd that it took until 2015 for it to be included by default. Nick
On 12/31/19 8:10 AM, joel jaeggli wrote:
Argumentation on the basis of a tu quoque fallacy doesn't really add much to the dicussion. Depreciating potentialy dangerous and definitely obsolete protocols does not make you a hypocrite.
Then how about privilege? If someone is living in a less-privileged situation (oppressive regime, state controlled ISP, extreme poverty, whatever) there's also a good chance that such people may not able to acquire newer/updated technology easily, perhaps not even legally at great risk. I will disagree with anyone's assertion that people in such conditions deserve to be disenfranchised.
On Tue, Dec 31, 2019 at 17:26 Seth Mattinen <sethm@rollernet.us> wrote:
On 12/31/19 8:10 AM, joel jaeggli wrote:
Argumentation on the basis of a tu quoque fallacy doesn't really add much to the dicussion. Depreciating potentialy dangerous and definitely obsolete protocols does not make you a hypocrite.
Then how about privilege?
If someone is living in a less-privileged situation (oppressive regime, state controlled ISP, extreme poverty, whatever) there's also a good chance that such people may not able to acquire newer/updated technology easily, perhaps not even legally at great risk. I will disagree with anyone's assertion that people in such conditions deserve to be disenfranchised.
I’m not entirely sure an argument based on privilege applies cleanly here. There are freely supported (open source) TLS 1.2 / TLS 1.3 implementations available for download - at no cost - that run on commodity hardware, even as old as i386 cpu chips. Kind regards, Job
On 12/31/19 08:25, Seth Mattinen wrote:
On 12/31/19 8:10 AM, joel jaeggli wrote:
Argumentation on the basis of a tu quoque fallacy doesn't really add much to the dicussion. Depreciating potentialy dangerous and definitely obsolete protocols does not make you a hypocrite.
Then how about privilege?
If someone is living in a less-privileged situation (oppressive regime, state controlled ISP, extreme poverty, whatever) there's also a good chance that such people may not able to acquire newer/updated technology easily, perhaps not even legally at great risk. I will disagree with anyone's assertion that people in such conditions deserve to be disenfranchised.
You cite a hypothetical situation that may, but does not in my experience exist, I work with customers who had populations of impacted devices, so the consequences and timing of these transitions are directly consequential to our customers. Most CDNs turned off tls 1.0 by early to mid-2018. The mobile devices that still required it at the time and did not have an alternative were a vanishingly small portion of the population then in use (for example legacy docomo i-mode handsets), and the ones that cannot support it now are still smaller, Lacking support for SNI was a signification consumer of address consumption in CDNs and that contributes to accessibility cost and usability issues for websites attempts at universal tls deployment as well so we should be clear that there are plenty of people who were disenfranchised by or burdened with otherwise unnecessary costs by the need to support tls 1.0. Most populations have recourse to application alternatives that can and did extend their useful service life to tls 1.2 (current firefox supports back to android 4.1 for example, Opera mini /mobile have much larger market shares in bandwidth constrained environments and superior performance on low end devices). tls 1.1 is not really far on the heels of 1.0. hence you see this now.
On Tue, Dec 31, 2019 at 6:12 AM Seth Mattinen <sethm@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.
This. I visited a rural school in South Africa around 2008. For many things - such as using their cellphone provider's billing infrastructure to pay for third-party services via SMS - a switch to TLS 1.2 only would probably have no impact. But for educational purposes, their reliance on Wikipedia was dramatic - and they could *only* get to it from outdated phones that had been donated, scavenged, or cobbled together from parts. In the intervening years, the disposable-electronics culture has probably been a great boon to them, bringing better and more tech - but much of it is probably still pre Android 4.4.2 But perhaps Wikipedia's decision is based on actual data. I'd love to see percentages of their negotiated TLS ciphers, per country and per client type. Back in 2015, you could see them as discussed here: https://news.ycombinator.com/item?id=10194258 ... but I'm not sure where the equivalent data would be in the new Grafana data: https://grafana.wikimedia.org/?orgId=1 Royce
There are really two arguments here. 1. TLSv1.0 is insecure and should never be used in an HTTPS scenario - cant argue with this 2. Alot of static content sites are forcing HTTPS even though “technically” there is nothing that needs to be secured in transit - this is where the argument lies. Why does access to wikipedia need to go over https? There is no login, no credit card or SSNs being transferred, etc.,. Part of the blame is google, they started penalize sites in their index if they didn’t do https, as a result, almost every website now does ssl - everything from allrecipes.com <http://allrecipes.com/> to a mommy blog, literally you cant find a non-ssl website anymore, everybody wants the better google rank, so they all gave in and went 100% ssl. There is a reason however for search engines to enforce https, its a privacy issue, everyone is snooping on you, so if you dont want your ISP knowing what your searching for (http://search.com/?q=looking+for+a+divorce+lawyer) and then selling that info to advertisers, you need https - and yes Wiki is sort of search engine. What I foresee happening is people will come up with a 3rd party solution, basically, you’ll start seeing people offer http->https proxy services, it will be interesting to see if the content source providers try to clamp down on this or let it happen… -John
On Dec 31, 2019, at 11:11 AM, Royce Williams <royce@techsolvency.com> wrote:
On Tue, Dec 31, 2019 at 6:12 AM Seth Mattinen <sethm@rollernet.us <mailto:sethm@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.
This.
I visited a rural school in South Africa around 2008.
For many things - such as using their cellphone provider's billing infrastructure to pay for third-party services via SMS - a switch to TLS 1.2 only would probably have no impact.
But for educational purposes, their reliance on Wikipedia was dramatic - and they could *only* get to it from outdated phones that had been donated, scavenged, or cobbled together from parts.
In the intervening years, the disposable-electronics culture has probably been a great boon to them, bringing better and more tech - but much of it is probably still pre Android 4.4.2
But perhaps Wikipedia's decision is based on actual data. I'd love to see percentages of their negotiated TLS ciphers, per country and per client type. Back in 2015, you could see them as discussed here:
https://news.ycombinator.com/item?id=10194258 <https://news.ycombinator.com/item?id=10194258>
... but I'm not sure where the equivalent data would be in the new Grafana data:
https://grafana.wikimedia.org/?orgId=1 <https://grafana.wikimedia.org/?orgId=1>
Royce
because no one should know what you read about or check out at wikipedia Sent from my iPhone
On Dec 31, 2019, at 00:30, Matt Hoppes <mattlists@rivervalleyinternet.net> wrote:
Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why not either let it fall back to 1.0 or to HTTP.
This seems like security for no valid reason.
... because you should be able to verify the site you are at is actually the site you intended to be at... Let the old crap go. Besides the sheer amount of ppl left that have the older phones most likely are not going to Wikipedia anyway. -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.
On Dec 31, 2019, at 04:05, John Adams <jna@retina.net> wrote:
because no one should know what you read about or check out at wikipedia
Sent from my iPhone
On Dec 31, 2019, at 00:30, Matt Hoppes <mattlists@rivervalleyinternet.net> wrote:
Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why not either let it fall back to 1.0 or to HTTP.
This seems like security for no valid reason.
Just to make it clear: are you suggesting that it should be a requirement to always verify the site where anonymous people make anonymous edits? Let that sink in. C. On Tue, 31 Dec 2019 at 05:31, J. Hellenthal <jhellenthal@dataix.net> wrote:
... because you should be able to verify the site you are at is actually the site you intended to be at...
Let the old crap go. Besides the sheer amount of ppl left that have the older phones most likely are not going to Wikipedia anyway.
-- J. Hellenthal
The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.
On Dec 31, 2019, at 04:05, John Adams <jna@retina.net> wrote:
because no one should know what you read about or check out at wikipedia
Sent from my iPhone
On Dec 31, 2019, at 00:30, Matt Hoppes < mattlists@rivervalleyinternet.net> wrote:
Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why not either let it fall back to 1.0 or to HTTP.
This seems like security for no valid reason.
On Tuesday, 31 December, 2019 04:44, Constantine A. Murenin <mureninc@gmail.com> wrote:
Just to make it clear: are you suggesting that it should be a requirement to always verify the site where anonymous people make anonymous edits? Let that sink in.
TLS 1.2 as deployed in Web Browsers does not authenticate the end-point. What it does is present an "Advertizing ID" that is akin to the "Advertizing ID" that the telco's sold as "Caller ID", because they new that y'all proles would not pay if there were truth in naming. By the same token the general certificate system will "say" whatever he who pays wants it to say. It does not verify anything other than the fact that the remote end-point went to the bother of buying (or the trouble of fiddling about with) advertizing certificates. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
" the sheer amount of ppl left that have the older phones most likely are not going to Wikipedia anyway." Why? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "J. Hellenthal via NANOG" <nanog@nanog.org> To: "John Adams" <jna@retina.net> Cc: "Constantine A. Murenin" <mureninc@gmail.com>, "North American Network Operators' Group" <nanog@nanog.org> Sent: Tuesday, December 31, 2019 5:30:58 AM Subject: Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read ... because you should be able to verify the site you are at is actually the site you intended to be at... Let the old crap go. Besides the sheer amount of ppl left that have the older phones most likely are not going to Wikipedia anyway. -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.
On Dec 31, 2019, at 04:05, John Adams <jna@retina.net> wrote:
because no one should know what you read about or check out at wikipedia
Sent from my iPhone
On Dec 31, 2019, at 00:30, Matt Hoppes <mattlists@rivervalleyinternet.net> wrote:
Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why not either let it fall back to 1.0 or to HTTP.
This seems like security for no valid reason.
Well, that would be nothing, because they're blocking your device from having any access. C. On Tue, 31 Dec 2019 at 04:04, John Adams <jna@retina.net> wrote:
because no one should know what you read about or check out at wikipedia
Sent from my iPhone
On Dec 31, 2019, at 00:30, Matt Hoppes < mattlists@rivervalleyinternet.net> wrote:
Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why not either let it fall back to 1.0 or to HTTP.
This seems like security for no valid reason.
If you care that bad, you work towards meeting the requirement. If you don't care, then you don't. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "John Adams" <jna@retina.net> To: "Matt Hoppes" <mattlists@rivervalleyinternet.net> Cc: "Constantine A. Murenin" <mureninc@gmail.com>, "North American Network Operators' Group" <nanog@nanog.org> Sent: Tuesday, December 31, 2019 4:04:54 AM Subject: Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read because no one should know what you read about or check out at wikipedia Sent from my iPhone
On Dec 31, 2019, at 00:30, Matt Hoppes <mattlists@rivervalleyinternet.net> wrote:
Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why not either let it fall back to 1.0 or to HTTP.
This seems like security for no valid reason.
On Dec 31, 2019, at 00:30, Matt Hoppes <mattlists@rivervalleyinternet.net> wrote:
Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why not either let it fall back to 1.0 or to HTTP.
This seems like security for no valid reason.
On Dec 31, 2019, at 04:04, John Adams <jna@retina.net> wrote:
because no one should know what you read about or check out at wikipedia
On Tue, 31 Dec 2019, Mike Hammett wrote:
If you care that bad, you work towards meeting the requirement. If you don't care, then you don't.
What happens when you care but your current environment, one in which a new-ish phone, tablet, laptop or desktop is not readily available or at a price point that you cannot afford without starving yourself and your family? If there are technically and free-speech reasons to force TLSv1.2, provide an HTTP version that restricts edits or whatever technical reasons Wikimedia Corp is changing for. This may only affect 1% of Wikipedia users, but 1% in a world of 4.48 billion Internet-using humans, where the US population is 4.27% of the world population, 1% is a HUGE number. 1% is about the size of Uganda or Argentina. You and I, sitting comfortably in North America, sipping our Starbucks Latte while casually surfing on our iPads and Lenovos, may have zero problem accessing everything using TLSv1.2. But my iPhone from 2007 won't, despite it still being functional. Let us stand for freedom, free speech, openness and sharing in a world that seems to forget how we got here in the first place. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
I normally don't chime in here, because I'm not technically a network operator, but I do know certs and PKI infrastructure. Just wanted to point out that many situations where such security would be desirable -- a repressive government, an overly surveilling employer -- have, or can easily put in place, tech to subvert the entire process anyway. Require every browser to include a custom CA certificate, issue certs on the fly for any given site, and The Man can MITM every site you visit, supporting whatever protocol your device requires. Requiring TLS 1.2 won't fix this -- it's an attempt to minimize the risk of specific protocol-based attacks at the expense of older browsers. That having been said, I'd like to see actual numbers on how many of Wikimedia's sites' visitors will be affected. What percentage of browsers visiting their sites can't support TLS 1.2 or later? -- Jim Goltz <jgoltz@mail.nih.gov> HHS/NIH/CIT/Network Services -----Original Message----- From: John Adams <jna@retina.net> Sent: Tuesday, 31 December, 2019 05:05 To: Matt Hoppes <mattlists@rivervalleyinternet.net> Cc: Constantine A. Murenin <mureninc@gmail.com>; North American Network Operators' Group <nanog@nanog.org> Subject: Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read because no one should know what you read about or check out at wikipedia Sent from my iPhone
On Dec 31, 2019, at 00:30, Matt Hoppes <mattlists@rivervalleyinternet.net> wrote:
Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why not either let it fall back to 1.0 or to HTTP.
This seems like security for no valid reason.
On Tue, Dec 31, 2019 at 2:30 AM Matt Hoppes < mattlists@rivervalleyinternet.net> wrote:
Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why not either let it fall back to 1.0 or to HTTP.
This seems like security for no valid reason.
Being able to authenticate that the content you've requested is coming from the source from which you requested it seems like a pretty valid reason to me. If you live in a privileged nation with democratic governance, and you have ISP choice and your ISP doesn't and won't hijack your connections and you're not otherwise in an environment where your connections may be hijacked for any number of reasons by any number of parties, then you may not think about this very much. Employing the best (popular, well-supported, well-documented, completely open) current standard, TLS 1.2, instead of supporting deprecated, known-flawed previous versions of that protocol also seems like an entirely reasonable idea, too. If you don't like that this potentially disenfranchises users of old devices (and there's perhaps a case to be made here), then the ire should be imho directed towards the device vendors for not issuing security updates for whatever version you wish were able to support modern technology. Not at free web-based services for ending support for deprecated, known-flawed protocols/ciphers/etc. If google wanted to issue an update for older android versions to support TLS1.2 then they absolutely could, though users may see some detrimental performance impact to using modern technology on an outdated device. This isn't a new issue, and we as the greater internet community have generally tackled it by taking aggressive measures towards deprecating known-flawed technologies on a conservative timeline. RFC5246 was published over a decade ago. - mdh
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? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Matt Harris" <matt@netfire.net> To: "Matt Hoppes" <mattlists@rivervalleyinternet.net> Cc: "Constantine A. Murenin" <mureninc@gmail.com>, "North American Network Operators' Group" <nanog@nanog.org> Sent: Tuesday, December 31, 2019 10:02:26 AM Subject: Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read On Tue, Dec 31, 2019 at 2:30 AM Matt Hoppes < mattlists@rivervalleyinternet.net > wrote: Why do I need Wikipedia SSLed? I know the argument. But if it doesn’t work why not either let it fall back to 1.0 or to HTTP. This seems like security for no valid reason. Being able to authenticate that the content you've requested is coming from the source from which you requested it seems like a pretty valid reason to me. If you live in a privileged nation with democratic governance, and you have ISP choice and your ISP doesn't and won't hijack your connections and you're not otherwise in an environment where your connections may be hijacked for any number of reasons by any number of parties, then you may not think about this very much. Employing the best (popular, well-supported, well-documented, completely open) current standard, TLS 1.2, instead of supporting deprecated, known-flawed previous versions of that protocol also seems like an entirely reasonable idea, too. If you don't like that this potentially disenfranchises users of old devices (and there's perhaps a case to be made here), then the ire should be imho directed towards the device vendors for not issuing security updates for whatever version you wish were able to support modern technology. Not at free web-based services for ending support for deprecated, known-flawed protocols/ciphers/etc. If google wanted to issue an update for older android versions to support TLS1.2 then they absolutely could, though users may see some detrimental performance impact to using modern technology on an outdated device. This isn't a new issue, and we as the greater internet community have generally tackled it by taking aggressive measures towards deprecating known-flawed technologies on a conservative timeline. RFC5246 was published over a decade ago. - mdh
On Tue, Dec 31, 2019 at 9:11 AM Seth Mattinen <sethm@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@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.
On Tue, Dec 31, 2019 at 7:17 AM Matt Harris <matt@netfire.net> wrote:
On Tue, Dec 31, 2019 at 9:11 AM Seth Mattinen <sethm@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.
Unfortunately, this is the high-tech privilege equivalent of saying "let them eat cake" - because of upgrade friction on mobile in under-resources areas (including, I might add, specific sub-populations of US consumers!) If there were reliable, official, clean replacement Androrid ROMs for older hardware, the cottage industry of end-user phone repair in many countries could take a perfectly good phone and get basic modern services working on it. But there aren't - and there's little financial motivation for the phone OEMs to provide one. And there isn't really much you can do to replace the OS on an old iPhone, either. One of the best things that Google could do for the security of the Android ecosystem is to provide clean, OEM-bloat-free, reference ROMs for older phones with minimal backported security updates. I would expect that such ROMs must actually exist internally, as needed for OEM patch integration testing. The answer to why such ROMs will likely not be made publicly available is left as an exercise for the reader. Royce
No one mentioned the passwords need to be encrypted? Why have an old encryption method that isn't secure? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Tue, Dec 31, 2019 at 11:34 AM Royce Williams <royce@techsolvency.com> wrote:
On Tue, Dec 31, 2019 at 7:17 AM Matt Harris <matt@netfire.net> wrote:
On Tue, Dec 31, 2019 at 9:11 AM Seth Mattinen <sethm@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.
Unfortunately, this is the high-tech privilege equivalent of saying "let them eat cake" - because of upgrade friction on mobile in under-resources areas (including, I might add, specific sub-populations of US consumers!)
If there were reliable, official, clean replacement Androrid ROMs for older hardware, the cottage industry of end-user phone repair in many countries could take a perfectly good phone and get basic modern services working on it.
But there aren't - and there's little financial motivation for the phone OEMs to provide one. And there isn't really much you can do to replace the OS on an old iPhone, either.
One of the best things that Google could do for the security of the Android ecosystem is to provide clean, OEM-bloat-free, reference ROMs for older phones with minimal backported security updates. I would expect that such ROMs must actually exist internally, as needed for OEM patch integration testing.
The answer to why such ROMs will likely not be made publicly available is left as an exercise for the reader.
Royce
On Tue, Dec 31, 2019 at 7:32 AM Royce Williams <royce@techsolvency.com> wrote:
On Tue, Dec 31, 2019 at 7:17 AM Matt Harris <matt@netfire.net> wrote:
On Tue, Dec 31, 2019 at 9:11 AM Seth Mattinen <sethm@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.
Unfortunately, this is the high-tech privilege equivalent of saying "let them eat cake" - because of upgrade friction on mobile in under-resources areas (including, I might add, specific sub-populations of US consumers!)
If there were reliable, official, clean replacement Androrid ROMs for older hardware, the cottage industry of end-user phone repair in many countries could take a perfectly good phone and get basic modern services working on it.
But there aren't - and there's little financial motivation for the phone OEMs to provide one. And there isn't really much you can do to replace the OS on an old iPhone, either.
One of the best things that Google could do for the security of the Android ecosystem is to provide clean, OEM-bloat-free, reference ROMs for older phones with minimal backported security updates. I would expect that such ROMs must actually exist internally, as needed for OEM patch integration testing.
The answer to why such ROMs will likely not be made publicly available is left as an exercise for the reader.
But perhaps you were suggesting that a *grass-roots* effort to create such ROMs might be in order? I would love to donate to such a project. But short of a million-dollar grant, or legislation, I am not optimistic. Royce
On Tue, Dec 31, 2019 at 10:34 AM Royce Williams <royce@techsolvency.com> wrote:
On Tue, Dec 31, 2019 at 7:17 AM Matt Harris <matt@netfire.net> wrote:
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.
Unfortunately, this is the high-tech privilege equivalent of saying "let them eat cake" - because of upgrade friction on mobile in under-resources areas (including, I might add, specific sub-populations of US consumers!)
Perhaps more unfortunately, the other option - to continue supporting known-flawed protocols - is simply saying "let them be victimized." Accepting that we should instead support technologies that place those very same populations at risk is coming from a place of privilege for the reasons I mentioned previously: you live somewhere with relatively peaceful/democratic governance, usually have at least some ISP choice, and are likely not otherwise under the thumb of an oppressive regime at some level of another - so when your browser makes a TLS1.0 connection, you probably don't even think about it, much less worry about it, because you don't have to. The populations we're discussing here, on the other hand, all too often do. What it comes down to is a question of whether we want to solve what we know today is a real problem or let it fester until abuse reaches an untenable level in some big, news-headline-making way. One way we can combat this specific issue is to make open technologies accessible. But that requires major investment on our side of the world, and prior attempts to do so (Ubuntu's open source phone OS for example) have largely been commercial flops. - mdh
On Tue, Dec 31, 2019 at 7:46 AM Matt Harris <matt@netfire.net> wrote:
On Tue, Dec 31, 2019 at 10:34 AM Royce Williams <royce@techsolvency.com> wrote:
On Tue, Dec 31, 2019 at 7:17 AM Matt Harris <matt@netfire.net> wrote:
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.
Unfortunately, this is the high-tech privilege equivalent of saying "let them eat cake" - because of upgrade friction on mobile in under-resources areas (including, I might add, specific sub-populations of US consumers!)
Perhaps more unfortunately, the other option - to continue supporting known-flawed protocols - is simply saying "let them be victimized."
With the rise of state-level disinformation at scale, I see your point.
Accepting that we should instead support technologies that place those very same populations at risk is coming from a place of privilege for the reasons I mentioned previously: you live somewhere with relatively peaceful/democratic governance, usually have at least some ISP choice, and are likely not otherwise under the thumb of an oppressive regime at some level of another - so when your browser makes a TLS1.0 connection, you probably don't even think about it, much less worry about it, because you don't have to. The populations we're discussing here, on the other hand, all too often do.
What it comes down to is a question of whether we want to solve what we know today is a real problem or let it fester until abuse reaches an untenable level in some big, news-headline-making way. One way we can combat this specific issue is to make open technologies accessible. But that requires major investment on our side of the world, and prior attempts to do so (Ubuntu's open source phone OS for example) have largely been commercial flops.
Indeed. Though a non-commercial (grass-roots, sponsored, or legislative) solution seems similarly unlikely. Royce
Silicon Valley is typically out of touch with reality. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Constantine A. Murenin" <mureninc@gmail.com> To: "North American Network Operators' Group" <nanog@nanog.org> Sent: Tuesday, December 31, 2019 1:34:19 AM Subject: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read Dear all, It came to my attention that anyone visiting en.wikipedia.org site from an "old Android smartphone", as Wikipedia puts it, will be redirected to https://en.wikipedia.org/sec-warning ( http://web.archive.org/web/20191217154700/https://en.wikipedia.org/sec-warni... ), which, amongst other things, reads the following: #### : 中文: 维基百科正在使网站更加安全。您正在使用旧的浏览器，这在将来无法连接维基百科。请更新您的设备或联络您的IT管理员。以下提供更长，更具技术性的更新（仅英语）。 : : We are removing support for insecure TLS protocol versions, specifically TLSv1.0 and TLSv1.1, which your browser software relies on to connect to our sites. This is usually caused by using some ancient browser or user agents like old Android smartphones. 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 Jan 1, 2020. 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. #### This is yet another assault on the less fortunate folk for absolutely no valid technical reason. Yet another assault on the free flow of information. Everyone should be able to access an encyclopaedia without any such restrictions; wasn't that the whole original premise behind Wikipedia in the first place? Why are they now precluding valid users from having access? What happened with the idea of following Postel's law? http://web.archive.org/web/20191212212040/https://en.wikipedia.org/wiki/Robu... If you have an old iPad device lying around, why should you be precluded from having access to an encyclopaedia? A Google search reveals that there's already iOS users receiving these messages, too. (BTW, Google Search itself still works fine over plain HTTP — FYI — as does Bing and Baidu, but not Yandex.) If anyone is aware of a tracking-free TLS-free mirror, LMK. I cannot link to Wikipedia in good conscience anymore knowing that they block folks left and right now. C.
On Dec 31, 2019, at 8:37 AM, Mike Hammett <nanog@ics-il.net> wrote:
Silicon Valley is typically out of touch with reality.
I think this is a bit over the top and troll-ish but there is a big thing going on in circles where transport integrity and secrecy are tied together when it’s not necessary. Not all mutual authentication needs to be done with certificates (for example). Forcing all of wikipedia to be https is an example of the side-effects of this practice when combined with deprecating older versions of TLS and older ciphers, you will inevitably make the content inaccessible as a result. The thought that we should all upgrade our devices (that work just fine) is a bit of a problem. If I have an old tablet that my kids use to do wikipedia and are now locked out, that’s forcing an expense on the end-user of that tech and creates more e-waste etc than necessary. I’m not a fan of that either, but the painting a broad brush is not helpful to the conversation. - Jared
On Tue, Dec 31, 2019 at 08:45:11AM -0500, Jared Mauch wrote:
On Dec 31, 2019, at 8:37 AM, Mike Hammett <nanog@ics-il.net> wrote:
Silicon Valley is typically out of touch with reality.
[...]
If I have an old tablet that my kids use to do wikipedia and are now locked out, that’s forcing an expense on the end-user of that tech and creates more e-waste etc than necessary. I’m not a fan of that either, but the painting a broad brush is not helpful to the conversation.
I have read this example as illustration of thesis saying "smartphones and {t|ph)ablets are dead-end architecture". If I had a twenty years old laptop (oh wait, I have one) and could install a decent OS on it, and upgrade it a bit or in whole, then I guess the problem with TLS would have been solved for me. If I had a three years old smartphone... ok, I have one, and while it is still usable, I understand that at one point I am not going to receive any new software for it, nor be able to compile it on my own. In a future I might not make old errors again and just buy the cheapest and lousiest smartphone, expecting it would last a year and a day, not giving any more thought about it. Dumbphones, on the other hand, seem to be free of this kind of problems. I am a dumbphone user and it works great. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola@bigfoot.com **
Wikipedia deprecated 1.0 and 1.1 on Jan 1, 2020. Apple, Google, Microsoft, and Mozilla are all deprecating 1.0 and 1.1 in their browsers by March 2020. Chrome will start showing warnings about 1.0 and 1.1 I think next week? This isn't an assault on the free flow of information. On Tue, Dec 31, 2019 at 2:36 AM Constantine A. Murenin <mureninc@gmail.com> wrote:
Dear all,
It came to my attention that anyone visiting en.wikipedia.org site from an "old Android smartphone", as Wikipedia puts it, will be redirected to https://en.wikipedia.org/sec-warning ( http://web.archive.org/web/20191217154700/https://en.wikipedia.org/sec-warni...), which, amongst other things, reads the following:
####
: 中文: 维基百科正在使网站更加安全。您正在使用旧的浏览器，这在将来无法连接维基百科。请更新您的设备或联络您的IT管理员。以下提供更长，更具技术性的更新（仅英语）。 : : We are removing support for insecure TLS protocol versions, specifically TLSv1.0 and TLSv1.1, which your browser software relies on to connect to our sites. This is usually caused by using some ancient browser or user agents like old Android smartphones. 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 Jan 1, 2020. 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.
####
This is yet another assault on the less fortunate folk for absolutely no valid technical reason. Yet another assault on the free flow of information.
Everyone should be able to access an encyclopaedia without any such restrictions; wasn't that the whole original premise behind Wikipedia in the first place? Why are they now precluding valid users from having access? What happened with the idea of following Postel's law? http://web.archive.org/web/20191212212040/https://en.wikipedia.org/wiki/Robu...
If you have an old iPad device lying around, why should you be precluded from having access to an encyclopaedia? A Google search reveals that there's already iOS users receiving these messages, too. (BTW, Google Search itself still works fine over plain HTTP — FYI — as does Bing and Baidu, but not Yandex.)
If anyone is aware of a tracking-free TLS-free mirror, LMK. I cannot link to Wikipedia in good conscience anymore knowing that they block folks left and right now.
C.
participants (25)
-
Antonios Chariton -
Constantine A. Murenin -
DaKnOb
-
Goltz, Jim (NIH/CIT) [E] -
J. Hellenthal -
Jared Mauch -
Jeff Shultz -
Job Snijders -
joel jaeggli -
John Adams -
John Von Essen -
Josh Luthman -
Keith Medcalf -
Matt Harris -
Matt Hoppes -
Mike Hammett -
Nick Hilliard -
Peter Beckman -
Quan Zhou -
Royce Williams -
Ryan Hamel -
Seth Mattinen -
Tom Beecher -
Tomasz Rola -
Yang Yu