The vast majority of people we serve with Wikipedia and friends don't have accounts and don't log in, and won't be affected in any way by this change.
IMO it's simply unacceptable to leak authentication tokens or account passwords in cleartext; allowing any form of login over HTTP is dinosaur behavior and we'd be crazy to let it continue, whether for "some sites" only or all. We should require HTTPS for all logins on all sites in all languages all the time.
Note that there are plenty of projects producing and maintaining block-circumvention tools, which is what folks who are running afoul of government censorship should be looking into if they need to log into a blocked site, or read blocked pages.
It's a bit out of scope for Wikimedia to fix China's internet, though it'd be nice if we gave some recommendations on tools. Or would that just get us more blocked?
-- brion
On Tue, Aug 20, 2013 at 12:46 PM, George William Herbert < george.herbert@gmail.com> wrote:
On Aug 20, 2013, at 12:03 PM, James Alexander jalexander@wikimedia.org wrote:
Yeah, this seems to contradict what I thought Ryan was saying above and what I was under the impression for. The bad use case for here (as
describe
by Risker for example) is a mainland china user from zhWiki logging in (through http) but now not being able to visit enWiki logged in at all (because it will force them to https and https is blocked).
Posed for sake of argument, assuming this interpretation is correct:
This is unacceptable and a blocking bug to this rollout.
The suggested "just find an excepted project and log in there first" is neither easy nor self-evident enough to be effective for those users. The silent failure mode they will encounter will effectively be a silent site outage for them.
The change must be delayed until people geographically / nationally denied HTTPS can log in again.
Sent from Kangphone _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l