There are three groups to consider, readers, contributors without and
contributors with specific rights that allow them access to data which is
not publicly visible anyway:

For readers: Readers will not have reduced access to knowledge. I think
that runs against our mission. There are a number of possible reactions:
1) nothing, and the readers cannot access this knowledge anymore
2) readers move to alternatives like Baidu Knows
3) an HTTP proxy will be set up by a third party, giving access to readers
without the supervision and guidance of the WMF, and potentially with
technical and even more serious security issues
What is the advantage for readers to not have access to the HTTP version?

For contributors without specific rights:
 1) what they do is publicly visible anyway, and logged. What is in danger
is the connection between them and their login. Would HTTPS help with that?
2) most of these contributors do not touch sensitive issues. Why block them
out? For what advantage?

For contributors with specific rights:
1) HTTPS only. Putting the contributors themselves in risk is bad enough,
but compromising further contributors is not acceptable.
2) How many would be affected by this anyway? I would be pleasantly
surprised if it is more than a handful.

I think this is an important and hard discussion, and I hope for wide
participation. Thank you Erik, for starting it.


2013/8/31 Erik Moeller <>

> Hi folks,
> As many of you know, this week we enabled HTTPS for logged-in users of
> Wikimedia projects. See:
> We have geographically exempted users geo-located to China or Iran
> from this [1], because these countries mostly block HTTPS traffic and
> requiring HTTPS for logged-in users would make it impossible for users
> in these countries to log in.
> Long term, we’d like to increase HTTPS coverage further, initially by
> marking the HTTPS versions of our pages as "canonical", which would
> cause search engines to refer to them instead of the unencrypted
> content. This would make issues with countries that block HTTPS
> traffic even more complex to deal with.
> HTTPS for editors is important because it is otherwise trivial to
> sniff account credentials, especially when users use unencrypted
> connections such as open wireless networks. This could potentially
> enable an attacker to gain access to an account with significant
> privileges, such as checkuser credentials. Beyond that, HTTPS makes it
> harder for attackers (individuals, organizations, governments) to
> monitor user behavior of readers and editors. It’s not perfect by any
> means, but it’s a step towards more privacy and security.
> There are many sites on the web now that use HTTPS for all
> transactions. For example, Twitter and Facebook use HTTPS by default.
> Both sites are also completely blocked in mainland China. [2]
> Disabling HTTPS-by-default in regions where HTTPS is blocked for
> political reasons of course also exposes affected users to monitoring
> and credentials-theft -- which is likely part of the political
> motivation for blocking it in the first place. Therefore, our current
> exemption is an explicit choice to _not_ give users a degree of
> security that we give to everyone else, for the simple reason that
> their government would otherwise completely limit their access.
> If they know how to make HTTPS work in their region, these users will
> still be able to use it by explicitly visiting the HTTPS URLs or use
> an extension such as HTTPSEverywhere to enforce HTTPS usage.
> 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? How do we answer that question?
> We can, of course, ask users in the affected countries. Given that
> this may lead to degradation or loss of access, users are likely to be
> opposed, and indeed, when plans to expand HTTPS usage were announced,
> a group of Chinese Wikipedians published an open letter asking for
> exemptions to be implemented:
> This was a big part of what drove the decision to implement exemptions.
> The bigger consideration here, however, is whether any such
> accommodation achieves positive or negative long term effects. The
> argument against it goes like this: If we accommodate the PRC’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.
> Moreover, Wikimedia is not just any website -- it’s a top 5 web
> property, and the only non-profit organization among the top sites.
> Our actions can have signalling effects on the rest of the web. By
> exempting China and Iran from standard security measures, we are
> treating them as part of the global web community. 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.
> 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.  Another
> way to pose the question is: Would we be implementing these exemptions
> if China had blocked HTTPS traffic well after we switched to HTTPS?
> Moreover, we’re not helpless against censorship. 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.
> So, what to do? My main suggestion is to organize a broad request for
> comments and input on possible paths forward. I think we’re doing the
> right thing by initially implementing these exemptions -- but I do
> think this decision needs to finally rest with the Board of the
> Wikimedia Foundation, based on community input, taking the tradeoffs
> into account.
> My own stance, which I will continue to argue for (and which is my
> view as an individual -- there are many divergent opinions on this
> even inside WMF), is clear: I think we should set a deadline for the
> current approach, and shift to HTTPS for all traffic, for all sites,
> for all users, by default, after that deadline passes. This will force
> us to take the consequences of that shift seriously, and to explore
> alternatives to designing our technical policies around the practices
> of regimes that undermine web security in order to better censor and
> monitor their citizens.
> All best,
> Erik
> [1] For the curious, the list of blacklisted countries is defined in
> the configuration array 'wmgHTTPSBlacklistCountries’ in
> .
> [2] A reasonably up-to-date list is being maintained at
> _______________________________________________
> Wikimedia-l mailing list
> Unsubscribe:,
> <>

Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 |

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikimedia-l mailing list

Reply via email to