Hello all,
As we outlined in our blog post on the future of HTTPS at the Wikimedia Foundation[0], the plan is to enable HTTPS by default for logged in users on August 21st, this Wednesday.
We are still on target for that rollout date.
As this can have severe consequences for users where HTTPS is blocked by governments/network operators *in addition to* users who connect to Wikimedia sites via high latency connections, we've set up a page on MetaWiki[1] describing what is going on and what it means for users and what they can do to report problems.
Please help watch out for any unintended consequences on August 21st and report any negative issues to us as soon as you can. Bugzilla[2], IRC (#wikimedia-operations), or the (forthcoming) OTRS email are all fine. Also, feel free to email myself or ping me directly on IRC.
Best,
Greg
[0] https://blog.wikimedia.org/2013/08/01/future-https-wikimedia-projects/ [1] https://meta.wikimedia.org/wiki/HTTPS [2] https://bugzilla.wikimedia.org
Quick question: will the patch that was just merged regarding removing the "Stay on HTTPS" checkbox be deployed by then? Or will that be a separate deployment?
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Mon, Aug 19, 2013 at 8:00 PM, Greg Grossmeier greg@wikimedia.org wrote:
Hello all,
As we outlined in our blog post on the future of HTTPS at the Wikimedia Foundation[0], the plan is to enable HTTPS by default for logged in users on August 21st, this Wednesday.
We are still on target for that rollout date.
As this can have severe consequences for users where HTTPS is blocked by governments/network operators *in addition to* users who connect to Wikimedia sites via high latency connections, we've set up a page on MetaWiki[1] describing what is going on and what it means for users and what they can do to report problems.
Please help watch out for any unintended consequences on August 21st and report any negative issues to us as soon as you can. Bugzilla[2], IRC (#wikimedia-operations), or the (forthcoming) OTRS email are all fine. Also, feel free to email myself or ping me directly on IRC.
Best,
Greg
[0] https://blog.wikimedia.org/2013/08/01/future-https-wikimedia-projects/ [1] https://meta.wikimedia.org/wiki/HTTPS [2] https://bugzilla.wikimedia.org
-- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Aug 19, 2013 at 5:32 PM, Tyler Romeo tylerromeo@gmail.com wrote:
Quick question: will the patch that was just merged regarding removing the "Stay on HTTPS" checkbox be deployed by then? Or will that be a separate deployment?
I'm going to work on getting that merged to all relevant branches either tonight or tomorrow, so yes, it will be included.
-Chad
On 19 August 2013 20:35, Chad innocentkiller@gmail.com wrote:
On Mon, Aug 19, 2013 at 5:32 PM, Tyler Romeo tylerromeo@gmail.com wrote:
Quick question: will the patch that was just merged regarding removing
the
"Stay on HTTPS" checkbox be deployed by then? Or will that be a separate deployment?
I'm going to work on getting that merged to all relevant branches either tonight or tomorrow, so yes, it will be included.
Congrats to everyone for getting this going. Is there a workaround available for people behind the Great Firewall to log into projects in languages other than those that are exempted? If so, what is the best way for those individual users to contact Operations or whoever, outside of IRC? I'm fairly certain some of those users may not want to have to publicize their locations. I see mention of an email address: could that be created before the change please?
(I'm guessing it might be some special user permission similar to IP-block exemption, but that may just be my non-technicalese speaking.)
Risker
On Mon, Aug 19, 2013 at 6:03 PM, Risker risker.wp@gmail.com wrote:
On 19 August 2013 20:35, Chad innocentkiller@gmail.com wrote:
On Mon, Aug 19, 2013 at 5:32 PM, Tyler Romeo tylerromeo@gmail.com
wrote:
Quick question: will the patch that was just merged regarding removing
the
"Stay on HTTPS" checkbox be deployed by then? Or will that be a
separate
deployment?
I'm going to work on getting that merged to all relevant branches either tonight or tomorrow, so yes, it will be included.
Congrats to everyone for getting this going. Is there a workaround available for people behind the Great Firewall to log into projects in languages other than those that are exempted? If so, what is the best way for those individual users to contact Operations or whoever, outside of IRC? I'm fairly certain some of those users may not want to have to publicize their locations. I see mention of an email address: could that be created before the change please?
Some projects are being left out of the initial rollout. Users that use those projects as their home wiki will still log-in to HTTP by default and will get a central auth cookie that will work for other projects as well.
Users who are logged in over HTTPS and feel that it is too slow for their area or device can disable HTTPS redirection in their preferences to continue using the site in HTTP mode.
- Ryan
On 19 August 2013 21:09, Ryan Lane rlane32@gmail.com wrote:
On Mon, Aug 19, 2013 at 6:03 PM, Risker risker.wp@gmail.com wrote:
On 19 August 2013 20:35, Chad innocentkiller@gmail.com wrote:
On Mon, Aug 19, 2013 at 5:32 PM, Tyler Romeo tylerromeo@gmail.com
wrote:
Quick question: will the patch that was just merged regarding
removing
the
"Stay on HTTPS" checkbox be deployed by then? Or will that be a
separate
deployment?
I'm going to work on getting that merged to all relevant branches either tonight or tomorrow, so yes, it will be included.
Congrats to everyone for getting this going. Is there a workaround available for people behind the Great Firewall to log into projects in languages other than those that are exempted? If so, what is the best
way
for those individual users to contact Operations or whoever, outside of IRC? I'm fairly certain some of those users may not want to have to publicize their locations. I see mention of an email address: could that be created before the change please?
Some projects are being left out of the initial rollout. Users that use those projects as their home wiki will still log-in to HTTP by default and will get a central auth cookie that will work for other projects as well.
Users who are logged in over HTTPS and feel that it is too slow for their area or device can disable HTTPS redirection in their preferences to continue using the site in HTTP mode.
- Ryan
Okay, perhaps I wasn't clear. What I am referring to are editors from China or Iran who regularly log into projects that will be covered with HTTPS, as we know that HTTPS is (at least sometimes) blocked in those countries. Remember that you're including Commons, Meta, and all English projects - and yes, it is the right thing to do. But we do have a non-negligible number of users (including administrators and stewards) who will need to have a way to access these projects. Do you have a way to exempt them?
Risker
On Mon, Aug 19, 2013 at 6:21 PM, Risker risker.wp@gmail.com wrote:
On 19 August 2013 21:09, Ryan Lane rlane32@gmail.com wrote:
On Mon, Aug 19, 2013 at 6:03 PM, Risker risker.wp@gmail.com wrote:
On 19 August 2013 20:35, Chad innocentkiller@gmail.com wrote:
On Mon, Aug 19, 2013 at 5:32 PM, Tyler Romeo tylerromeo@gmail.com
wrote:
Quick question: will the patch that was just merged regarding
removing
the
"Stay on HTTPS" checkbox be deployed by then? Or will that be a
separate
deployment?
I'm going to work on getting that merged to all relevant branches either tonight or tomorrow, so yes, it will be included.
Congrats to everyone for getting this going. Is there a workaround available for people behind the Great Firewall to log into projects in languages other than those that are exempted? If so, what is the best
way
for those individual users to contact Operations or whoever, outside of IRC? I'm fairly certain some of those users may not want to have to publicize their locations. I see mention of an email address: could
that
be created before the change please?
Some projects are being left out of the initial rollout. Users that use those projects as their home wiki will still log-in to HTTP by default
and
will get a central auth cookie that will work for other projects as well.
Users who are logged in over HTTPS and feel that it is too slow for their area or device can disable HTTPS redirection in their preferences to continue using the site in HTTP mode.
- Ryan
Okay, perhaps I wasn't clear. What I am referring to are editors from China or Iran who regularly log into projects that will be covered with HTTPS, as we know that HTTPS is (at least sometimes) blocked in those countries. Remember that you're including Commons, Meta, and all English projects - and yes, it is the right thing to do. But we do have a non-negligible number of users (including administrators and stewards) who will need to have a way to access these projects. Do you have a way to exempt them?
As I mentioned above. As long as they log-in to their home wiki, they will get a central auth cookie that will keep them logged-in on every other project, which includes commons, meta, etc. If they visit other projects as an anonymous user and try to log in, they'll be redirected to HTTPS, which will fail.
- Ryan
On 19 August 2013 21:31, Ryan Lane rlane32@gmail.com wrote:
On Mon, Aug 19, 2013 at 6:21 PM, Risker risker.wp@gmail.com wrote:
On 19 August 2013 21:09, Ryan Lane rlane32@gmail.com wrote:
On Mon, Aug 19, 2013 at 6:03 PM, Risker risker.wp@gmail.com wrote:
On 19 August 2013 20:35, Chad innocentkiller@gmail.com wrote:
On Mon, Aug 19, 2013 at 5:32 PM, Tyler Romeo <tylerromeo@gmail.com
wrote:
Quick question: will the patch that was just merged regarding
removing
the
"Stay on HTTPS" checkbox be deployed by then? Or will that be a
separate
deployment?
I'm going to work on getting that merged to all relevant branches either tonight or tomorrow, so yes, it will be included.
Congrats to everyone for getting this going. Is there a workaround available for people behind the Great Firewall to log into projects
in
languages other than those that are exempted? If so, what is the
best
way
for those individual users to contact Operations or whoever, outside
of
IRC? I'm fairly certain some of those users may not want to have to publicize their locations. I see mention of an email address: could
that
be created before the change please?
Some projects are being left out of the initial rollout. Users that use those projects as their home wiki will still log-in to HTTP by default
and
will get a central auth cookie that will work for other projects as
well.
Users who are logged in over HTTPS and feel that it is too slow for
their
area or device can disable HTTPS redirection in their preferences to continue using the site in HTTP mode.
- Ryan
Okay, perhaps I wasn't clear. What I am referring to are editors from China or Iran who regularly log into projects that will be covered with HTTPS, as we know that HTTPS is (at least sometimes) blocked in those countries. Remember that you're including Commons, Meta, and all English projects - and yes, it is the right thing to do. But we do have a non-negligible number of users (including administrators and stewards)
who
will need to have a way to access these projects. Do you have a way to exempt them?
As I mentioned above. As long as they log-in to their home wiki, they will get a central auth cookie that will keep them logged-in on every other project, which includes commons, meta, etc. If they visit other projects as an anonymous user and try to log in, they'll be redirected to HTTPS, which will fail.
Well, see. The problem is that the home projects for these editors are not Farsi or Chinese, they are English or German or Commons or Meta (and a few other languages too - and that is just the editors I personally have had contact with). So, is your recommendation to these editors that they log in using the Chinese or Farsi project and then traverse to their home wiki from there?
Risker/Anne
On Mon, Aug 19, 2013 at 6:35 PM, Risker risker.wp@gmail.com wrote:
Well, see. The problem is that the home projects for these editors are not Farsi or Chinese, they are English or German or Commons or Meta (and a few other languages too - and that is just the editors I personally have had contact with). So, is your recommendation to these editors that they log in using the Chinese or Farsi project and then traverse to their home wiki from there?
Correct, that's the best work-around we have, until we can specify the redirects by geography
On 19 August 2013 23:07, Chris Steipp csteipp@wikimedia.org wrote:
On Mon, Aug 19, 2013 at 6:35 PM, Risker risker.wp@gmail.com wrote:
Well, see. The problem is that the home projects for these editors are
not
Farsi or Chinese, they are English or German or Commons or Meta (and a
few
other languages too - and that is just the editors I personally have had contact with). So, is your recommendation to these editors that they log in using the Chinese or Farsi project and then traverse to their home
wiki
from there?
Correct, that's the best work-around we have, until we can specify the redirects by geography
Thanks, Chris. I recommend you add that to the applicable pages. Is it certain that they won't run into a problem when moving from Farsi/Chinese to an HTTPS project? Has this been tested and verified? That is, they won't suddenly find themselves logged out on Commons because they're not using HTTPS?
Risker
Risker wrote:
Okay, perhaps I wasn't clear. What I am referring to are editors from China or Iran who regularly log into projects that will be covered with HTTPS, as we know that HTTPS is (at least sometimes) blocked in those countries. Remember that you're including Commons, Meta, and all English projects - and yes, it is the right thing to do. But we do have a non-negligible number of users (including administrators and stewards) who will need to have a way to access these projects. Do you have a way to exempt them?
My understanding from https://bugzilla.wikimedia.org/29898 is that as of August 20, 2013, there is now a user preference that can toggle HTTP/HTTPS as being required. This is similar to what Gmail and others do (default to HTTPS, allow it to be disabled via a user preference). I'm not totally sure how users will be able to reach their user preferences if they can't log in, though.
MZMcBride
On Mon, Aug 19, 2013 at 9:32 PM, MZMcBride z@mzmcbride.com wrote:
My understanding from https://bugzilla.wikimedia.org/29898 is that as of August 20, 2013, there is now a user preference that can toggle HTTP/HTTPS as being required. This is similar to what Gmail and others do (default to HTTPS, allow it to be disabled via a user preference). I'm not totally sure how users will be able to reach their user preferences if they can't log in, though.
Just to clarify a bit: this is a moot problem, because disabling HTTPS in your user preferences does *not* disable login over HTTPS. Once this is deployed, *all* logins (as in absolutely all of them on whatever projects it is enabled on) will be over HTTPS.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
Tyler Romeo wrote:
On Mon, Aug 19, 2013 at 9:32 PM, MZMcBride z@mzmcbride.com wrote:
My understanding from https://bugzilla.wikimedia.org/29898 is that as of August 20, 2013, there is now a user preference that can toggle HTTP/HTTPS as being required. This is similar to what Gmail and others do (default to HTTPS, allow it to be disabled via a user preference). I'm not totally sure how users will be able to reach their user preferences if they can't log in, though.
Just to clarify a bit: this is a moot problem, because disabling HTTPS in your user preferences does *not* disable login over HTTPS. Once this is deployed, *all* logins (as in absolutely all of them on whatever projects it is enabled on) will be over HTTPS.
I'm not sure that counts as moot. People incapable of using HTTPS will simply be locked out of their accounts indefinitely? How many users will this affect?
I wonder if making it possible to toggle this user preference via e-mail would make sense. Wikimedia wikis are too large and too diverse to not expect that a certain percent of users won't be able to use HTTPS. I'd really like to avoid losing these users. Of course even a "toggle by e-mail" option still wouldn't solve the login issue. Hmmm.
(And if the user preference isn't meant to serve those who can't use HTTPS, who is it intended to serve?)
MZMcBride
On Tue, Aug 20, 2013 at 10:34 AM, MZMcBride z@mzmcbride.com wrote:
I'm not sure that counts as moot. People incapable of using HTTPS will simply be locked out of their accounts indefinitely? How many users will this affect?
I wonder if making it possible to toggle this user preference via e-mail would make sense. Wikimedia wikis are too large and too diverse to not expect that a certain percent of users won't be able to use HTTPS. I'd really like to avoid losing these users. Of course even a "toggle by e-mail" option still wouldn't solve the login issue. Hmmm.
(And if the user preference isn't meant to serve those who can't use HTTPS, who is it intended to serve?)
My point is that it doesn't matter what your user preference is. Whether it's false or true, you still have to log in over HTTPS. In other words, the user preference has no effect on your ability to use the site.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
<quote name="Tyler Romeo" date="2013-08-20" time="10:50:23 -0400">
On Tue, Aug 20, 2013 at 10:34 AM, MZMcBride z@mzmcbride.com wrote:
(And if the user preference isn't meant to serve those who can't use HTTPS, who is it intended to serve?)
My point is that it doesn't matter what your user preference is. Whether it's false or true, you still have to log in over HTTPS. In other words, the user preference has no effect on your ability to use the site.
One group of users that is always being forgotten in this discussion is the group who use Wikipedia over really crappy connections that aren't censoring them. These users will have a hard time using an SSL connection due to the added resources/round trips and have a legitimate non-China/NSA excuse to disable HTTPS after they login (where the added roundtrips are probably worthwhile to keep their username/password safe).
Greg
On Tue, Aug 20, 2013 at 1:12 PM, Greg Grossmeier greg@wikimedia.org wrote:
One group of users that is always being forgotten in this discussion is the group who use Wikipedia over really crappy connections that aren't censoring them. These users will have a hard time using an SSL connection due to the added resources/round trips and have a legitimate non-China/NSA excuse to disable HTTPS after they login (where the added roundtrips are probably worthwhile to keep their username/password safe).
Indeed, and in those case they just leave their HTTPS preference turned off (since the default is off anyway).
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On 20 August 2013 13:12, Greg Grossmeier greg@wikimedia.org wrote:
<quote name="Tyler Romeo" date="2013-08-20" time="10:50:23 -0400"> > On Tue, Aug 20, 2013 at 10:34 AM, MZMcBride <z@mzmcbride.com> wrote: > > > (And if the user preference isn't meant to serve those who can't use > > HTTPS, who is it intended to serve?) > > > > My point is that it doesn't matter what your user preference is. Whether > it's false or true, you still have to log in over HTTPS. In other words, > the user preference has no effect on your ability to use the site.
One group of users that is always being forgotten in this discussion is the group who use Wikipedia over really crappy connections that aren't censoring them. These users will have a hard time using an SSL connection due to the added resources/round trips and have a legitimate non-China/NSA excuse to disable HTTPS after they login (where the added roundtrips are probably worthwhile to keep their username/password safe).
This is correct, but it is still not addressing the question of what happens to users who are completely unable to use HTTPS, and whether or not they will remain logged in if they try to reach another HTTPS-standard project if they start off from Chinese/Farsi projects.
We have project-specific IPBE user-rights for users who are affected by blocked IP addresses (which include but aren't limited to TOR nodes or other blocked proxies). Is it possible to create a similar user-right for "HTTPS not default for login" for this users?
We are talking about a non-negligible number of high-activity users on multiple projects being adversely affected here, including several stewards (cross-project issues), administrators, and high-productivity editors. It is important to find a way that is certain to allow them to log in and to move across multiple projects, and doing so should not be considered an *enhancement*, it should be considered a required feature of the new process. (It may not be a blocker, but I'd hope to see this "fixed" before the end of the month.)
Risker
To clarify, the default value for this HTTPS option is false, meaning you have to explicitly turn it on in order to force HTTPS. In other words, the only functional change being made by this deployment is that *login* on certain projects will be over HTTPS. So for those who do not have HTTPS, they will have to log in through a project that does not have secure login enabled. And once they do log in, they should be fine thereafter.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Tue, Aug 20, 2013 at 1:54 PM, Risker risker.wp@gmail.com wrote:
On 20 August 2013 13:12, Greg Grossmeier greg@wikimedia.org wrote:
<quote name="Tyler Romeo" date="2013-08-20" time="10:50:23 -0400"> > On Tue, Aug 20, 2013 at 10:34 AM, MZMcBride <z@mzmcbride.com> wrote: > > > (And if the user preference isn't meant to serve those who can't use > > HTTPS, who is it intended to serve?) > > > > My point is that it doesn't matter what your user preference is.
Whether
it's false or true, you still have to log in over HTTPS. In other
words,
the user preference has no effect on your ability to use the site.
One group of users that is always being forgotten in this discussion is the group who use Wikipedia over really crappy connections that aren't censoring them. These users will have a hard time using an SSL connection due to the added resources/round trips and have a legitimate non-China/NSA excuse to disable HTTPS after they login (where the added roundtrips are probably worthwhile to keep their username/password safe).
This is correct, but it is still not addressing the question of what happens to users who are completely unable to use HTTPS, and whether or not they will remain logged in if they try to reach another HTTPS-standard project if they start off from Chinese/Farsi projects.
We have project-specific IPBE user-rights for users who are affected by blocked IP addresses (which include but aren't limited to TOR nodes or other blocked proxies). Is it possible to create a similar user-right for "HTTPS not default for login" for this users?
We are talking about a non-negligible number of high-activity users on multiple projects being adversely affected here, including several stewards (cross-project issues), administrators, and high-productivity editors. It is important to find a way that is certain to allow them to log in and to move across multiple projects, and doing so should not be considered an *enhancement*, it should be considered a required feature of the new process. (It may not be a blocker, but I'd hope to see this "fixed" before the end of the month.)
Risker _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Aug 20, 2013 at 10:58 AM, Tyler Romeo tylerromeo@gmail.com wrote:
To clarify, the default value for this HTTPS option is false, meaning you have to explicitly turn it on in order to force HTTPS. In other words, the only functional change being made by this deployment is that *login* on certain projects will be over HTTPS. So for those who do not have HTTPS, they will have to log in through a project that does not have secure login enabled. And once they do log in, they should be fine thereafter.
*-- *
Thanks Tyler,
For clarification purposes I'm putting my understanding of this below, if you or someone else thinks what I'm saying is wrong please correct :):
* The 'force https' preference is an option that is, by default, turned off. * However, for most wikis (not all), force https login is turned on. * Because forced https login is turned on the 'default' for those people will be to move from an https login to an https page because our normal workflow is to always keep you on https if you are already on https (if you are on page X, like a login page, in https then the next page X2 is also in https). * However, if you drop yourself down to http (for example just load the page in http by dropping the s from the address bar and pressing enter) you will not be forced back to https by default for the same reason (our normal workflow) assuming that you have not turned on the https preference. * If you login from an http (non secure) login page such as zhWiki or faWiki you will be able to remain logged in while going to a non secure wiki page (http://en.wikipedia.org ) and not be forced to https (unless you selected that in your preference).
On a side note: I assume the preference is wiki based rather then global?
James
James Alexander Legal and Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur
On Tue, Aug 20, 2013 at 11:07 AM, James Alexander jalexander@wikimedia.orgwrote:
- The 'force https' preference is an option that is, by default, turned
off.
It is turned on by default when $wgSecureLogin is enabled.
- However, for most wikis (not all), force https login is turned on.
That will be the case come tomorrow, yes.
- Because forced https login is turned on the 'default' for those people
will be to move from an https login to an https page because our normal workflow is to always keep you on https if you are already on https (if you are on page X, like a login page, in https then the next page X2 is also in https).
Yes, this is correct.
- However, if you drop yourself down to http (for example just load the
page in http by dropping the s from the address bar and pressing enter) you will not be forced back to https by default for the same reason (our normal workflow) assuming that you have not turned on the https preference.
No, it will put you back on HTTPS as that was the default. You have to turn the preference off.
- If you login from an http (non secure) login page such as zhWiki or
faWiki you will be able to remain logged in while going to a non secure wiki page (http://en.wikipedia.org ) and not be forced to https (unless you selected that in your preference).
Preferences are local, so unless the local preference has been set to false, you would end up on HTTPS.
On a side note: I assume the preference is wiki based rather then global?
Correct.
I'm beginning to think there's a disconnect between what we coded and what people expect. The preference is *on* by default which I think is what's going to cause problems. We can change defaults before tomorrow so I think we should all be clear.
-Chad
On Tue, Aug 20, 2013 at 2:31 PM, Chad innocentkiller@gmail.com wrote:
I'm beginning to think there's a disconnect between what we coded and what people expect. The preference is *on* by default which I think is what's going to cause problems. We can change defaults before tomorrow so I think we should all be clear.
Oh I was not aware of this. I just knew that in MW core itself the default is off. Didn't realize WMF changed it.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Tue, Aug 20, 2013 at 11:36 AM, Tyler Romeo tylerromeo@gmail.com wrote:
On Tue, Aug 20, 2013 at 2:31 PM, Chad innocentkiller@gmail.com wrote:
I'm beginning to think there's a disconnect between what we coded and what people expect. The preference is *on* by default which I think is what's going to cause problems. We can change defaults before tomorrow so I think we should all be clear.
Oh I was not aware of this. I just knew that in MW core itself the default is off. Didn't realize WMF changed it.
Did you read the patch? If $wgSecureLogin is true, prefershttps is also true. This is core.
-Chad
On Tue, Aug 20, 2013 at 2:38 PM, Chad innocentkiller@gmail.com wrote:
Did you read the patch? If $wgSecureLogin is true, prefershttps is also true. This is core.
Oh, I didn't see that Demon had added that in. My bad.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Tue, Aug 20, 2013 at 11:31 AM, Chad innocentkiller@gmail.com wrote:
- If you login from an http (non secure) login page such as zhWiki or
faWiki you will be able to remain logged in while going to a non secure wiki page (http://en.wikipedia.org ) and not be forced to https (unless you selected that in your preference).
Preferences are local, so unless the local preference has been set to false, you would end up on HTTPS.
On a side note: I assume the preference is wiki based rather then global?
Correct.
I'm beginning to think there's a disconnect between what we coded and what people expect. The preference is *on* by default which I think is what's going to cause problems. We can change defaults before tomorrow so I think we should all be clear.
-Chad _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Thanks Chad, that's a lot of help.
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).
I know Ryan used the term 'home wiki' some up in his emails. My interpretation when reading the thread was that it actually meant the wiki you were logging into (which I think is fine) and not the 'home' wiki that is marked in the CentralAuth interface (though I can't figure out where that's actually marked in the database...). If we are using that 'CentralAuth' definition we're going to have a lot of false negatives, a significant amount of people are marked off as their home being enWiki or somewhere else because it was the first place they created an account. We've never really used 'home wiki' to mean anything other then first account.
James
James Alexander Legal and Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur
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
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
On Aug 20, 2013, at 12:57 PM, Brion Vibber bvibber@wikimedia.org wrote:
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.
This is a defensible position.
That is not my point.
It appears that the ops team is about to kick anyone who is unfortunate enough to live in the wrong countries off the projects, without a clue what happened or obvious fallback they will realize. Without publicity or explanation or a HTTP landing pad that explains.
This magnitude of change is political, not purely technical/operational. And demands both notification and a fallback that users will be reasonably able to grasp.
Again, this is still a little fuzzy as to the impact. But it seems like we dump China users of en.wp without warning or immediately obvious workaround. And if that's right, the ops team should not do this. It needs wider warnings and discussion, and is not an ops decision to make.
Sent from Kangphone
Wikipedia was blocked ENTIRELY in China for years; people interested in *reading* as well as contributing used circumvention tools (VPNs etc) to more securely access the site, and just got generic errors if they didn't.
This is an acceptable trade-off which we've allowed the Chinese government to make for us before, and here we're talking about a much smaller effect (on contributors only).
Again, it's not our business to fix China. China has to fix China.
-- brion
On Tue, Aug 20, 2013 at 1:15 PM, George William Herbert < george.herbert@gmail.com> wrote:
On Aug 20, 2013, at 12:57 PM, Brion Vibber bvibber@wikimedia.org wrote:
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.
This is a defensible position.
That is not my point.
It appears that the ops team is about to kick anyone who is unfortunate enough to live in the wrong countries off the projects, without a clue what happened or obvious fallback they will realize. Without publicity or explanation or a HTTP landing pad that explains.
This magnitude of change is political, not purely technical/operational. And demands both notification and a fallback that users will be reasonably able to grasp.
Again, this is still a little fuzzy as to the impact. But it seems like we dump China users of en.wp without warning or immediately obvious workaround. And if that's right, the ops team should not do this. It needs wider warnings and discussion, and is not an ops decision to make.
Sent from Kangphone
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
+foundation-l
On Aug 20, 2013, at 1:20 PM, Brion Vibber bvibber@wikimedia.org wrote:
This is an acceptable trade-off which we've allowed the Chinese government to make for us before, and here we're talking about a much smaller effect (on contributors only).
Again, it's not our business to fix China. China has to fix China.
None of which changes that this is not properly an ops team decision, particularly without notification, warning, workaround explained to people.
If the explanation as to the effects on users in those locales is correct, I would like the Ops team to voluntarily stand back and notify and allow some wider discussion and explanation of the workaround.
If Ops won't do that, then I would like to request that the WMF executive intervene and direct ops to pause and allow wider notification and discussion and explanation of the workaround.
If the WMF executive is not willing I would like to request that the Board review the situation promptly and direct a pause per above.
The outcome is not wrong. THIS IS THE WRONG WAY TO DO IT, without warning and explanation to the community.
Sent from Kangphone
Brion Vibber wrote:
Wikipedia was blocked ENTIRELY in China for years; people interested in *reading* as well as contributing used circumvention tools (VPNs etc) to more securely access the site, and just got generic errors if they didn't.
This is an acceptable trade-off which we've allowed the Chinese government to make for us before, and here we're talking about a much smaller effect (on contributors only).
Again, it's not our business to fix China. China has to fix China.
I completely agree with China fixing China.
But I think the Wikimedia community has to decide whether this trade-off is acceptable. I'm not sure it's a decision that sysadmins and developers can make alone.
From my understanding, zh.wikipedia.org is currently available via HTTP in
China, but not HTTPS. If we change all sites to require HTTPS for logged-in users, we'll certainly increase site security and enhance the user experience for most users, but is that worth losing every zh.wikipedia.org contributor who lives in China? Or do we expect anyone blocked from HTTPS to simply edit without an account?
I think the concern here is that some projects may be decimated (in terms of number of contributors) if HTTPS is forced for all users.
MZMcBride
On Tue, 20 Aug 2013 23:19:22 +0200, MZMcBride z@mzmcbride.com wrote:
If we change all sites to require HTTPS for logged-in users, we'll certainly increase site security and enhance the user experience for most users, but is that worth losing every zh.wikipedia.org contributor who lives in China? Or do we expect anyone blocked from HTTPS to simply edit without an account? I think the concern here is that some projects may be decimated (in terms of number of contributors) if HTTPS is forced for all users.
I think that zh and fa wikis are "exempt". The concernseems to be about contributors from affected countries editing other wikis, such as Commons or Wikidata.
On 20 aug. 2013, at 23:21, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Tue, 20 Aug 2013 23:19:22 +0200, MZMcBride z@mzmcbride.com wrote:
If we change all sites to require HTTPS for logged-in users, we'll certainly increase site security and enhance the user experience for most users, but is that worth losing every zh.wikipedia.org contributor who lives in China? Or do we expect anyone blocked from HTTPS to simply edit without an account? I think the concern here is that some projects may be decimated (in terms of number of contributors) if HTTPS is forced for all users.
I think that zh and fa wikis are "exempt". The concernseems to be about contributors from affected countries editing other wikis, such as Commons or Wikidata.
Can I just say that IF there is still this much discussion and confusion going on even at the level of the developers, that I feel really uncomfortable with this being deployed in the next 24hours.
This all just feels way too rough. And it smells like this is gonna create yet another deploy shitstorm within the communities. I wouldn't like to be in the shoes of the liaisons and ambassadors tomorrow....
DJ
The lack of secure login on WMF wikis is a *major security issue*, and AFAIK is the biggest publicly known security issue in the site. All you need is some random checkuser to be using Wikipedia at a Starbucks, and all of a sudden the privacy policy of every single registered user is violated. There's big talk all around about "evading the NSA" and attempting to protect the privacy of our users, but it is literally impossible to protect users' privacy if we can't even protect their security in the first place. To re-iterate, privacy depends on security, and right now we have neither of them.
Furthermore, secure login is not a new idea. I've been fighting to get this feature enabled since October 2012 when the secure login functionality in MW core was finally fixed. Since then, HTTPS login has been deployed *twice*, but reverted once due to a bug with CentralAuth and once due the design team concerned about the login form. This will be the third attempt at deploying this in the past six months, so I don't know why this discussion had to start right now.
In the end, what we're doing is allowing the Chinese government to manipulate the WMF into degrading the security of its entire userbase, and I don't think that's acceptable. There are 100 times as many active users on enwiki than there are zhwiki, and that's assuming *all* active users on zhwiki also edit enwiki, which is probably not true.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Tue, Aug 20, 2013 at 6:10 PM, Derk-Jan Hartman < d.j.hartman+wmf_ml@gmail.com> wrote:
On 20 aug. 2013, at 23:21, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Tue, 20 Aug 2013 23:19:22 +0200, MZMcBride z@mzmcbride.com wrote:
If we change all sites to require HTTPS for logged-in users, we'll certainly increase site security and enhance the user experience for most users, but is that worth losing every zh.wikipedia.org contributor who lives in China? Or do we expect anyone blocked from HTTPS to simply edit without an account? I think the concern here is that some projects may be decimated (in
terms
of number of contributors) if HTTPS is forced for all users.
I think that zh and fa wikis are "exempt". The concernseems to be about
contributors from affected countries editing other wikis, such as Commons or Wikidata.
Can I just say that IF there is still this much discussion and confusion going on even at the level of the developers, that I feel really uncomfortable with this being deployed in the next 24hours.
This all just feels way too rough. And it smells like this is gonna create yet another deploy shitstorm within the communities. I wouldn't like to be in the shoes of the liaisons and ambassadors tomorrow....
DJ _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Aug 20, 2013 at 3:57 PM, Tyler Romeo tylerromeo@gmail.com wrote:
The lack of secure login on WMF wikis is a *major security issue*, and AFAIK is the biggest publicly known security issue in the site.
Time out...
We do not have a lack of secure login. That was solved a long time ago (many years). I've been using it since about when it was made available first (secure. ...).
This is going from "secure is default and available" to "you cannot access other than secure", unless you know a non-secure exempted wiki you can log in to first.
The people with a firewall (national, corporate, whatever) that blocks HTTPS deserve some warning that something bad is going to happen to them, and that they can mititate that using (X), before it hits.
Again - it is entirely reasonable to shift the stance towards all secure. This will affect some people (I don't know how many). They have not been warned and the workaround is not intuitive.
It's not a normal or reasonable to affect some number of users like that with no warning.
This will be the third attempt at deploying this in the past six months, so
I don't know why this discussion had to start right now.
It was not clear to me that this would have that wide an effect, or I for one would have been saying something months ago. I said exactly how significant I feel it is immediately upon my understanding what the effects will be.
I understand your frustration, but again, the impact on those users is (to me) a blocker bug. It being discovered and made visible this close to deploy time is unfortunate. We should (later) have a conversation about feature descriptions and notifications on the tech list so that discoveries like this aren't last minute.
That does not affect that it should be a blocker bug. Those affected people deserve notification and information on the workarounds.
That does not mean "don't roll this out" but "don't roll it out until it's adequately publicized long enough that nobody is surprised and unable to find the workaround". A week or two weeks of adequate notice should be fine.
-george
On Tue, Aug 20, 2013 at 3:57 PM, Tyler Romeo tylerromeo@gmail.com wrote:
The lack of secure login on WMF wikis is a *major security issue*, and AFAIK is the biggest publicly known security issue in the site.
Indeed. For a Signpost article three years ago, I asked a security researcher (who had co-authored a comparative study of user password handling on 150 websites) about his recommendations for Wikipedia. "Making encrypted transmission of the password the default" was his foremost advice: https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2010-08-02/Techno...
It's excellent news that this issue is finally being resolved, even when there are exceptions and corner cases that need to be addressed.
All you need is some random checkuser to be using Wikipedia at a Starbucks, and all of a sudden the privacy policy of every single registered user is violated. There's big talk all around about "evading the NSA" and attempting to protect the privacy of our users, but it is literally impossible to protect users' privacy if we can't even protect their security in the first place. To re-iterate, privacy depends on security, and right now we have neither of them.
Furthermore, secure login is not a new idea. I've been fighting to get this feature enabled since October 2012 when the secure login functionality in MW core was finally fixed. Since then, HTTPS login has been deployed *twice*, but reverted once due to a bug with CentralAuth and once due the design team concerned about the login form. This will be the third attempt at deploying this in the past six months, so I don't know why this discussion had to start right now.
Okay, so I think there's a fair deal of confusion in a lot of minds as to
how this all is going to work. So let's take a fairly simple and common use case, and work out how we're going to keep these users editing.
The use case I suggest we work out is "English Wikipedia editor who lives in China and wants to edit English Wikipedia using his logged-in account."
So:
- Can this user log in on English Wikipedia? (based on this discussion, no) - Can this user log in on an HTTPS-exempt Wikipedia (based on this discussion, any Chinese or Farsi project, yes) - How will they know that they have to go there? - When they try to go from Chinese Wikipedia to English Wikipedia, what happens? - Do they get an HTTP page, or an HTTPS one? (the latter of which is not accessible) - Do they remain logged in as HTTP? or do they get logged out because the enwp page is HTTPS by default? - If they manage to get as far as English Wikipedia, they can change their user preference to HTTP once that is enabled. Will that also allow them to log in under HTTP so they don't have to go to another project?
Now, I can personally think of a dozen editors to whom this *specific* user case applies, and I know at least another dozen to whom similar user cases apply in relation to other projects - and I really don't know that many people.
I get the importance and value of this action plan. At the same time, there is no benefit to the movement to de facto block existing contributors or ghettoize new ones. Essentially banning Iranian Wikimedians from editing anything but Farsi projects is contrary to the core principles of the Wikimedia movement; deliberately creating a situation where editors need to break the law of their land to participate on Commons or Meta is a significant problem. It's bad enough when that is caused by external forces outside of WMF control; it's disturbing when it is being caused by WMF itself.
Risker
On Tue, Aug 20, 2013 at 12:46 PM, George William Herbert george.herbert@gmail.com wrote:
The change must be delayed until people geographically / nationally denied HTTPS can log in again.
Tim's working on a patch that should make this possible: https://gerrit.wikimedia.org/r/#/c/80166/
The plan of record right now is to not make the switch til we have that merged & tested. We may still be able to make the launch window tomorrow - RobLa will make the final call on that.
Ideally I'd like to see the language-based blacklisting removed if the GeoIP-based solution works.
In general, though, I'd prefer for WMF to move away from what could be characterized as appeasement and towards actively resisting censorship and monitoring. So I'd argue in favor of a deadline for this approach, and alignment of resources and alliances to take active measures against censorship and monitoring.
Erik
On Tue, Aug 20, 2013 at 7:22 PM, Erik Moeller erik@wikimedia.org wrote:
On Tue, Aug 20, 2013 at 12:46 PM, George William Herbert george.herbert@gmail.com wrote:
The change must be delayed until people geographically / nationally
denied HTTPS can log in again.
Tim's working on a patch that should make this possible: https://gerrit.wikimedia.org/r/#/c/80166/
The plan of record right now is to not make the switch til we have that merged & tested. We may still be able to make the launch window tomorrow - RobLa will make the final call on that.
Ideally I'd like to see the language-based blacklisting removed if the GeoIP-based solution works.
Excellent. Thank you.
In general, though, I'd prefer for WMF to move away from what could be characterized as appeasement and towards actively resisting censorship and monitoring. So I'd argue in favor of a deadline for this approach, and alignment of resources and alliances to take active measures against censorship and monitoring.
Yes; in the medium term (past the next few days / week) the direction here is clearly good from a user privacy / censorship and monitoring point of view.
Erik Moeller wrote:
In general, though, I'd prefer for WMF to move away from what could be characterized as appeasement and towards actively resisting censorship and monitoring.
I agree with you and I imagine most developers would agree with you. But the question remains: do most Wikimedians?
I think for most Wikimedians, but particularly for Wikimedians in areas where HTTPS access is restricted, I think there's a general view that having insecure access over HTTP trumps requiring HTTPS and cutting off access altogether. While we hope that this situation is inapplicable to most users, we have to recognize that it's applicable to some percent of our users. It'd be good to get numbers about how many users we're talking about and try to better understand what the Wikimedia community thinks is the best path forward, given the various constraints and consequences.
MZMcBride
On Tue, Aug 20, 2013 at 8:04 PM, MZMcBride z@mzmcbride.com wrote:
Erik Moeller wrote:
In general, though, I'd prefer for WMF to move away from what could be characterized as appeasement and towards actively resisting censorship and monitoring.
I agree with you and I imagine most developers would agree with you. But the question remains: do most Wikimedians?
I think for most Wikimedians, but particularly for Wikimedians in areas where HTTPS access is restricted, I think there's a general view that having insecure access over HTTP trumps requiring HTTPS and cutting off access altogether. While we hope that this situation is inapplicable to most users, we have to recognize that it's applicable to some percent of our users. It'd be good to get numbers about how many users we're talking about and try to better understand what the Wikimedia community thinks is the best path forward, given the various constraints and consequences.
There's not a lot of great options for us to actively bypass censorship methods and anything we do will likely result in us being completely blocked by doing it.
Maybe what we're doing is appeasement, but realistically we have no political power against China. The editors from mainland China had a discussion with some of us at Wikimania and they said that Wikipedia is basically unknown in China because Baidupedia is what shows up in the search results and Wikipedia does not. They actually spend a great deal of time trying to make Wikipedia known to readers in hopes of strengthening the editing community. If we were fully blocked again in China, it wouldn't cause any political fuss.
- Ryan
Ryan Lane wrote:
Maybe what we're doing is appeasement, but realistically we have no political power against China. The editors from mainland China had a discussion with some of us at Wikimania and they said that Wikipedia is basically unknown in China because Baidupedia is what shows up in the search results and Wikipedia does not. They actually spend a great deal of time trying to make Wikipedia known to readers in hopes of strengthening the editing community. If we were fully blocked again in China, it wouldn't cause any political fuss.
Good to know, thanks. So perhaps the impact will be minimal. If stats are possible, they'd be great. I'm not sure how easy it is to measure users unable to use HTTPS.
https://wikimedia.org/wiki/m:Requests_for_comment/Petition_of_HTTPS_default
^ Another data point. The Meta-Wiki version is frozen in time, while people continue to sign on the Chinese Wikipedia.
MZMcBride
<quote name="MZMcBride" date="2013-08-21" time="00:23:04 -0400">
Ryan Lane wrote:
Maybe what we're doing is appeasement, but realistically we have no political power against China. The editors from mainland China had a discussion with some of us at Wikimania and they said that Wikipedia is basically unknown in China because Baidupedia is what shows up in the search results and Wikipedia does not. They actually spend a great deal of time trying to make Wikipedia known to readers in hopes of strengthening the editing community. If we were fully blocked again in China, it wouldn't cause any political fuss.
Good to know, thanks. So perhaps the impact will be minimal. If stats are possible, they'd be great. I'm not sure how easy it is to measure users unable to use HTTPS.
We have some preliminary data that we collected over the weekend on the ability of users to access an https resource (zero byte gif hosted on upload.wikimedia). The numbers still only live in a google doc (sorry!), and they have a lot of caveats.
The caveats (really important to read): https://docs.google.com/a/wikimedia.org/document/d/1Y2vs8lpevv9PtH_dp3P5hZeK... (one really important caveat is we don't even list countries which had less than 100 requests total, as that would be too much noise in the data.)
https://docs.google.com/a/wikimedia.org/spreadsheet/ccc?key=0Ams-fyukCIlMdFR... (Be sure not to miss the tabs at the bottom which show you a map view of the data).
As China and Iran are the outliers there, here's a spreadsheet with them zero'd out so you can more easily see the middle gradients: https://docs.google.com/a/wikimedia.org/spreadsheet/ccc?key=0Agte_lJNpi-OdFJ...
Additionally, to see if any changes have a major effect on the ability of people to log in, we've started parsing out the successful centralauth autentications and will have a nice Ganglia graph tomorrow. We also parsed out some historical data on those going back a week or more to have a better idea of what "normal" is. Our numbers here are "successful logins per hour" which should be a decent metric to watch.
Thanks much to Ori and Dario for working on the HTTPS capability numbers, and Ori and Robla for getting the successful login numbers.
Greg
<quote name="Greg Grossmeier" date="2013-08-20" time="21:43:55 -0700">
The caveats (really important to read): https://docs.google.com/a/wikimedia.org/document/d/1Y2vs8lpevv9PtH_dp3P5hZeK... (one really important caveat is we don't even list countries which had less than 100 requests total, as that would be too much noise in the data.)
I should reiterate: It's hard to draw stark conclusions from this data at this point, but we're using it as a guide along with our knowledge of network reliability in different parts of the world to make decisions about what regions will be exempted.
Greg
On 21 August 2013 00:51, Greg Grossmeier greg@wikimedia.org wrote:
<quote name="Greg Grossmeier" date="2013-08-20" time="21:43:55 -0700"> > > The caveats (really important to read): > https://docs.google.com/a/wikimedia.org/document/d/1Y2vs8lpevv9PtH_dp3P5hZeKuczB4-1xDXOHCaeuhw8/edit > (one really important caveat is we don't even list countries which had > less than 100 requests total, as that would be too much noise in the > data.)
I should reiterate: It's hard to draw stark conclusions from this data at this point, but we're using it as a guide along with our knowledge of network reliability in different parts of the world to make decisions about what regions will be exempted.
Greg
Thank you for sharing this data, Greg. I am surprised to see 5 additional countries with more than 10% failure rates, and another 11 with more than 5%, although these tend to also have higher than average margins of error. It would be interesting to see how the numbers stabilize over time.
Risker
<quote name="Risker" date="2013-08-21" time="01:03:51 -0400">
Thank you for sharing this data, Greg. I am surprised to see 5 additional countries with more than 10% failure rates, and another 11 with more than 5%, although these tend to also have higher than average margins of error. It would be interesting to see how the numbers stabilize over time.
Yes, the stabilizing/longer term data will be really helpful here. We'll keep our eyes on it, in addition to the other feedback channels, and adjust our settings appropriately.
Greg
On Aug 20, 2013, at 9:43 PM, Greg Grossmeier greg@wikimedia.org wrote:
Additionally, to see if any changes have a major effect on the ability of people to log in, we've started parsing out the successful centralauth autentications and will have a nice Ganglia graph tomorrow. We also parsed out some historical data on those going back a week or more to have a better idea of what "normal" is. Our numbers here are "successful logins per hour" which should be a decent metric to watch.
Thanks, Greg.
Is there any chance that monitoring could track success of login if someone is redirected from HTTP to HTTPS? The redirects should be easy to spot.
-george
Sent from Kangphone
<quote name="George William Herbert" date="2013-08-20" time="22:09:41 -0700">
Is there any chance that monitoring could track success of login if someone is redirected from HTTP to HTTPS? The redirects should be easy to spot.
I don't know, honestly. The log we were working from initially doesn't have that data in it (we don't track our users, remember? ;)), but I'll look more closely tomorrow.
Greg
If it was six months ago, I would suggest we hand over a unique random cookie with the redirect and verify on the HTTPS side that the cookie showed up, to make sure that it worked.
And then only keep a success/fail log for IP block, perhaps, no user data. That would seem privacy neutral.
Too late now to do that, though.
Sent from Kangphone
On Aug 20, 2013, at 10:24 PM, Greg Grossmeier greg@wikimedia.org wrote:
<quote name="George William Herbert" date="2013-08-20" time="22:09:41 -0700"> > Is there any chance that monitoring could track success of login if someone is redirected from HTTP to HTTPS? The redirects should be easy to spot.
I don't know, honestly. The log we were working from initially doesn't have that data in it (we don't track our users, remember? ;)), but I'll look more closely tomorrow.
Greg
-- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D | _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 20 August 2013 22:22, Erik Moeller erik@wikimedia.org wrote:
On Tue, Aug 20, 2013 at 12:46 PM, George William Herbert george.herbert@gmail.com wrote:
The change must be delayed until people geographically / nationally
denied HTTPS can log in again.
Tim's working on a patch that should make this possible: https://gerrit.wikimedia.org/r/#/c/80166/
The plan of record right now is to not make the switch til we have that merged & tested. We may still be able to make the launch window tomorrow - RobLa will make the final call on that.
Very good, this is the step that needed to be taken so that users who are unable to use HTTPS can still contribute to our knowledge base - which is the primary focus of the WMF.
Ideally I'd like to see the language-based blacklisting removed if the GeoIP-based solution works.
In general, though, I'd prefer for WMF to move away from what could be characterized as appeasement and towards actively resisting censorship and monitoring. So I'd argue in favor of a deadline for this approach, and alignment of resources and alliances to take active measures against censorship and monitoring.
Perhaps then you might want to re-familiarize yourself with the WMF's policy on political advocacy, particularly the section on "Promotional use of website assets" and "Movement Partnerships" (although the latter is a bit of a stretch).[1] I think that would best describe the proposal here, to politicize the manner in which *registered contributors* are able to contribute to the vast array of WMF projects. I do understand why this is important to a lot of people, and I do get that logging in under HTTPS is more secure than logging in under HTTP. But at the same time, the WMF's primary mission is to "empower and engage people around the world to collect and develop educational content".[2] Wikimedia's values include "encouraging the development of free-content educational resources that may be created, used, and reused by the entire human community. We believe that this mission requires thriving open formats and open standards on the web to allow the creation of content not subject to restrictions on creation, use, and reuse." [3]
Note now none of them say "the WMF technical team can unilaterally take actions that may affect the ability of users to register an account or for registered contributors to participate in the WMF's primary mission." For that, you need to actively persuade the community in general that this is necessary, and possibly even the Board of Trustees.
Risker
[1] https://meta.wikimedia.org/wiki/Legal_and_Community_Advocacy/Foundation_Poli... [2] https://wikimediafoundation.org/wiki/Mission [3] https://wikimediafoundation.org/wiki/Values
On 08/20/2013 11:05 PM, Risker wrote:
Perhaps then you might want to re-familiarize yourself with the WMF's policy on political advocacy
I'm sorry Risker, but you've got this backwards. Making a long-overdue /minimal/ fix to our login process is not political advocacy. Compromising the security and privacy of our editors for the sake of a government's censorship policies, *is*.
The very idea that editors with checkuser or oversight might even be *able* to login in cleartext over an Internet we *know* is monitored by entities that are demonstrably hostile to privacy is worrying enough on its own without introducing additional flaws in the process.
I don't even agree that an exception should be made to allow cleartext logins from regions which are even *more* hostile to privacy than the United States; and I would have advocated that no account with bits should be allowed to do so regardless of location.
Nevertheless, engineering has been bending over backwards to accommodate as many editors with crippled Internet access as is possible; inventing bogeymen and quoting misapplied bits of policy around ("promotional use"? Really?) is an extraordinary show of bad faith.
-- Marc
On 21 August 2013 00:08, Marc A. Pelletier marc@uberbox.org wrote:
On 08/20/2013 11:05 PM, Risker wrote:
Perhaps then you might want to re-familiarize yourself with the WMF's policy on political advocacy
I'm sorry Risker, but you've got this backwards. Making a long-overdue /minimal/ fix to our login process is not political advocacy. Compromising the security and privacy of our editors for the sake of a government's censorship policies, *is*.
The mandatory use of HTTPS outside of a limited number of countries where we know the editors will be blocked is not what I am talking about. I was responding to Erik's political manifesto about censorship. I have no problems with the core concept here.
The very idea that editors with checkuser or oversight might even be *able* to login in cleartext over an Internet we *know* is monitored by entities that are demonstrably hostile to privacy is worrying enough on its own without introducing additional flaws in the process.
I don't even agree that an exception should be made to allow cleartext logins from regions which are even *more* hostile to privacy than the United States; and I would have advocated that no account with bits should be allowed to do so regardless of location.
Well, you're not alone there. But that is an entirely different discussion. You want to take up security of accounts with "bits", Chris Stiepp is thataway.
Nevertheless, engineering has been bending over backwards to accommodate as many editors with crippled Internet access as is possible; inventing bogeymen and quoting misapplied bits of policy around ("promotional use"? Really?) is an extraordinary show of bad faith.
Again, I was not referring to the core concept here. Read Erik's last paragraph again: it is a political manifesto, and something I would not have expected from the #2 of Wikimedia Foundation leadership in the middle of a technical discussion. I don't entirely disagree with him, but it's not in line with the mission and vision of the Foundation itself, which is unsupportive of using technical means to prevent good-faith contributions.
Risker
On Tue, Aug 20, 2013 at 9:20 PM, Risker risker.wp@gmail.com wrote:
The mandatory use of HTTPS outside of a limited number of countries where we know the editors will be blocked is not what I am talking about.
No, but the point is that there's no apolitical choice here. Actively suppressing a standard, long overdue security measure in order to ensure that a country's censorship practices do not interfere with editing and access to Wikipedia is a political choice. Not doing so in full awareness of the consequences is a political choice. We cannot claim ignorance or neutrality either way.
The real question is what political choices serve Wikimedia's mission best in the short and long term, and I agree that that's a discussion that extends beyond the technical dimension, so is somewhat OT here.
Erik
On 21/08/13 12:22, Erik Moeller wrote:
On Tue, Aug 20, 2013 at 12:46 PM, George William Herbert george.herbert@gmail.com wrote:
The change must be delayed until people geographically / nationally denied HTTPS can log in again.
Tim's working on a patch that should make this possible: https://gerrit.wikimedia.org/r/#/c/80166/
The plan of record right now is to not make the switch til we have that merged & tested. We may still be able to make the launch window tomorrow - RobLa will make the final call on that.
I don't think it is a great idea to enable $wgSecureLogin with https://gerrit.wikimedia.org/r/#/c/47089/ unreverted and unfixed. And my own patches probably need more testing.
In general, though, I'd prefer for WMF to move away from what could be characterized as appeasement and towards actively resisting censorship and monitoring. So I'd argue in favor of a deadline for this approach, and alignment of resources and alliances to take active measures against censorship and monitoring.
That's not really what I signed up for. I would like WMF to play an increasing role in the education of the people of the PRC, and I think actively resisting censorship is opposed to that goal. We will be blocked, and thus lose almost all of our PRC traffic.
I support circumvention of China's censorship, and more fundamentally, I want China to be more open and democratic. However, I think that measures to achieve these goals should be done at arm's length from the Foundation.
-- Tim Starling
On Mon, Aug 19, 2013 at 5:35 PM, Chad innocentkiller@gmail.com wrote:
On Mon, Aug 19, 2013 at 5:32 PM, Tyler Romeo tylerromeo@gmail.com wrote:
Quick question: will the patch that was just merged regarding removing the "Stay on HTTPS" checkbox be deployed by then? Or will that be a separate deployment?
I'm going to work on getting that merged to all relevant branches either tonight or tomorrow, so yes, it will be included.
Changes all staged for deployment, will probably merge right before we throw the switch Wednesday.
https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/core+topic:...
-Chad
wikitech-l@lists.wikimedia.org