Should Wikipedia Force All Users To Use HTTPS?
from the politics-of-encryption dept
It would be something of an understatement to say that encryption is a hot topic at the moment. But leaving aside deeper issues like the extent to which the Internet's cryptographic systems are compromised, there is a more general question about whether Web sites should be pushing users to connect using HTTPS in the hope that this might improve their security. That might seem a no-brainer, but for the Wikimedia Foundation (WMF), the organization that runs Wikipedia and related projects, it's a more complex issue.
The problem is that HTTPS access is disabled in some countries precisely to prevent users from being able to access sites securely. So when Wikimedia introduced its HTTPS-by-default policy on August 28, it made a couple of exceptions:
Some users live in areas where HTTPS is not an easy option, most times because of explicit blocking by a government. At the request of these communities, we have made an explicit exclusion for users from those affected countries. Simply put, users from China and Iran will not be required to use HTTPS for logging in, nor for viewing any Wikimedia project site.
An interesting post by Erik Möller, the WMF's Deputy Director, raises the question whether such exceptions help or hinder freedom in those countries:
In the long term, the Wikimedia movement is faced with a choice, which is inherently political: Should we indefinitely sustain security exceptions for regions that prevent the use of encryption, or should we shift to an alternative strategy?
Here are some of the considerations he mentions:
If we accommodate [China]'s or Iran's censorship practices, we are complicit in their attempts to monitor and control their citizenry. If a privileged user's credentials (e.g. Checkuser) are misused by the government through monitoring of unencrypted traffic, for example, this is an action that would not have been possible without our exemption. This could potentially expose even users not in the affected country to risks.
Möller goes on to suggest the following:
It could be argued that it's time to draw a line in the sand -- if you're prohibiting the use of encryption, you're effectively not part of the web. You're subverting basic web technologies.
That may have been a defensible position last week, when he wrote those words, but it certainly isn't now. Snowden's information about efforts by the NSA and GCHQ to undermine every form of online encryption shows how they are "subverting basic web technologies" in a profound way; it is therefore no longer possible for the West to wag a finger at countries like China that are doing the same. However, Möller also points out:
Drawing this hard line clearly has negative near term effects on the citizenry of affected countries. But the more the rest of the world comes together in saying "What you are doing is wrong. Stop it." -- the harder it will be for outlier countries to continue doing it.There _are_ effective tools that can be used to circumvent attempts to censor and control the Internet. Perhaps it is time for WMF to ally with the organizations that develop and promote such tools, rather than looking for ways to guarantee basic site operation in hostile environments even at the expense of user privacy.
This is surely a better strategy. It would allow Wikimedia users in countries where HTTPS is blocked to access Wikipedia and related projects in a discreet way. Such circumvention tools could also be useful for many other sites that face the same problem, and so would be a force for combating censorship and control in general. Finally, if the privacy situation in the West continues to deteriorate, the software might even come in handy there, too.
Follow me @glynmoody on Twitter or identi.ca, and on Google+
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: challenges, filtering, https, security, wikipedia
Companies: wikimedia foundation, wikipedia
Reader Comments
The First Word
“While this does not prevent targeted attacks against people, or even trying to decrypt data once some becomes targeted, it does prevent the general spying on everybody. Therefore the more data is encrypted, and the stronger the encryption, the more spy agencies are forced to target their efforts on identified suspects. Breakable encryptions if widely used restores a measure of privacy to most communications, except where the spy agencies can get a decrypted feed from the service providers.
Subscribe: RSS
View by: Time | Thread
This is quite true. And incredibly depressing.
[ link to this | view in chronology ]
Re:
Though even there, there's conspiracy theories with some basis in reality that some elections are fraudulent to (see the Diebold election machine conspiracies that were especially common in 2004, the company doesn't help itself by threatening to sue anyone who wants to look at their code to verify their voting machines are 100% accurate, citing trade secrets).
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Nothing is.
Google may have confidence a string of PlayStation 3 consoles won't break https, but there's nothing saying a floor full of IBM super computers can't.
[ link to this | view in chronology ]
Re:
While this does not prevent targeted attacks against people, or even trying to decrypt data once some becomes targeted, it does prevent the general spying on everybody. Therefore the more data is encrypted, and the stronger the encryption, the more spy agencies are forced to target their efforts on identified suspects. Breakable encryptions if widely used restores a measure of privacy to most communications, except where the spy agencies can get a decrypted feed from the service providers.
[ link to this | view in chronology ]
Re: Re:
Plus once we get in the habit of of using encryption for everything then switching out current encryption for stronger types should be easier because its no longer an afterthought only some people worry about.
[ link to this | view in chronology ]
Using HTTPS in that context gives no security.
Have they thought about GNU TLS v1.2 / DTLS 1.2?
Both are LGPL v3+ Open Source projects. Heavily audited, and very portable.
[ link to this | view in chronology ]
Path dependence
Suppose for a moment Wikipedia goes all the way, and forces HTTPS for everyone, even anonymous readers, like github does.
Suppose then that, after a few years, a third country (not China, Iran, or the USA) decides to also block HTTPS. There would be an incredible backlash, since Wikipedia is very popular. They would not be able to convince Wikipedia to disable HTTPS for them (the only country which might be able to do that would be the USA, since it is where the Wikimedia servers are).
That is, once encryption is the default, it is sticky.
The current exception with China and Iran is the same, in the opposite direction - once encryption is banned, it is hard to enable it by default, since either Wikipedia convinces China and Iran to unblock it, or it cannot be accessed from there.
Which is why forcing encryption by default now, except for these two countries, is a great strategy - once it is done, it is hard for a third country to decide to ban it. And it goes beyond that: once the government of one of these two countries decides to allow encryption again, and Wikipedia disables the exception for that country, the country cannot go back.
This applies not only to Wikipedia, but to the web as a whole: the more sites force encryption (permanent redirect from http: to https: plus strict transport security), the harder it is to ban encryption.
The current NSA revelations are not an issue for this. TLS has what is called cryptographic agility: the algorithms used are negotiated between the endpoints, and can be swapped later for more secure ones. Even if every algorithm used by TLS has been broken, new ones can be introduced, and will be used if both endpoints allow them.
[ link to this | view in chronology ]
Tor ban
[ link to this | view in chronology ]
Re: Tor ban
1. It will reveal to third parties who's editing Wikimedia pages.
2. It will enable copious abuse of Wikimedia.
There is, unfortunately, a persistent mythos that Tor is magic and that it works perfectly and that it's opaque and so on: nothing could be further from the truth. The best outcome would be to take some "lessons learned" from it, throw it away, and start over.
[ link to this | view in chronology ]
Re: Re: Tor ban
What third parties? They'd have to break SSL (or Tor); maybe the NSA could do it, but it's harder than just watching non-Tor SSL traffic. Without Tor even ISPs can tell who's editing.
Even if logins are required?
If Wikimedia wants to promote circumvention tools, which tools should they promote? If such tools are just banned it's not a very strong form of promotion.
[ link to this | view in chronology ]
Re: Re: Re: Tor ban
I suggest doing a web search for "tor nsa" and reading what you find.
Then consider that the NSA is hardly the only intelligence organization on this planet with an interest in doing so.
Consider further that 60% of Tor development is paid for by the USG, which has now been definitively shown to be deliberating introducing weaknesses/backdoors into code. Do you REALLY think that the USG would be giving money to Tor if they couldn't break it?
Of course the problem here is that once entity A can crack Tor, entities B through Z will be aware that it's a solvable problem and may even pick up some hints on how to replicate the work.
Even if logins are required?
Yes. Nothing stops an abuser from creating a large number of logins (either manually or via automation) -- any measure that would attempt to do so would also block the legitimate creation of a single login by a non-abuser.
[...] which tools should they promote?
Usenet. With encryption, of course. It's incredibly hard to block WHEN DEPLOYED PROPERLY and because it's been around for a very long time, rather sophisticated anti-abuse mechanisms have been developed for it. Yes, it's slower: that's a feature, not a bug. Yes, it takes some clue: that's also a feature, not a bug. But given that it can be propagated over network links, over dialup, via USB stick, via CD/DVD, via tape, via just about anything...it's enormously resistant to disruption.
[ link to this | view in chronology ]
Re: Re: Re: Re: Tor ban
Are you serious?
I am puzzled, how one would edit Wikimedia using Usenet?
Why would anybody want to use Usenet and old, weak and totally open to abuse and spying?
[ link to this | view in chronology ]
Re: Re: Tor ban
[ link to this | view in chronology ]
Re: Tor ban
However, there is a way to bypass the block on anonymous proxies and tor exit nodes: the ipblock-exempt permission. There seem to also exist special "closed proxies" which are not blocked and which can be used to edit Wikipedia. See https://en.wikipedia.org/wiki/Wikipedia:IP_block_exemption and https://en.wikipedia.org/wiki/Wikipedia:Advice_to_users_using_Tor for more information.
[ link to this | view in chronology ]
Re: Re: Tor ban
[ link to this | view in chronology ]
Note that the current stable release of Firefox does not support TLS 1.2.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
[ link to this | view in chronology ]