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..
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?
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.
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
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.
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
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.
There are really two arguments here.
- TLSv1.0 is insecure and should never be used in an HTTPS scenario - cant argue with this
- 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 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
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?
>
> 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.
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
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
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
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
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
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.
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.pdf