Hi all,
With all the talk about turning on $wgSecureLogin for WMF sites, there has been a lot of misconceptions about how the option works, and difference of opinions about how they should work in the future.
I started: https://www.mediawiki.org/wiki/Requests_for_comment/Login_security
It would be great to get feedback on the "Longer Term Questions" section. Also, if anyone isn't entirely clear about how the preferences work, hopefully this will provide some clarification.
- Should MediaWiki support allowing some users to use http for their
login, while most users use https? If yes, what are reasonable criteria for determining who can use http (e.g., user groups, GeoIP, or some other criteria)?
I don't have an answer for this, but if it is done it should not be in core, which seems to be the current approach anyway (since the current patch just adds a CanUseHTTPS hook).
- Should MediaWiki support logged in users using HTTP, when HTTPS is
available to them but they don't want to use it (typically for performance reasons-- low end devices, lack of caching, etc)?
I think so. I mean the difficulty of allowing a user to go back to HTTP is not that difficult.
- Should MediaWiki support requiring HTTPS for users with advanced
privileges?
You mean like my $wgSecureGroups approach? Because if people actually still want that I can attempt to revive that part of my patch. I think it'd be of especial interest to require HTTPS for checkusers and oversight people, due to the legal problems associated with breaches to those accounts.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Fri, Aug 23, 2013 at 1:46 PM, Chris Steipp csteipp@wikimedia.org wrote:
Hi all,
With all the talk about turning on $wgSecureLogin for WMF sites, there has been a lot of misconceptions about how the option works, and difference of opinions about how they should work in the future.
I started: https://www.mediawiki.org/wiki/Requests_for_comment/Login_security
It would be great to get feedback on the "Longer Term Questions" section. Also, if anyone isn't entirely clear about how the preferences work, hopefully this will provide some clarification. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 08/23/2013 02:36 PM, Tyler Romeo wrote:
You mean like my $wgSecureGroups approach? Because if people actually still want that I can attempt to revive that part of my patch. I think it'd be of especial interest to require HTTPS for checkusers and oversight people, due to the legal problems associated with breaches to those accounts.
+1
-- Marc
On 23 August 2013 16:25, Marc A. Pelletier marc@uberbox.org wrote:
On 08/23/2013 02:36 PM, Tyler Romeo wrote:
You mean like my $wgSecureGroups approach? Because if people actually
still
want that I can attempt to revive that part of my patch. I think it'd be
of
especial interest to require HTTPS for checkusers and oversight people,
due
to the legal problems associated with breaches to those accounts.
+1
I also see some value to this, and I speak as a member of both those groups. I'd like to see what can be developed, however, to support Checkusers/Oversighters/Stewards who have difficulty using HTTPS, and I have already initiated an offline discussion with Chris and others at the WMF about this.
Risker/Anne
On 08/23/2013 04:35 PM, Risker wrote:
I'd like to see what can be developed, however, to support Checkusers/Oversighters/Stewards who have difficulty using HTTPS
Pretty much by definition the accounts holding those bits are the one we /least/ want to have their password snooped, and the ones most likely to be targeted by malicious eavesdroppers. If we could only support some accounts to use HTTPS, those are the ones we would need to force.
Yes, it does mean that there could not be checkusers in mainland China, for instance as long as they are unable to log in through HTTPS. That would be a /good/ thing.
-- Marc
On 23 August 2013 17:10, Marc A. Pelletier marc@uberbox.org wrote:
On 08/23/2013 04:35 PM, Risker wrote:
I'd like to see what can be developed, however, to support Checkusers/Oversighters/Stewards who have difficulty using HTTPS
Pretty much by definition the accounts holding those bits are the one we /least/ want to have their password snooped, and the ones most likely to be targeted by malicious eavesdroppers. If we could only support some accounts to use HTTPS, those are the ones we would need to force.
Yes, it does mean that there could not be checkusers in mainland China, for instance as long as they are unable to log in through HTTPS. That would be a /good/ thing.
As I said, Marc, there's already an offline discussion happening looking for ways to effectively manage this without outright banning editors from those geographical regions from serving Wikimedia communities. A decision to prevent users from certain countries or with certain technical challenges from holding these permissions is as much a policy issue as it is a security issue (it's also a cross-wiki one), so that aspect needs to be considered from a broad community perspective.
If a technical solution can be found that facilitates affected users being able to securely use the tools, then the policy discussion would focus on whether we require those editors to use the technical solution, instead of recommending outright bans to granting advanced permissions to those affected by HTTPS issues. Solutions are already being considered and examined for this; granted, the discussion is occurring off-wiki so you wouldn't have been aware.
Risker/Anne
On Fri, Aug 23, 2013 at 5:33 PM, Risker risker.wp@gmail.com wrote:
As I said, Marc, there's already an offline discussion happening looking for ways to effectively manage this without outright banning editors from those geographical regions from serving Wikimedia communities. A decision to prevent users from certain countries or with certain technical challenges from holding these permissions is as much a policy issue as it is a security issue (it's also a cross-wiki one), so that aspect needs to be considered from a broad community perspective.
It's statements like these that make me question whether the WMF actually cares about its users' privacy in the first place. There's some big talk on this list about "subverting the NSA" and making sure that users are secure within their accounts when using Wikipedia. But if you're not willing to actually do something about privacy, then it's just talk.
It is completely unacceptable for checkusers in China to be logging in over an insecure connection. The Chinese government directly monitors these connections and can easily harvest these passwords en masse. I truly sympathize with Chinese Wikipedians who aspire to hold checkuser positions, but putting at risk the IP address information of every user on Wikipedia just for the sake of one person who wants to volunteer in a certain capacity is completely unacceptable.
If a technical solution can be found that facilitates affected users being
able to securely use the tools, then the policy discussion would focus on whether we require those editors to use the technical solution, instead of recommending outright bans to granting advanced permissions to those affected by HTTPS issues. Solutions are already being considered and examined for this; granted, the discussion is occurring off-wiki so you wouldn't have been aware.
There is no technical solution, as has been discussed previously. The China firewall blocks all HTTPS connections. There is no legal method of getting around this. The only solution that would preserve both accessibility and security would be if Wikipedia implemented its own application level TLS protocol, which would be an absurd undertaking, and would probably just result in the Chinese government blocking Wikipedia completely anyway.
You're going to have to choose: risk everybody's privacy or deny checkuser opportunities to people in China.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Fri, Aug 23, 2013 at 3:13 PM, Tyler Romeo tylerromeo@gmail.com wrote:
On Fri, Aug 23, 2013 at 5:33 PM, Risker risker.wp@gmail.com wrote:
As I said, Marc, there's already an offline discussion happening looking for ways to effectively manage this without outright banning editors from those geographical regions from serving Wikimedia communities. A
decision
to prevent users from certain countries or with certain technical challenges from holding these permissions is as much a policy issue as it is a security issue (it's also a cross-wiki one), so that aspect needs to be considered from a broad community perspective.
It's statements like these that make me question whether the WMF actually cares about its users' privacy in the first place. There's some big talk on this list about "subverting the NSA" and making sure that users are secure within their accounts when using Wikipedia. But if you're not willing to actually do something about privacy, then it's just talk.
It is completely unacceptable for checkusers in China to be logging in over an insecure connection. The Chinese government directly monitors these connections and can easily harvest these passwords en masse. I truly sympathize with Chinese Wikipedians who aspire to hold checkuser positions, but putting at risk the IP address information of every user on Wikipedia just for the sake of one person who wants to volunteer in a certain capacity is completely unacceptable.
If a technical solution can be found that facilitates affected users being
able to securely use the tools, then the policy discussion would focus on whether we require those editors to use the technical solution, instead
of
recommending outright bans to granting advanced permissions to those affected by HTTPS issues. Solutions are already being considered and examined for this; granted, the discussion is occurring off-wiki so you wouldn't have been aware.
There is no technical solution, as has been discussed previously. The China firewall blocks all HTTPS connections. There is no legal method of getting around this. The only solution that would preserve both accessibility and security would be if Wikipedia implemented its own application level TLS protocol, which would be an absurd undertaking, and would probably just result in the Chinese government blocking Wikipedia completely anyway.
You're going to have to choose: risk everybody's privacy or deny checkuser opportunities to people in China.
Well, it's also possible that you're just not having clever enough ideas, eh? ;)
- Ryan
On Fri, Aug 23, 2013 at 6:16 PM, Ryan Lane rlane32@gmail.com wrote:
Well, it's also possible that you're just not having clever enough ideas, eh? ;)
True, but to be honest, if we come up with a clever enough idea, from China's perspective that's just us getting around their security, which they wouldn't exactly take kindly towards...
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On 23 August 2013 18:13, Tyler Romeo tylerromeo@gmail.com wrote:
On Fri, Aug 23, 2013 at 5:33 PM, Risker risker.wp@gmail.com wrote:
As I said, Marc, there's already an offline discussion happening looking for ways to effectively manage this without outright banning editors from those geographical regions from serving Wikimedia communities. A
decision
to prevent users from certain countries or with certain technical challenges from holding these permissions is as much a policy issue as it is a security issue (it's also a cross-wiki one), so that aspect needs to be considered from a broad community perspective.
It's statements like these that make me question whether the WMF actually cares about its users' privacy in the first place. There's some big talk on this list about "subverting the NSA" and making sure that users are secure within their accounts when using Wikipedia. But if you're not willing to actually do something about privacy, then it's just talk.
It is completely unacceptable for checkusers in China to be logging in over an insecure connection. The Chinese government directly monitors these connections and can easily harvest these passwords en masse. I truly sympathize with Chinese Wikipedians who aspire to hold checkuser positions, but putting at risk the IP address information of every user on Wikipedia just for the sake of one person who wants to volunteer in a certain capacity is completely unacceptable.
I'm not disagreeing with you about Checkusers (wherever they're from) needing to have secure connections when using the tools. If a community RFC was posted today, I would support that requirement.
If a technical solution can be found that facilitates affected users being
able to securely use the tools, then the policy discussion would focus on whether we require those editors to use the technical solution, instead
of
recommending outright bans to granting advanced permissions to those affected by HTTPS issues. Solutions are already being considered and examined for this; granted, the discussion is occurring off-wiki so you wouldn't have been aware.
There is no technical solution, as has been discussed previously. The China firewall blocks all HTTPS connections. There is no legal method of getting around this. The only solution that would preserve both accessibility and security would be if Wikipedia implemented its own application level TLS protocol, which would be an absurd undertaking, and would probably just result in the Chinese government blocking Wikipedia completely anyway.
You're going to have to choose: risk everybody's privacy or deny checkuser opportunities to people in China.
There are other options. The question is whether or not they can be made to work in the MediaWiki/WMF circumstances. If you looked at the data collected to see where HTTPS attempts were unsuccessful, you'd see that there are editors in a lot of countries with issues (i.e., greater than 5% failure rates), and most of them are technical issues. Suddenly you're not just talking about a few projects, you're talking about dozens who may have difficulty getting CU/OS support internally.
The people in our many overlapping MediaWiki and Wikimedia communities have come up with a lot of very creative solutions to problems that other sites haven't figured out or don't care enough to bother with. I have a lot of faith that some out of the box thinking might very well resolve this specific issue, and possibly open a gateway to solving the security issue for even larger groups.
Risker/Anne
On 23 August 2013 23:31, Risker risker.wp@gmail.com wrote:
There are other options. The question is whether or not they can be made to work in the MediaWiki/WMF circumstances. If you looked at the data collected to see where HTTPS attempts were unsuccessful, you'd see that there are editors in a lot of countries with issues (i.e., greater than 5% failure rates), and most of them are technical issues. Suddenly you're not just talking about a few projects, you're talking about dozens who may have difficulty getting CU/OS support internally.
That doesn't change the security consideration.
The people in our many overlapping MediaWiki and Wikimedia communities have come up with a lot of very creative solutions to problems that other sites haven't figured out or don't care enough to bother with. I have a lot of faith that some out of the box thinking might very well resolve this specific issue, and possibly open a gateway to solving the security issue for even larger groups.
And until then, it actually needs to be HTTPS-only. I'm horrified it isn't already.
- d.
On Fri, Aug 23, 2013 at 6:35 PM, David Gerard dgerard@gmail.com wrote:
And until then, it actually needs to be HTTPS-only. I'm horrified it isn't already.
Also, now would be a good time to mention that it is impossible to force HTTPS login for checkusers due to the current GeoIP solution that was just implemented.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On 23 August 2013 18:35, David Gerard dgerard@gmail.com wrote:
On 23 August 2013 23:31, Risker risker.wp@gmail.com wrote:
There are other options. The question is whether or not they can be made
to
work in the MediaWiki/WMF circumstances. If you looked at the data collected to see where HTTPS attempts were unsuccessful, you'd see that there are editors in a lot of countries with issues (i.e., greater than
5%
failure rates), and most of them are technical issues. Suddenly you're
not
just talking about a few projects, you're talking about dozens who may
have
difficulty getting CU/OS support internally.
That doesn't change the security consideration.
No it doesn't change the security consideration. What changes is the recognition that the problem may actually be bigger than initially thought. Everyone knew about China and Iran. Probably nobody knew about Pakistan, Indonesia, Philippines, India, etc - all of which have multiple language projects. Even just HTTPS logins may be a challenge for some of these countries, and it gives the WMF reason to consider how to better support them just so everyone is protected and isn't left with the choice of editing by IP or not editing at all.
The people in our many overlapping MediaWiki and Wikimedia communities
have
come up with a lot of very creative solutions to problems that other
sites
haven't figured out or don't care enough to bother with. I have a lot of faith that some out of the box thinking might very well resolve this specific issue, and possibly open a gateway to solving the security issue for even larger groups.
And until then, it actually needs to be HTTPS-only. I'm horrified it isn't already.
Well, I'm not terribly technical, but I don't think there's ever been consideration of linking login requirements to user permissions. Perhaps that needs to change. I'm concerned too.
Risker/Anne
On Fri, Aug 23, 2013 at 6:43 PM, Risker risker.wp@gmail.com wrote:
Well, I'm not terribly technical, but I don't think there's ever been consideration of linking login requirements to user permissions. Perhaps that needs to change. I'm concerned too.
Unfortunately it's very difficult to do this. On our login forms you enter your username and password simultaneously, which means the server can't possibly know if the user has to be using HTTPS until they've already submitted their password, thus defeating the purpose. That's why $wgSecureLogin is made to *always* put logins over HTTPS, no matter what, and then direct the user to the appropriate protocol afterwards.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
Le Sat, 24 Aug 2013 00:45:05 +0200, Tyler Romeo tylerromeo@gmail.com a écrit:
Unfortunately it's very difficult to do this. On our login forms you enter your username and password simultaneously, which means the server can't possibly know if the user has to be using HTTPS until they've already submitted their password, thus defeating the purpose. That's why $wgSecureLogin is made to *always* put logins over HTTPS, no matter what, and then direct the user to the appropriate protocol afterwards.
An other solution is the use of one-time passwords [1] for high-security or https-unfriendly users (e.g. logging in) or actions (e.g. checkuser action). Such one-time passwords can be generated entirely on the client side (e.g. a program) or on an external device (e.g. SecurID [2]). This transfers the problem "unsecure password" to a problem "protection of the password generator" (e.g. with an offline password) and introduces the key distribution problem (e.g. the physical device).
If used on HTTP the server response must be encrypted and processed by the client with JavaScript; there exists such JavaScript cryptographic libraries [3][4] (I didn’t test them).
Le Sat, 24 Aug 2013 00:13:03 +0200, Tyler Romeo tylerromeo@gmail.com a écrit:
There is no technical solution, as has been discussed previously. The China firewall blocks all HTTPS connections. There is no legal method of getting around this. The only solution that would preserve both accessibility and security would be if Wikipedia implemented its own application level TLS protocol, which would be an absurd undertaking, and would probably just result in the Chinese government blocking Wikipedia completely anyway.
Just for the sake of documention there exists a JavaScript TLS library [5] (I didn’t test it). This could also be used for high-security or https-unfriendly users or actions.
Anyway I guess that if any encryption (HTTPS, JavaScript TLS, etc.) is used on the whole encyclopedia the Chinese government will also likely block also the HTTP version because it could no more filter it, just like the HTTPS now.
[1] https://en.wikipedia.org/wiki/One-time_password [2] https://en.wikipedia.org/wiki/SecurID [3] http://code.google.com/p/crypto-js/ [4] http://crypto.stanford.edu/sjcl/ [5] http://digitalbazaar.com/2010/07/20/javascript-tls-1/
~ Seb35
On Sat, Aug 24, 2013 at 12:50 PM, Seb35 seb35wikipedia@gmail.com wrote:
An other solution is the use of one-time passwords [1] for high-security or https-unfriendly users (e.g. logging in) or actions (e.g. checkuser action). Such one-time passwords can be generated entirely on the client side (e.g. a program) or on an external device (e.g. SecurID [2]). This transfers the problem "unsecure password" to a problem "protection of the password generator" (e.g. with an offline password) and introduces the key distribution problem (e.g. the physical device).
Would something like Extension:OATHAuth fit this purpose?
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
Le Sat, 24 Aug 2013 19:05:38 +0200, Tyler Romeo tylerromeo@gmail.com a écrit:
On Sat, Aug 24, 2013 at 12:50 PM, Seb35 seb35wikipedia@gmail.com wrote:
An other solution is the use of one-time passwords [1] for high-security or https-unfriendly users (e.g. logging in) or actions (e.g. checkuser action). Such one-time passwords can be generated entirely on the client side (e.g. a program) or on an external device (e.g. SecurID [2]). This transfers the problem "unsecure password" to a problem "protection of the password generator" (e.g. with an offline password) and introduces the key distribution problem (e.g. the physical device).
Would something like Extension:OATHAuth fit this purpose?
Oh yes, this type of extension would be great for checkusers/oversights; probably the documentation should be improved if deployed on the Wikimedia wikis -- I didn’t know myself how this was functionning exactly when I played with it.
Thanks, ~ Seb35
On Sat, Aug 24, 2013 at 10:05 AM, Tyler Romeo tylerromeo@gmail.com wrote:
On Sat, Aug 24, 2013 at 12:50 PM, Seb35 seb35wikipedia@gmail.com wrote:
An other solution is the use of one-time passwords [1] for high-security or https-unfriendly users (e.g. logging in) or actions (e.g. checkuser action). Such one-time passwords can be generated entirely on the client side (e.g. a program) or on an external device (e.g. SecurID [2]). This transfers the problem "unsecure password" to a problem "protection of the password generator" (e.g. with an offline password) and introduces the
key
distribution problem (e.g. the physical device).
Would something like Extension:OATHAuth fit this purpose?
The OATH protocol, definitely. One piece I wasn't able to get into our Auth rework this summer was having 2-step login, so that we could require OATH for some people, but normal users wouldn't have to. But yeah,
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Aug 26, 2013 at 11:50 AM, Chris Steipp csteipp@wikimedia.orgwrote:
One piece I wasn't able to get into our Auth rework this summer was having 2-step login, so that we could require OATH for some people, but normal users wouldn't have to. But yeah,
Yeah...that's a little bit of my fault. Once the merger between Extension:OATHAuth and Extension:TwoFactorAuthentication is complete, that feature will exist. See bug 53195.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Fri, Aug 23, 2013 at 3:43 PM, Risker risker.wp@gmail.com wrote:
No it doesn't change the security consideration. What changes is the recognition that the problem may actually be bigger than initially thought. Everyone knew about China and Iran. Probably nobody knew about Pakistan, Indonesia, Philippines, India, etc - all of which have multiple language projects. Even just HTTPS logins may be a challenge for some of these countries, and it gives the WMF reason to consider how to better support them just so everyone is protected and isn't left with the choice of editing by IP or not editing at all.
Hi Risker,
We made a mistake in publishing those numbers. We hadn't fully vetted the numbers, and after they went out, we discovered a flaw in our methodology that meant we were likely overcounting (probably drastically) the number of HTTPS failures we would see in practice.
I'm going to quote Tim Starling's internal analysis below. My apologies to Tim to forwarding without permission, though I doubt he would object.
The main point is that we shouldn't draw too many conclusions about the data. It was useful in seeing where we are being blocked (China and Iran), but the numbers <15% probably shouldn't be counted to draw any conclusions about problems in other countries.
Rob
Tim Starling wrote:
The test used upload.wikimedia.org, at a time when the browser would already have a keepalive connection open to port 80 but not port 443. Client-side aborts caused by navigating away from the page are not logged, and so if the HTTP request completes earlier than the HTTPS request, this opens a window for a systemic error in the results. If the user navigates away after the completion of the HTTP request, but before the completion of the HTTPS request, this would be logged as an HTTPS failure.
My theory two days ago was that the size of the window would be the time it took the browser to do the connection setup, or possibly the whole request. But it occurs to me now that the browser may have its maximum number of concurrent connections open when the test starts. So the request might be queued by the browser until a connection slot opens up. That queue wait time might depend on network bandwidth, as well as RTT.
If both the HTTP and the HTTPS tests used a hostname which is unlikely to have a keepalive connection open, and if the order of the two tests was randomized rather than always sending the HTTP request first, then I think you would get closer to accurate results. However, actual performance differences between HTTPS and HTTP would still cause a systemic error.
On 23 August 2013 19:55, Rob Lanphier robla@wikimedia.org wrote:
On Fri, Aug 23, 2013 at 3:43 PM, Risker risker.wp@gmail.com wrote:
No it doesn't change the security consideration. What changes is the recognition that the problem may actually be bigger than initially
thought.
Everyone knew about China and Iran. Probably nobody knew about Pakistan, Indonesia, Philippines, India, etc - all of which have multiple language projects. Even just HTTPS logins may be a challenge for some of these countries, and it gives the WMF reason to consider how to better support them just so everyone is protected and isn't left with the choice of editing by IP or not editing at all.
Hi Risker,
We made a mistake in publishing those numbers. We hadn't fully vetted the numbers, and after they went out, we discovered a flaw in our methodology that meant we were likely overcounting (probably drastically) the number of HTTPS failures we would see in practice.
I'm going to quote Tim Starling's internal analysis below. My apologies to Tim to forwarding without permission, though I doubt he would object.
The main point is that we shouldn't draw too many conclusions about the data. It was useful in seeing where we are being blocked (China and Iran), but the numbers <15% probably shouldn't be counted to draw any conclusions about problems in other countries.
Rob
Thanks for the clarification, Rob.
Risker
Tim Starling wrote:
The test used upload.wikimedia.org, at a time when the browser would already have a keepalive connection open to port 80 but not port 443. Client-side aborts caused by navigating away from the page are not logged, and so if the HTTP request completes earlier than the HTTPS request, this opens a window for a systemic error in the results. If the user navigates away after the completion of the HTTP request, but before the completion of the HTTPS request, this would be logged as an HTTPS failure.
This is simply not true. The request to log the event hits bits.wikimedia.org and is distinct from either request used as part of the test. Navigating away before both requests have completed (or have been forcibly timed-out) prevents the event from being logged at all.
So, some ideas:
As for the idea that we need to fix internet that's so bad it can't handle HTTPS for "technical reasons"; anything that's that broken is pretty hopeless to "fix" from the web server's end. Instead, consider: * provide support to groups working for improving internet access in areas with poor connectivity
And for the "some countries block our HTTPS" issue: * *actually support* use of Tor etc for editing, allowing folks "in the know" to work around the government blocks and use the site over HTTPS * provide support to groups working against government censorship of the internet * sponsor an official hosted-and-run-in-PRC censor-friendly mirror, and devise some way to migrate edits back
This last would probably be controversial, but if we're serious about 'providing access to knowledge' in PRC, I suspect that's our best bet. Good news is, we're an open-source open-content project, and so this service could be launched *by anyone at any time*. Arguably, Baidupedia already beat us to this.
-- brion
On Fri, Aug 23, 2013 at 3:31 PM, Risker risker.wp@gmail.com wrote:
On 23 August 2013 18:13, Tyler Romeo tylerromeo@gmail.com wrote:
On Fri, Aug 23, 2013 at 5:33 PM, Risker risker.wp@gmail.com wrote:
As I said, Marc, there's already an offline discussion happening
looking
for ways to effectively manage this without outright banning editors
from
those geographical regions from serving Wikimedia communities. A
decision
to prevent users from certain countries or with certain technical challenges from holding these permissions is as much a policy issue as
it
is a security issue (it's also a cross-wiki one), so that aspect needs
to
be considered from a broad community perspective.
It's statements like these that make me question whether the WMF actually cares about its users' privacy in the first place. There's some big talk
on
this list about "subverting the NSA" and making sure that users are
secure
within their accounts when using Wikipedia. But if you're not willing to actually do something about privacy, then it's just talk.
It is completely unacceptable for checkusers in China to be logging in
over
an insecure connection. The Chinese government directly monitors these connections and can easily harvest these passwords en masse. I truly sympathize with Chinese Wikipedians who aspire to hold checkuser
positions,
but putting at risk the IP address information of every user on Wikipedia just for the sake of one person who wants to volunteer in a certain capacity is completely unacceptable.
I'm not disagreeing with you about Checkusers (wherever they're from) needing to have secure connections when using the tools. If a community RFC was posted today, I would support that requirement.
If a technical solution can be found that facilitates affected users
being
able to securely use the tools, then the policy discussion would focus
on
whether we require those editors to use the technical solution, instead
of
recommending outright bans to granting advanced permissions to those affected by HTTPS issues. Solutions are already being considered and examined for this; granted, the discussion is occurring off-wiki so you wouldn't have been aware.
There is no technical solution, as has been discussed previously. The
China
firewall blocks all HTTPS connections. There is no legal method of
getting
around this. The only solution that would preserve both accessibility and security would be if Wikipedia implemented its own application level TLS protocol, which would be an absurd undertaking, and would probably just result in the Chinese government blocking Wikipedia completely anyway.
You're going to have to choose: risk everybody's privacy or deny
checkuser
opportunities to people in China.
There are other options. The question is whether or not they can be made to work in the MediaWiki/WMF circumstances. If you looked at the data collected to see where HTTPS attempts were unsuccessful, you'd see that there are editors in a lot of countries with issues (i.e., greater than 5% failure rates), and most of them are technical issues. Suddenly you're not just talking about a few projects, you're talking about dozens who may have difficulty getting CU/OS support internally.
The people in our many overlapping MediaWiki and Wikimedia communities have come up with a lot of very creative solutions to problems that other sites haven't figured out or don't care enough to bother with. I have a lot of faith that some out of the box thinking might very well resolve this specific issue, and possibly open a gateway to solving the security issue for even larger groups.
Risker/Anne _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 23 August 2013 18:42, Brion Vibber bvibber@wikimedia.org wrote:
So, some ideas:
<snip>
And for the "some countries block our HTTPS" issue:
- *actually support* use of Tor etc for editing, allowing folks "in the
know" to work around the government blocks and use the site over HTTPS
<snip>
Just for the record, anyone at administrator level or higher has IPBE built into their tools (I believe on all projects), so they can edit/administer/checkuser/etc using Tor.
But given that over 95% of anything that comes through an unblocked Tor node onto English Wikipedia is either spam or vandalism, I can't support allowing unbridled Tor editing on at least that project.
Risker/Anne
On Fri, Aug 23, 2013 at 3:47 PM, Risker risker.wp@gmail.com wrote:
Just for the record, anyone at administrator level or higher has IPBE built into their tools (I believe on all projects), so they can edit/administer/checkuser/etc using Tor.
But given that over 95% of anything that comes through an unblocked Tor node onto English Wikipedia is either spam or vandalism, I can't support allowing unbridled Tor editing on at least that project.
Well, we don't allow "unbridled" anything; our administrators litter the IP address universe and logged-in users alike with blocks constantly. :)
I would strongly recommend a saner signup/account moderation system for "less trusted" network origins such as Tor nodes, though. The key is that you have to actually allow creating an account from a Tor node in the first place, or you're limited to people who live in "free internet" countries or have the money or clout to go abroad to create their accounts...
-- brion
On Fri, Aug 23, 2013 at 3:51 PM, Brion Vibber bvibber@wikimedia.org wrote:
On Fri, Aug 23, 2013 at 3:47 PM, Risker risker.wp@gmail.com wrote:
Just for the record, anyone at administrator level or higher has IPBE built into their tools (I believe on all projects), so they can edit/administer/checkuser/etc using Tor.
But given that over 95% of anything that comes through an unblocked Tor node onto English Wikipedia is either spam or vandalism, I can't support allowing unbridled Tor editing on at least that project.
Well, we don't allow "unbridled" anything; our administrators litter the IP address universe and logged-in users alike with blocks constantly. :)
I would strongly recommend a saner signup/account moderation system for "less trusted" network origins such as Tor nodes, though. The key is that you have to actually allow creating an account from a Tor node in the first place, or you're limited to people who live in "free internet" countries or have the money or clout to go abroad to create their accounts...
-- brion
Well yes, such a system would be nice to have, but as discussed previously on this list, it's a hard problem to solve ("Can we help Tor users make legitimate edits?", http://www.gossamer-threads.com/lists/wiki/wikitech/323006 ). Basically, the problem is that all the existing proposals would at best provide a substitute for autoblocks, but not for Checkuser.
Also, there is already https://en.wikipedia.org/wiki/Wikipedia:Advice_to_users_using_Tor#Need_an_ac... (although I don't know how frequently/successfully it's being used currently)
On Fri, Aug 23, 2013 at 4:38 PM, Tilman Bayer tbayer@wikimedia.org wrote:
On Fri, Aug 23, 2013 at 3:51 PM, Brion Vibber bvibber@wikimedia.org wrote:
I would strongly recommend a saner signup/account moderation system for "less trusted" network origins such as Tor nodes, though. The key is that you have to actually allow creating an account from a Tor node in the
first
place, or you're limited to people who live in "free internet" countries
or
have the money or clout to go abroad to create their accounts...
Well yes, such a system would be nice to have, but as discussed previously on this list, it's a hard problem to solve ("Can we help Tor users make legitimate edits?", http://www.gossamer-threads.com/lists/wiki/wikitech/323006 ). Basically, the problem is that all the existing proposals would at best provide a substitute for autoblocks, but not for Checkuser.
I would make the argument that Checkuser is a) ineffective and b) dangerous to privacy: it's incapable of actually identifying people in the first place if they make any effort to work around it, and it exposes network locations of people who aren't explicitly hiding to a fairly large group of people.
That we've built a bureaucracy around checking to see what IP addresses people came from and banning them if they appear to be the same as a previously-banned person is pretty freaky at best and at worst **doesn't actually help** against anyone with the slightest incentive to game the system.
I'd recommend some out-of-the-box thinking instead, perhaps: * stop exposing IP addresses of any users at all (whether logged-in or anonymous) * replace "IP editing" with a simple solution for creating a consistent anonymous identity with a minimum of effort (for example, automatically create an ID cookie which links to an anonymous 'account' which you can optionally turn into a registered, named, emailable user account in the future, or discard and replace every time if you're super-anonymous!) * have much, much better inter-user communication and moderation tools that can prioritize attention on activity of new users, low-reputation users, at-risk network origins or user-agents, etc without exposing individual IP addresses to actual users on the site
No, making a good system is not going to be easy. It's going to be hard, and require a lot of thinking. But I really hope we get to it.
Also, there is already
https://en.wikipedia.org/wiki/Wikipedia:Advice_to_users_using_Tor#Need_an_ac... (although I don't know how frequently/successfully it's being used currently)
At best, that's not very user friendly (and the page strongly discourages anybody to use it by reminding that it's only for trusted people under 'exceptional circumstances'). At worst, it exposes your shiny new login over plaintext email, so negative actors can sniff the data and associate your account with your person.
-- brion
Brion wrote
- stop exposing IP addresses of any users at all (whether logged-in or
anonymous) +1
replace "IP editing" with a simple solution for creating a consistent
anonymous identity with a minimum of effort (for example, automatically create an ID cookie which links to an anonymous 'account' which you can optionally turn into a registered, named, emailable user account in the future, or discard and replace every time if you're super-anonymous!)
+1 ==> see how https://duckduckgo.com/settings and https://startpage.com handle "cookies" (pseudo-hash link; "Anonymous Cloud Save"
On Friday, August 23, 2013, Brion Vibber wrote:
On Fri, Aug 23, 2013 at 4:38 PM, Tilman Bayer <tbayer@wikimedia.orgjavascript:;> wrote:
On Fri, Aug 23, 2013 at 3:51 PM, Brion Vibber <bvibber@wikimedia.orgjavascript:;
wrote:
I'd recommend some out-of-the-box thinking instead, perhaps:
- stop exposing IP addresses of any users at all (whether logged-in or
anonymous)
- replace "IP editing" with a simple solution for creating a consistent
anonymous identity with a minimum of effort (for example, automatically create an ID cookie which links to an anonymous 'account' which you can optionally turn into a registered, named, emailable user account in the future, or discard and replace every time if you're super-anonymous!)
- have much, much better inter-user communication and moderation tools that
can prioritize attention on activity of new users, low-reputation users, at-risk network origins or user-agents, etc without exposing individual IP addresses to actual users on the site
No, making a good system is not going to be easy. It's going to be hard, and require a lot of thinking. But I really hope we get to it.
This kind of proto-account for anonymous editors is something we've discussed among a shadowy cabal (i kid) of product managers in the past. I've also heard that the Ombudsmen have suggest similar things as well. I think there's probably pretty wide support for some or all of what you're suggesting Brion, but as you say, it's a ton of work. :-)
My team is strongly considering experiments this year to try and give more anonymous editors incentives to sign up. Some of what you described, particularly giving them a persistent unique identity that makes viewing an IP a progressive disclosure action or otherwise masks it to most users on-wiki, is something we might be able to tackle. This would be a good transition step toward removing use of IPs as public identifiers altogether.
We don't really have the bandwidth to take up actually replacing IPs though. If anyone is interested in working on this during the Dev Days pre-all staff in September, I'll put it in the list of topics and would be game to participate from a product/UX perspective.
As for better communication and moderation tools, I think Maryana and Brandon would agree that if we are going to ever roll out new user-user discussion pages, we are going to have to figure out how IP talk pages fit in to that.
Steven
Also, there is already
https://en.wikipedia.org/wiki/Wikipedia:Advice_to_users_using_Tor#Need_an_ac...
(although I don't know how frequently/successfully it's being used currently)
At best, that's not very user friendly (and the page strongly discourages anybody to use it by reminding that it's only for trusted people under 'exceptional circumstances'). At worst, it exposes your shiny new login over plaintext email, so negative actors can sniff the data and associate your account with your person.
-- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 08/23/2013 05:33 PM, Risker wrote:
there's already an offline discussion happening looking for ways to effectively manage this without outright banning editors from those geographical regions from serving Wikimedia communities
Interesting. Would you care to share with whom that offline discussion is happening? Your email makes it look as though you speak on behalf of the Foundation, which is clearly not the case and - as far as I know - that discussion isn't taking place with the members of the ops team who actually are working on HTTPS.
-- Marc
On 23 August 2013 19:40, Marc A. Pelletier marc@uberbox.org wrote:
On 08/23/2013 07:35 PM, Marc A. Pelletier wrote:
Would you care to share with whom that offline discussion is happening?
... and, more importantly, /why/ is that discussion taking place offline in the first place?
As you and others may realise by now, I'm possibly the least technically knowledgeable person who comments on this list. There's a limit as to how often I feel the need to expose my limited knowledge to the immortal glare of this mailing list. I had some questions which I sent to Chris Stiepp (with whom I have worked in the past) and James Alexander (who is working with Chris on reviewing technical and other processes related to advanced permissions). Seems my thoughts weren't completely stupid, and I've been advised they're being discussed further internally at WMF. I have no reason to doubt that is true, and from the first post in this thread it is clear that Chris is actively involved in the entire HTTPS/ secure login action plan.
It's a big Engineering Department, so I wouldn't expect that everyone knows what everyone else is doing all the time; nor would I expect that every discussion about security issues and solutions would necessarily take place on this mailing list, or even on a public mailing list.
Risker
On Aug 23, 2013 7:46 PM, "Chris Steipp" csteipp@wikimedia.org wrote:
Hi all,
With all the talk about turning on $wgSecureLogin for WMF sites, there has been a lot of misconceptions about how the option works, and difference of opinions about how they should work in the future.
I started: https://www.mediawiki.org/wiki/Requests_for_comment/Login_security
It would be great to get feedback on the "Longer Term Questions" section. Also, if anyone isn't entirely clear about how the preferences work, hopefully this will provide some clarification.
Requiring https for advanced privileges seems odd. Would that require a second set of credentials over a https only page? If not, the most important consideration is already lost, the credentials. If yes, will people actually use different credentials? Should that be enforced? Is that worth the software complexity? What are the advantages here?
_______________________________________________
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-lht
On 08/23/2013 03:23 PM, Martijn Hoekstra wrote:
Requiring https for advanced privileges seems odd. Would that require a second set of credentials over a https only page?
You're missing the point. People who have (for instance) checkuser or oversight should be simply disallowed from logging in through HTTP at all.
-- Marc
On 23 August 2013 21:28, Marc A. Pelletier marc@uberbox.org wrote:
On 08/23/2013 03:23 PM, Martijn Hoekstra wrote:
Requiring https for advanced privileges seems odd. Would that require a second set of credentials over a https only page?
You're missing the point. People who have (for instance) checkuser or oversight should be simply disallowed from logging in through HTTP at all.
+1
There can't really be a geoIP exemption for this.
- d.
On Fri, Aug 23, 2013 at 10:46 AM, Chris Steipp csteipp@wikimedia.org wrote:
With all the talk about turning on $wgSecureLogin for WMF sites, there has been a lot of misconceptions about how the option works, and difference of opinions about how they should work in the future.
I started: https://www.mediawiki.org/wiki/Requests_for_comment/Login_security
Hi folks,
I filled in a few things for our plan of record, which I'll summarize here:
1. Use of GeoIP to disable HTTPS for the MediaWiki login vs enabling on per wiki basis
Plan of record: Implement GeoIP-based exclusion from the HTTPS default for China and Iran for all wikis, and rely exclusively on GeoIP for exclusion strategy (do not vary based on wiki).
2. Use of a preference vs login form checkbox vs hidden option vs sensible default
Plan of record: Have a preference (default: on) for always using a secure HTTPS connection as a logged user. This preference will be hidden for users in China and Iran, where the behavior will be off.
3. How interactions with login.wikimedia.org will work
Plan of record: we'll keep the status quo for Wednesday, August 28, but this will be the next item we explore.
4. Validation of our HTTPS test methodology
Plan of record: TBD. We haven't had a chance to regroup after figuring out the problems with our initial methodology. We'll do more next week.
Rob
wikitech-l@lists.wikimedia.org