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
On 30 April 2013 18:27, Petr Bena benap...@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
On Tue, Apr 30, 2013 at 10:27 AM, Petr Bena benap...@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
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
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
On Tue, 30 Apr 2013 10:27:21 -0700, Petr Bena benap...@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
On Tue, Apr 30, 2013 at 11:14:48AM -0700, Daniel Friesen wrote:
On Tue, 30 Apr 2013 10:27:21 -0700, Petr Bena benap...@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
On Tue, Apr 30, 2013 at 12:00 PM, Faidon Liambotis fai...@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
On Tue, Apr 30, 2013 at 2:02 PM, Petr Bena benap...@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
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
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
On Tue, Apr 30, 2013 at 2:59 PM, Matthew Walker mwal...@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
On Tue, Apr 30, 2013 at 12:59 PM, Matthew Walker mwal...@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
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
On 29 April 2013 09:12, Brion Vibber bvib...@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:
On Mon, Apr 29, 2013 at 9:12 AM, Brion Vibber bvib...@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
On Mon, Apr 29, 2013 at 9:40 AM, Chris Steipp cste...@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
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
On Mon, Apr 29, 2013 at 9:55 AM, Tyler Romeo tylerro...@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
On Mon, Apr 29, 2013 at 12:59 PM, Chris Steipp cste...@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
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
On Mon, Apr 29, 2013 at 9:07 PM, Paul Selitskas p.selits...@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
On Tue, Apr 30, 2013 at 5:55 AM, Tyler Romeo tylerro...@gmail.com wrote:
On Mon, Apr 29, 2013 at 9:07 PM, Paul Selitskas p.selits...@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
23 matches
Mail list logo
