Just curious -- what's the state of forcing HTTPS for all user sessions? It's simple common sense at this point to protect all our users from session hijacking on local networks or MITM attacks.
I see some Gerrit activity on adding "preferences" or special groups for HTTPS, which seems a horrid practice when we could just protect everyone...
-- brion
On 29 April 2013 09:12, Brion Vibber bvibber@wikimedia.org wrote:
Just curious -- what's the state of forcing HTTPS for all user sessions? It's simple common sense at this point to protect all our users from session hijacking on local networks or MITM attacks.
Now a bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=47832 (how did we not have one already?).
I see some Gerrit activity on adding "preferences" or special groups for HTTPS, which seems a horrid practice when we could just protect everyone...
Agreed; this was a nice idea back in the day when SSL was expensive, but now…
J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester
On Mon, Apr 29, 2013 at 9:12 AM, Brion Vibber bvibber@wikimedia.org wrote:
Just curious -- what's the state of forcing HTTPS for all user sessions? It's simple common sense at this point to protect all our users from session hijacking on local networks or MITM attacks.
I see some Gerrit activity on adding "preferences" or special groups for HTTPS, which seems a horrid practice when we could just protect everyone...
A handful of people have made comments that they really want the option to not use HTTPS. And in MediaWiki, some sites may still be concerned about the performance.
So I think the question is in MediaWiki, do we want to support sites that allow users to disable SSL after login (which is the current use of $wgSecureLogin)? If not, we can alter the functionality to make it force all logged in sessions to use SSL. If so, is that something the WMF wants to enable (https://bugzilla.wikimedia.org/show_bug.cgi?id=39380), or do we want another flag ($wgReallySuperSecureLogin) that forces sessions into SSL?
Personally, I think giving users safe defaults, but the option to shoot themselves *often* is the most secure option, because most users will use the secure defaults, and people who want another option will go to great, ugly lengths to circumvent your feature. This is the direction I've been working towards, but if there is strong support for another option, I'm happy to adjust.
On Mon, Apr 29, 2013 at 9:40 AM, Chris Steipp csteipp@wikimedia.org wrote:
Personally, I think giving users safe defaults, but the option to shoot themselves *often* is the most secure option, because most users will use the secure defaults, and people who want another option will go to great, ugly lengths to circumvent your feature. This is the direction I've been working towards, but if there is strong support for another option, I'm happy to adjust.
I think is sane as well. You see similar patterns from products like Gmail, which have a preference to not use HTTPS all the time.
In the meantime, the new login form from our team detects whether the user is on the HTTPS connection, and embeds a link at the top of the form if you're not. Hopefully this will encourage more people to use it.
Steven
Some relevant info:
Here's the Gerrit change implementing the user preference - https://gerrit.wikimedia.org/r/47089
Also, $wgSecureLogin was deployed once to WMF wikis, but apparently a bug occurred that was not present on my test environment. Once we figure out what the source of that issue is, at the very least we can take the first step and have secure login.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Mon, Apr 29, 2013 at 9:55 AM, Tyler Romeo tylerromeo@gmail.com wrote:
Some relevant info:
Here's the Gerrit change implementing the user preference - https://gerrit.wikimedia.org/r/47089
Also, $wgSecureLogin was deployed once to WMF wikis, but apparently a bug occurred that was not present on my test environment. Once we figure out what the source of that issue is, at the very least we can take the first step and have secure login.
Using $wgSecureLogin with CentralAuth, if a global account logged in and unchecked the box to continue using SSL, then SUL didn't correctly log them in. This has been fixed in some of the updates to SUL that we're working on right now (https://www.mediawiki.org/wiki/Auth_systems/SUL2).
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 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, Apr 29, 2013 at 12:59 PM, Chris Steipp csteipp@wikimedia.orgwrote:
Using $wgSecureLogin with CentralAuth, if a global account logged in and unchecked the box to continue using SSL, then SUL didn't correctly log them in. This has been fixed in some of the updates to SUL that we're working on right now (https://www.mediawiki.org/wiki/Auth_systems/SUL2).
Aha. I figured it had something to do with CentralAuth or another extension.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
There are some situations when HTTPS won't work (for example, blocked by provider or government). How does one disable HTTPS without actually accessing a HTTPS version if the user is redirected from HTTP automatically?
HTTPS was once blocked in Belarus, thus disabling access to above mentioned GMail, Facebook, Twitter and so on. There should be always an option (like ?noSecure=1).
On Mon, Apr 29, 2013 at 8:03 PM, Tyler Romeo tylerromeo@gmail.com wrote:
On Mon, Apr 29, 2013 at 12:59 PM, Chris Steipp csteipp@wikimedia.orgwrote:
Using $wgSecureLogin with CentralAuth, if a global account logged in and unchecked the box to continue using SSL, then SUL didn't correctly log them in. This has been fixed in some of the updates to SUL that we're working on right now (https://www.mediawiki.org/wiki/Auth_systems/SUL2).
Aha. I figured it had something to do with CentralAuth or another extension.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 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, Apr 29, 2013 at 9:07 PM, Paul Selitskas p.selitskas@gmail.comwrote:
There are some situations when HTTPS won't work (for example, blocked by provider or government). How does one disable HTTPS without actually accessing a HTTPS version if the user is redirected from HTTP automatically?
HTTPS was once blocked in Belarus, thus disabling access to above mentioned GMail, Facebook, Twitter and so on. There should be always an option (like ?noSecure=1).
Well, with $wgSecureLogin the idea is that it is completely disallowed to log in, i.e., enter a password, over an insecure connection.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Tue, Apr 30, 2013 at 5:55 AM, Tyler Romeo tylerromeo@gmail.com wrote:
On Mon, Apr 29, 2013 at 9:07 PM, Paul Selitskas p.selitskas@gmail.comwrote:
There are some situations when HTTPS won't work (for example, blocked by provider or government). How does one disable HTTPS without actually accessing a HTTPS version if the user is redirected from HTTP automatically?
HTTPS was once blocked in Belarus, thus disabling access to above mentioned GMail, Facebook, Twitter and so on. There should be always an option (like ?noSecure=1).
Well, with $wgSecureLogin the idea is that it is completely disallowed to log in, i.e., enter a password, over an insecure connection.
Ah, I missed that moment. Thanks.
-- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects
SSL is requiring more CPU, both on server and client and disable all kinds of cache (such as squid or varnish), and some browsers may have problems with it OR in some countries encryption may be even illegal.
Whatever you are going to do, you should let people turn it off. Wikimedia project itself has horrible security (in this thread I started some time ago - http://www.gossamer-threads.com/lists/wiki/wikitech/277357?do=post_view_thre... I was even told that wikimedia doesn't need good security at all, because user accounts aren't so critical there), forcing SSL will not improve it much
On Tue, Apr 30, 2013 at 6:30 AM, Paul Selitskas p.selitskas@gmail.com wrote:
On Tue, Apr 30, 2013 at 5:55 AM, Tyler Romeo tylerromeo@gmail.com wrote:
On Mon, Apr 29, 2013 at 9:07 PM, Paul Selitskas p.selitskas@gmail.comwrote:
There are some situations when HTTPS won't work (for example, blocked by provider or government). How does one disable HTTPS without actually accessing a HTTPS version if the user is redirected from HTTP automatically?
HTTPS was once blocked in Belarus, thus disabling access to above mentioned GMail, Facebook, Twitter and so on. There should be always an option (like ?noSecure=1).
Well, with $wgSecureLogin the idea is that it is completely disallowed to log in, i.e., enter a password, over an insecure connection.
Ah, I missed that moment. Thanks.
-- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 30 April 2013 18:27, Petr Bena benapetr@gmail.com wrote:
SSL is requiring more CPU, both on server and client and disable all kinds of cache (such as squid or varnish), and some browsers may have problems with it OR in some countries encryption may be even illegal.
Whatever you are going to do, you should let people turn it off. Wikimedia project itself has horrible security (in this thread I started some time ago -
http://www.gossamer-threads.com/lists/wiki/wikitech/277357?do=post_view_thre... I was even told that wikimedia doesn't need good security at all, because user accounts aren't so critical there), forcing SSL will not improve it much
I think you need to check those facts. How many years do you have to go back before the extra CPU needed for a client to decrypt an SSL connection becomes noticeable on a client? Or how many browser versions before support becomes imperfect? SSL support was introduced in Internet Explorer version *Two*, in 1995.
SSL is about much more than just preventing account hijacking. It hides details of what you're doing and what pages you're reading from people who have no right or need to know. In some jurisdictions, the correlation between the publicly-available content of a comment or edit, and the snoopable identity of the person who made it, can be damning. The more routine and commonplace SSL connections are, the safer the people who are protected by it will be.
--HM
On Tue, Apr 30, 2013 at 10:27 AM, Petr Bena benapetr@gmail.com wrote:
SSL is requiring more CPU,
Not really.
"In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that."
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
Luis
both on server and client and disable all kinds of cache (such as squid or varnish), and some browsers may have problems with it OR in some countries encryption may be even illegal.
Whatever you are going to do, you should let people turn it off. Wikimedia project itself has horrible security (in this thread I started some time ago - http://www.gossamer-threads.com/lists/wiki/wikitech/277357?do=post_view_thre... I was even told that wikimedia doesn't need good security at all, because user accounts aren't so critical there), forcing SSL will not improve it much
On Tue, Apr 30, 2013 at 6:30 AM, Paul Selitskas p.selitskas@gmail.com wrote:
On Tue, Apr 30, 2013 at 5:55 AM, Tyler Romeo tylerromeo@gmail.com wrote:
On Mon, Apr 29, 2013 at 9:07 PM, Paul Selitskas p.selitskas@gmail.comwrote:
There are some situations when HTTPS won't work (for example, blocked by provider or government). How does one disable HTTPS without actually accessing a HTTPS version if the user is redirected from HTTP automatically?
HTTPS was once blocked in Belarus, thus disabling access to above mentioned GMail, Facebook, Twitter and so on. There should be always an option (like ?noSecure=1).
Well, with $wgSecureLogin the idea is that it is completely disallowed to log in, i.e., enter a password, over an insecure connection.
Ah, I missed that moment. Thanks.
-- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Luis Villa Deputy General Counsel Wikimedia Foundation 415.839.6885 ext. 6810
NOTICE: This message may be confidential or legally privileged. If you have received it by accident, please delete it and let us know about the mistake. As an attorney for the Wikimedia Foundation, for legal/ethical reasons I cannot give legal advice to, or serve as a lawyer for, community members, volunteers, or staff members in their personal capacity.
Ok, I agree with both of you that ssl is probably no deal for current machines and browsers. But anyway - I am afraid that /forcing/ people to use anything is a bad idea. It should be up to them to do what they like on their own risk.
There are countries where encryption is illegal (not really expert on that, but I heard that in Iran and such countries encryption is problem), and these people would not be able to register / edit wikipedia using an account if you made it a requirement.
First step should be just making it a default option for everyone, before actually enforcing anybody.
On Tue, Apr 30, 2013 at 7:52 PM, Luis Villa lvilla@wikimedia.org wrote:
On Tue, Apr 30, 2013 at 10:27 AM, Petr Bena benapetr@gmail.com wrote:
SSL is requiring more CPU,
Not really.
"In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that."
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
Luis
both on server and client and disable all kinds of cache (such as squid or varnish), and some browsers may have problems with it OR in some countries encryption may be even illegal.
Whatever you are going to do, you should let people turn it off. Wikimedia project itself has horrible security (in this thread I started some time ago - http://www.gossamer-threads.com/lists/wiki/wikitech/277357?do=post_view_thre... I was even told that wikimedia doesn't need good security at all, because user accounts aren't so critical there), forcing SSL will not improve it much
On Tue, Apr 30, 2013 at 6:30 AM, Paul Selitskas p.selitskas@gmail.com wrote:
On Tue, Apr 30, 2013 at 5:55 AM, Tyler Romeo tylerromeo@gmail.com wrote:
On Mon, Apr 29, 2013 at 9:07 PM, Paul Selitskas p.selitskas@gmail.comwrote:
There are some situations when HTTPS won't work (for example, blocked by provider or government). How does one disable HTTPS without actually accessing a HTTPS version if the user is redirected from HTTP automatically?
HTTPS was once blocked in Belarus, thus disabling access to above mentioned GMail, Facebook, Twitter and so on. There should be always an option (like ?noSecure=1).
Well, with $wgSecureLogin the idea is that it is completely disallowed to log in, i.e., enter a password, over an insecure connection.
Ah, I missed that moment. Thanks.
-- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Luis Villa Deputy General Counsel Wikimedia Foundation 415.839.6885 ext. 6810
NOTICE: This message may be confidential or legally privileged. If you have received it by accident, please delete it and let us know about the mistake. As an attorney for the Wikimedia Foundation, for legal/ethical reasons I cannot give legal advice to, or serve as a lawyer for, community members, volunteers, or staff members in their personal capacity.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
BTW there are not only common browsers like internet explorer which are getting content from wikipedia, but even less common browsers, such as bots, which are sometimes written in languages, where even if it's not impossible, it at least adds 1 more level of complexity for programmer to make them work.
Some of you who know me, probably know that I am really lazy guy. And I was cursing Ryan Lane for enforcing ssl on wikitech when I had to implement some certificate handling and ssl handshake into wm-bot which is retrieving some data from it using api (reorad only - wm-bot doesn't even have mediawiki user account). It took me like 20 minutes to implement it and that was really horrid :D Think of all these poor programmers, who wrote their wikimedia bot in assembler or brainfuck... try to implement ssl in that first :P
On Tue, Apr 30, 2013 at 8:02 PM, Petr Bena benapetr@gmail.com wrote:
Ok, I agree with both of you that ssl is probably no deal for current machines and browsers. But anyway - I am afraid that /forcing/ people to use anything is a bad idea. It should be up to them to do what they like on their own risk.
There are countries where encryption is illegal (not really expert on that, but I heard that in Iran and such countries encryption is problem), and these people would not be able to register / edit wikipedia using an account if you made it a requirement.
First step should be just making it a default option for everyone, before actually enforcing anybody.
On Tue, Apr 30, 2013 at 7:52 PM, Luis Villa lvilla@wikimedia.org wrote:
On Tue, Apr 30, 2013 at 10:27 AM, Petr Bena benapetr@gmail.com wrote:
SSL is requiring more CPU,
Not really.
"In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that."
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
Luis
both on server and client and disable all kinds of cache (such as squid or varnish), and some browsers may have problems with it OR in some countries encryption may be even illegal.
Whatever you are going to do, you should let people turn it off. Wikimedia project itself has horrible security (in this thread I started some time ago - http://www.gossamer-threads.com/lists/wiki/wikitech/277357?do=post_view_thre... I was even told that wikimedia doesn't need good security at all, because user accounts aren't so critical there), forcing SSL will not improve it much
On Tue, Apr 30, 2013 at 6:30 AM, Paul Selitskas p.selitskas@gmail.com wrote:
On Tue, Apr 30, 2013 at 5:55 AM, Tyler Romeo tylerromeo@gmail.com wrote:
On Mon, Apr 29, 2013 at 9:07 PM, Paul Selitskas p.selitskas@gmail.comwrote:
There are some situations when HTTPS won't work (for example, blocked by provider or government). How does one disable HTTPS without actually accessing a HTTPS version if the user is redirected from HTTP automatically?
HTTPS was once blocked in Belarus, thus disabling access to above mentioned GMail, Facebook, Twitter and so on. There should be always an option (like ?noSecure=1).
Well, with $wgSecureLogin the idea is that it is completely disallowed to log in, i.e., enter a password, over an insecure connection.
Ah, I missed that moment. Thanks.
-- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Luis Villa Deputy General Counsel Wikimedia Foundation 415.839.6885 ext. 6810
NOTICE: This message may be confidential or legally privileged. If you have received it by accident, please delete it and let us know about the mistake. As an attorney for the Wikimedia Foundation, for legal/ethical reasons I cannot give legal advice to, or serve as a lawyer for, community members, volunteers, or staff members in their personal capacity.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Apr 30, 2013 at 2:02 PM, Petr Bena benapetr@gmail.com wrote:
But anyway - I am afraid that /forcing/ people to use anything is a bad idea.
^this. Yes, using HTTPS everywhere is more secure and is probably what WMF will move toward. But no reason has yet to be provided why we should force all wikis everywhere to be all or none, especially when the difference between forcing everybody and giving the option is trivial (to adjust my patch to make it a forcing patch is literally a few lines of code).
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Tue, 30 Apr 2013 10:27:21 -0700, Petr Bena benapetr@gmail.com wrote:
SSL is requiring more CPU, both on server and client and disable all kinds of cache (such as squid or varnish), and some browsers may have problems with it OR in some countries encryption may be even illegal.
SSL does not disable caches. SSL is terminated at the cluster, Squid/Varnish are in on the raw HTTP and serve out HTTP EXACTLY the same way they serve out normal HTTP requests (they even use the exact same cache thanks to our protocol relative urls).
And aside from a few special edge cases, browser caches also work perfectly fine over https as well.
On Tue, Apr 30, 2013 at 11:14:48AM -0700, Daniel Friesen wrote:
On Tue, 30 Apr 2013 10:27:21 -0700, Petr Bena benapetr@gmail.com wrote:
SSL is requiring more CPU, both on server and client and disable all kinds of cache (such as squid or varnish), and some browsers may have problems with it OR in some countries encryption may be even illegal.
SSL does not disable caches. SSL is terminated at the cluster, Squid/Varnish are in on the raw HTTP and serve out HTTP EXACTLY the same way they serve out normal HTTP requests (they even use the exact same cache thanks to our protocol relative urls).
I can verify that the above is correct and Petr is wrong.
However, we terminate SSL before proxying to the normal caching layers, and the infrastructure for this is too small to handle significant portions of the traffic (if it were bigger, it'd be a waste of resources and hence money, considering its current usage). If we were to push normal traffic to them, we'd quickly reach all kinds of limits, incl. CPU and network.
That isn't to say that it's impossible to scale up this infrastructure if needed (or, more likely, adapt the design of the infrastructure to incorporate such an expansion by putting it closer to the caching layers), but it should be considered that it's not just about enabling a MediaWiki config setting to do this but also involves other operations-related engineering work.
That being said, my gut tells me that making all the logins SSL-enabled is not going to make a significant difference compared to current usage, but I don't have any numbers to back this up right now. Maybe Ryan has them.
Cheers, Faidon
On Tue, Apr 30, 2013 at 12:00 PM, Faidon Liambotis faidon@wikimedia.org wrote:
That being said, my gut tells me that making all the logins SSL-enabled is not going to make a significant difference compared to current usage, but I don't have any numbers to back this up right now. Maybe Ryan has them.
We enabled it for about an hour previously (before reverting due to the centralauth bug), and the change was barely noticeable in ganglia.
We enabled it for about an hour previously (before reverting due to the centralauth bug), and the change was barely noticeable in ganglia.
Do we have numbers on what this did to the number of active editors during that time period? Esp. broken down on a per country basis?
I think I want to agree with Petr -- we should not be forcing SSL always; we should be respecting what the user requested. In that way if it ever becomes enforced by a government that SSL is disallowed users may still contribute to the site. (Remember we block things like Tor so they can't even proxy around it.)
Perhaps we should just make it really obvious on the login page (e.g. big button to login via SSL, small button to not do so.)
~Matt Walker Wikimedia Foundation Fundraising Technology Team
On Tue, Apr 30, 2013 at 12:21 PM, Chris Steipp csteipp@wikimedia.orgwrote:
On Tue, Apr 30, 2013 at 12:00 PM, Faidon Liambotis faidon@wikimedia.org wrote:
That being said, my gut tells me that making all the logins SSL-enabled is not going to make a significant difference compared to current usage, but I don't have any numbers to back this up right now. Maybe Ryan has them.
We enabled it for about an hour previously (before reverting due to the centralauth bug), and the change was barely noticeable in ganglia.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Ok, so we should allow non-SSL so that in totalitarian countries with internet snooping, people can contribute to a free encyclopedia that's generally censored by totalitarian countries anyway, in a way that their government can snoop on their connections and see exactly what they're doing and so put them in jail?
Maybe we should be reconsidering how we deal with Tor to allow sane HTTPS-over-Tor connections.
-- brion
On Tue, Apr 30, 2013 at 12:59 PM, Matthew Walker mwalker@wikimedia.orgwrote:
We enabled it for about an hour previously (before reverting due to the centralauth bug), and the change was barely noticeable in ganglia.
Do we have numbers on what this did to the number of active editors during that time period? Esp. broken down on a per country basis?
I think I want to agree with Petr -- we should not be forcing SSL always; we should be respecting what the user requested. In that way if it ever becomes enforced by a government that SSL is disallowed users may still contribute to the site. (Remember we block things like Tor so they can't even proxy around it.)
Perhaps we should just make it really obvious on the login page (e.g. big button to login via SSL, small button to not do so.)
~Matt Walker Wikimedia Foundation Fundraising Technology Team
On Tue, Apr 30, 2013 at 12:21 PM, Chris Steipp <csteipp@wikimedia.org
wrote:
On Tue, Apr 30, 2013 at 12:00 PM, Faidon Liambotis <faidon@wikimedia.org
wrote:
That being said, my gut tells me that making all the logins SSL-enabled is not going to make a significant difference compared to current
usage,
but I don't have any numbers to back this up right now. Maybe Ryan has them.
We enabled it for about an hour previously (before reverting due to the centralauth bug), and the change was barely noticeable in ganglia.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Apr 30, 2013 at 2:59 PM, Matthew Walker mwalker@wikimedia.orgwrote:
We enabled it for about an hour previously (before reverting due to the centralauth bug), and the change was barely noticeable in ganglia.
Do we have numbers on what this did to the number of active editors during that time period? Esp. broken down on a per country basis?
I think I want to agree with Petr -- we should not be forcing SSL always; we should be respecting what the user requested. In that way if it ever becomes enforced by a government that SSL is disallowed users may still contribute to the site. (Remember we block things like Tor so they can't even proxy around it.)
Perhaps we should just make it really obvious on the login page (e.g. big button to login via SSL, small button to not do so.)
I know it's heretical to base what we do on more popular sites, especially the great evil that is facebook, but let's assume they know what they are doing. Visit facebook. Looks to me like it redirects to https even if you specifically ask for http. Nowhere on the page does it give you an option to switch to http. They have twice the number of users as us.
"Do we have numbers?" seems to be the death call of discussions on our lists lately. We have examples we can look at to know what we're doing is sensible.
- Ryan
On Tue, Apr 30, 2013 at 12:59 PM, Matthew Walker mwalker@wikimedia.org wrote:
We enabled it for about an hour previously (before reverting due to the centralauth bug), and the change was barely noticeable in ganglia.
Do we have numbers on what this did to the number of active editors during that time period? Esp. broken down on a per country basis?
I think I want to agree with Petr -- we should not be forcing SSL always; we should be respecting what the user requested. In that way if it ever becomes enforced by a government that SSL is disallowed users may still contribute to the site. (Remember we block things like Tor so they can't even proxy around it.)
I don't want to drag this thread into politics, but the comparison with blocking Tor is really not appropriate. Tor is blocked because it would disrupt the work of the editing community, not to satisfy the requirements of governments. And it would seem extremely weird to let the current policies of the Iranian regime alongside a past measure of the Belarusian one determine the default setup of Wikimedia sites.
Perhaps we should just make it really obvious on the login page (e.g. big button to login via SSL, small button to not do so.)
~Matt Walker Wikimedia Foundation Fundraising Technology Team
On Tue, Apr 30, 2013 at 12:21 PM, Chris Steipp csteipp@wikimedia.orgwrote:
On Tue, Apr 30, 2013 at 12:00 PM, Faidon Liambotis faidon@wikimedia.org wrote:
That being said, my gut tells me that making all the logins SSL-enabled is not going to make a significant difference compared to current usage, but I don't have any numbers to back this up right now. Maybe Ryan has them.
We enabled it for about an hour previously (before reverting due to the centralauth bug), and the change was barely noticeable in ganglia.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org