(+CC: Analytics)
On Wed, Oct 15, 2014 at 8:54 AM, Giuseppe Lavagetto glavagetto@wikimedia.org wrote:
So, the somewhat-anticipated new SSL vulnerability is out, CVE-2014-3566.
To make the long story short:
- SSL v 3.0 operating with CBC-mode chiphers is vulnerable to this
attack and could allow an attacker to get plaintext info on the traffic being exchanged with the server
- It's fairly easy for an attacker to induce a downgrade from more
modern version of TLS to SSL 3.0
There are some patches that would eliminate the downgrading issues *for chrome users only at the moment*, but I'm not that happy with the idea of patching openssl and maintaining the patch.
Another possibility would be to force use of RC4 in SSL 3.0, which as Brandon put it on IRC is almost as using rot13.
So, the easiest (and best) way of getting rid of this vulnerability (and a bunch of others, to be honest) would be to drop SSL 3.0 support. That would mean dropping HTTPS support for IE6 users, which is a decision we can't make lightly, but keeping SSL 3.0 exposes the vast majority of our users to this vulnerability.
What should we do? This is not as serious as heartbleed but shouldn't be taken lightly anyway.
So to sum it up again:
SSL 3.0 is vulnerable/weak, enabling RC4 doesn't help much. Keeping SSL 3.0 enabled with RC4 for clients that only support SSL 3.0 (mostly IE 6 and below it seems) -might- be acceptable, if we could warn those users when they use it, and if we can prevent every other browser from downgrading to it. But that doesn't seem possible at the moment; Google's TLS_FALLBACK_SCSV needs all clients and servers patched, which will obviously take a long while and has maintainability issues. Also depends on whether OpenSSL and/or Debian will incorporate this nonstandard patch... at least this affects a lot of people.
Disabling SSL 3.0 could break SSL completely for something in the order of 1.5% of HTML page requests, according to http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm Perhaps the Analytics team could do some additional, specific investigation on this to aid this decision?
I think if we can't allow secure HTTPS by keeping SSL 3.0 enabled, we should probably disable it even if it breaks a small number of requests. 1.5% doesn't seem insignificant though. Obviously we'd need to communicate that very well, as we don't seem to have good options for doing any sort of fallback to HTTP. I guess it also depends on what the public awareness of this issue will be...
On Wed, Oct 15, 2014 at 11:11 AM, Mark Bergsma mark@wikimedia.org wrote:
I think if we can't allow secure HTTPS by keeping SSL 3.0 enabled, we should probably disable it even if it breaks a small number of requests. 1.5% doesn't seem insignificant though. Obviously we'd need to communicate that very well, as we don't seem to have good options for doing any sort of fallback to HTTP. I guess it also depends on what the public awareness of this issue will be...
I should clarify that the 1.5% figure there is http+https combined (I think) so the actual figures for https will be lower.
In practical terms I think no https would mean not being able to edit as a registered user, anon edit still works over http.
+1 to clearly communicate this, perhaps on the "https entry points" e.g. login button at least while http is still the default.
Le 15/10/2014 12:23, Filippo Giunchedi a écrit : <snip>
I should clarify that the 1.5% figure there is http+https combined (I think) so the actual figures for https will be lower.
In practical terms I think no https would mean not being able to edit as a registered user, anon edit still works over http.
+1 to clearly communicate this, perhaps on the "https entry points" e.g. login button at least while http is still the default.
That would prevents those users from logging in entirely since by default users have the preference 'prefershttps' set.
A workaround would be to hook in CanIPUseHTTPS to look for the user agent and thus indicate that the IP can not use https which would skip the redirect to a HTTPS login page.
On Wed, Oct 15, 2014 at 5:32 AM, Antoine Musso hashar@free.fr wrote:
Le 15/10/2014 12:23, Filippo Giunchedi a écrit :
<snip> > I should clarify that the 1.5% figure there is http+https combined (I > think) so the actual figures for https will be lower. > > In practical terms I think no https would mean not being able to edit as > a registered user, anon edit still works over http. > > +1 to clearly communicate this, perhaps on the "https entry points" e.g. > login button at least while http is still the default.
That would prevents those users from logging in entirely since by default users have the preference 'prefershttps' set.
Worse, we always require https on the form that accepts the user's password. So all logins for IE6+XP users will be broken.
Updating the hook would be possible. Probably better than not turning off ssl3 to the main sites though. What about just running a banner on the site for IE <6 users, telling them that ssl is disabled and soon they won't be able to login at all, we disable ssl3, and we temporarily put the CanIPUseHTTPS hook in to not force IE <6 users to https. After 90 days or so, we pull that part out of the hook, and IE6 users just have to deal with not being able to login?
A workaround would be to hook in CanIPUseHTTPS to look for the user agent and thus indicate that the IP can not use https which would skip the redirect to a HTTPS login page.
-- Antoine "hashar" Musso
Ops mailing list Ops@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ops
On Wed, Oct 15, 2014 at 3:39 PM, Chris Steipp csteipp@wikimedia.org wrote:
On Wed, Oct 15, 2014 at 5:32 AM, Antoine Musso hashar@free.fr wrote:
Le 15/10/2014 12:23, Filippo Giunchedi a écrit :
<snip> > I should clarify that the 1.5% figure there is http+https combined (I > think) so the actual figures for https will be lower. > > In practical terms I think no https would mean not being able to edit as > a registered user, anon edit still works over http. > > +1 to clearly communicate this, perhaps on the "https entry points" e.g. > login button at least while http is still the default.
That would prevents those users from logging in entirely since by default users have the preference 'prefershttps' set.
Worse, we always require https on the form that accepts the user's password. So all logins for IE6+XP users will be broken.
Updating the hook would be possible. Probably better than not turning off ssl3 to the main sites though. What about just running a banner on the site for IE <6 users, telling them that ssl is disabled and soon they won't be able to login at all, we disable ssl3, and we temporarily put the CanIPUseHTTPS hook in to not force IE <6 users to https. After 90 days or so, we pull that part out of the hook, and IE6 users just have to deal with not being able to login?
Given the numbers Christian pointed out, I think the 90 days interval is pretty irrelevant. It is not like those users will rush to upgrade/change to something not being IE6. I'd be delighted if we convinced something like 5% (~200k people if my numbers are right) of those users to do that. That being said, the plan sounds fine to me.
On Wed, Oct 15, 2014 at 2:57 PM, Alexandros Kosiaris akosiaris@wikimedia.org wrote:
On Wed, Oct 15, 2014 at 3:39 PM, Chris Steipp csteipp@wikimedia.org wrote:
Updating the hook would be possible. Probably better than not turning off ssl3 to the main sites though. What about just running a banner on the site for IE <6 users, telling them that ssl is disabled and soon they won't be able to login at all, we disable ssl3, and we temporarily put the CanIPUseHTTPS hook in to not force IE <6 users to https. After 90 days or so, we pull that part out of the hook, and IE6 users just have to deal with not being able to login?
Given the numbers Christian pointed out, I think the 90 days interval is pretty irrelevant. It is not like those users will rush to upgrade/change to something not being IE6. I'd be delighted if we convinced something like 5% (~200k people if my numbers are right) of those users to do that. That being said, the plan sounds fine to me.
How many -logins- are we seeing from non-TLS capable browsers? I'd expect that to be much lower. Likely the majority of IE5/6 users are from very out of date corporate environments, which is probably not a place where most of our users are editing from.
On 10/15/2014 06:06 AM, Mark Bergsma wrote:
On Wed, Oct 15, 2014 at 2:57 PM, Alexandros Kosiaris akosiaris@wikimedia.org wrote:
On Wed, Oct 15, 2014 at 3:39 PM, Chris Steipp csteipp@wikimedia.org wrote:
Updating the hook would be possible. Probably better than not turning off ssl3 to the main sites though. What about just running a banner on the site for IE <6 users, telling them that ssl is disabled and soon they won't be able to login at all, we disable ssl3, and we temporarily put the CanIPUseHTTPS hook in to not force IE <6 users to https. After 90 days or so, we pull that part out of the hook, and IE6 users just have to deal with not being able to login?
Given the numbers Christian pointed out, I think the 90 days interval is pretty irrelevant. It is not like those users will rush to upgrade/change to something not being IE6. I'd be delighted if we convinced something like 5% (~200k people if my numbers are right) of those users to do that. That being said, the plan sounds fine to me.
How many -logins- are we seeing from non-TLS capable browsers? I'd expect that to be much lower. Likely the majority of IE5/6 users are from very out of date corporate environments, which is probably not a place where most of our users are editing from.
This bug is very relevant here:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56575
Summary: In April Oliver found that IE 6 has only 0.00479% of logged-in page views these days.
On Wed, Oct 15, 2014 at 3:25 PM, Gabriel Wicke gwicke@wikimedia.org wrote:
On 10/15/2014 06:06 AM, Mark Bergsma wrote:
How many -logins- are we seeing from non-TLS capable browsers? I'd expect that to be much lower. Likely the majority of IE5/6 users are from very out of date corporate environments, which is probably not a place where most of our users are editing from.
This bug is very relevant here:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56575
Summary: In April Oliver found that IE 6 has only 0.00479% of logged-in page views these days.
Thanks. Then I think that's what we should do, and helping that bug forward as well. Clearly still supporting IE6 and below for logins isn't sustainable for security anymore.
Le 15/10/2014 15:37, Mark Bergsma a écrit :
This bug is very relevant here:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56575
Summary: In April Oliver found that IE 6 has only 0.00479% of logged-in page views these days.
Thanks. Then I think that's what we should do, and helping that bug forward as well. Clearly still supporting IE6 and below for logins isn't sustainable for security anymore.
Nice find Gabriel!
So I guess we just have to publicly announce that IE6 and below will no more be able to login and make it happen.
Thanks Gabriel, that number is indeed way lower!!
On Wed, Oct 15, 2014 at 4:44 PM, Antoine Musso hashar@free.fr wrote:
Le 15/10/2014 15:37, Mark Bergsma a écrit :
This bug is very relevant here:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56575
Summary: In April Oliver found that IE 6 has only 0.00479% of logged-in page views these days.
Thanks. Then I think that's what we should do, and helping that bug forward as well. Clearly still supporting IE6 and below for logins isn't sustainable for security anymore.
Nice find Gabriel!
So I guess we just have to publicly announce that IE6 and below will no more be able to login and make it happen.
-- Antoine "hashar" Musso
You invoked my name!
Emphasis is "logged-in". If you guys want more solid *overall* numbers, I can get those in short order; this seems like a pretty critical question to have data on, fast. Lemme know.
On 15 October 2014 10:45, Alexandros Kosiaris akosiaris@wikimedia.org wrote:
Thanks Gabriel, that number is indeed way lower!!
On Wed, Oct 15, 2014 at 4:44 PM, Antoine Musso hashar@free.fr wrote:
Le 15/10/2014 15:37, Mark Bergsma a écrit :
This bug is very relevant here:
https://bugzilla.wikimedia.org/show_bug.cgi?id=56575
Summary: In April Oliver found that IE 6 has only 0.00479% of
logged-in page
views these days.
Thanks. Then I think that's what we should do, and helping that bug forward as well. Clearly still supporting IE6 and below for logins isn't sustainable for security anymore.
Nice find Gabriel!
So I guess we just have to publicly announce that IE6 and below will no more be able to login and make it happen.
-- Antoine "hashar" Musso
-- Alexandros Kosiaris akosiaris@wikimedia.org
Ops mailing list Ops@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ops
On Wed, Oct 15, 2014 at 3:43 PM, Oliver Keyes okeyes@wikimedia.org wrote:
You invoked my name!
Emphasis is "logged-in". If you guys want more solid *overall* numbers, I can get those in short order; this seems like a pretty critical question to have data on, fast. Lemme know.
If you can source some good reliable numbers, probably what we care about (all of which have been estimated to some degree in this thread already, I think?) is:
% of all requests from IE6 % of all https requests from IE6 % of all text/html https requests from IE6 (not so important IMHO, if it's difficult) % of all logged-in https requests (or alternatively, % of all successful https login attempts) from IE6.
First three are pretty trivial; last one is a bit of a pain, but doable if someone wants to poke me on IRC (/query Ironholds) and chat about what an unambiguous successful login action would look like in terms of requests. But I can do the first three in a jiffy.
On 15 October 2014 13:32, Brandon Black bblack@wikimedia.org wrote:
On Wed, Oct 15, 2014 at 3:43 PM, Oliver Keyes okeyes@wikimedia.org wrote:
You invoked my name!
Emphasis is "logged-in". If you guys want more solid *overall* numbers, I can get those in short order; this seems like a pretty critical question to have data on, fast. Lemme know.
If you can source some good reliable numbers, probably what we care about (all of which have been estimated to some degree in this thread already, I think?) is:
% of all requests from IE6 % of all https requests from IE6 % of all text/html https requests from IE6 (not so important IMHO, if it's difficult) % of all logged-in https requests (or alternatively, % of all successful https login attempts) from IE6.
(With "jiffy" read "a day"; even with sampling, big logs are big, and I imagine we probably want ~30 days of data.)
On 15 October 2014 15:18, Oliver Keyes okeyes@wikimedia.org wrote:
First three are pretty trivial; last one is a bit of a pain, but doable if someone wants to poke me on IRC (/query Ironholds) and chat about what an unambiguous successful login action would look like in terms of requests. But I can do the first three in a jiffy.
On 15 October 2014 13:32, Brandon Black bblack@wikimedia.org wrote:
On Wed, Oct 15, 2014 at 3:43 PM, Oliver Keyes okeyes@wikimedia.org wrote:
You invoked my name!
Emphasis is "logged-in". If you guys want more solid *overall* numbers, I can get those in short order; this seems like a pretty critical question to have data on, fast. Lemme know.
If you can source some good reliable numbers, probably what we care about (all of which have been estimated to some degree in this thread already, I think?) is:
% of all requests from IE6 % of all https requests from IE6 % of all text/html https requests from IE6 (not so important IMHO, if it's difficult) % of all logged-in https requests (or alternatively, % of all successful https login attempts) from IE6.
-- Oliver Keyes Research Analyst Wikimedia Foundation
Update: Yuvi's pointed me towards a login attempts schema. All 4 are doable. Data tomorrow morning EST at the latest.
On 15 October 2014 15:19, Oliver Keyes okeyes@wikimedia.org wrote:
(With "jiffy" read "a day"; even with sampling, big logs are big, and I imagine we probably want ~30 days of data.)
On 15 October 2014 15:18, Oliver Keyes okeyes@wikimedia.org wrote:
First three are pretty trivial; last one is a bit of a pain, but doable if someone wants to poke me on IRC (/query Ironholds) and chat about what an unambiguous successful login action would look like in terms of requests. But I can do the first three in a jiffy.
On 15 October 2014 13:32, Brandon Black bblack@wikimedia.org wrote:
On Wed, Oct 15, 2014 at 3:43 PM, Oliver Keyes okeyes@wikimedia.org wrote:
You invoked my name!
Emphasis is "logged-in". If you guys want more solid *overall* numbers, I can get those in short order; this seems like a pretty critical question to have data on, fast. Lemme know.
If you can source some good reliable numbers, probably what we care about (all of which have been estimated to some degree in this thread already, I think?) is:
% of all requests from IE6 % of all https requests from IE6 % of all text/html https requests from IE6 (not so important IMHO, if it's difficult) % of all logged-in https requests (or alternatively, % of all successful https login attempts) from IE6.
-- Oliver Keyes Research Analyst Wikimedia Foundation
-- Oliver Keyes Research Analyst Wikimedia Foundation
There's no data for IE6 in EventLogging because IE6 gets no JS these days. Maybe, if there's old enough data...
On Wed, Oct 15, 2014 at 12:46 PM, Oliver Keyes okeyes@wikimedia.org wrote:
Update: Yuvi's pointed me towards a login attempts schema. All 4 are doable. Data tomorrow morning EST at the latest.
On 15 October 2014 15:19, Oliver Keyes okeyes@wikimedia.org wrote:
(With "jiffy" read "a day"; even with sampling, big logs are big, and I imagine we probably want ~30 days of data.)
On 15 October 2014 15:18, Oliver Keyes okeyes@wikimedia.org wrote:
First three are pretty trivial; last one is a bit of a pain, but doable if someone wants to poke me on IRC (/query Ironholds) and chat about what an unambiguous successful login action would look like in terms of requests. But I can do the first three in a jiffy.
On 15 October 2014 13:32, Brandon Black bblack@wikimedia.org wrote:
On Wed, Oct 15, 2014 at 3:43 PM, Oliver Keyes okeyes@wikimedia.org wrote:
You invoked my name!
Emphasis is "logged-in". If you guys want more solid *overall* numbers, I can get those in short order; this seems like a pretty critical question to have data on, fast. Lemme know.
If you can source some good reliable numbers, probably what we care about (all of which have been estimated to some degree in this thread already, I think?) is:
% of all requests from IE6 % of all https requests from IE6 % of all text/html https requests from IE6 (not so important IMHO, if it's difficult) % of all logged-in https requests (or alternatively, % of all successful https login attempts) from IE6.
-- Oliver Keyes Research Analyst Wikimedia Foundation
-- Oliver Keyes Research Analyst Wikimedia Foundation
-- Oliver Keyes Research Analyst Wikimedia Foundation
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
Darnit. Ah well! Okay; finished building the code to retrieve this data. Takes ~400 seconds to handle a day of logs, so take into account parallelisation and I should (should!) have something to show in a couple of hours for the first 3 Qs. The fourth, it seems, is beyond our ken.
On 15 October 2014 15:54, Max Semenik maxsem.wiki@gmail.com wrote:
There's no data for IE6 in EventLogging because IE6 gets no JS these days. Maybe, if there's old enough data...
On Wed, Oct 15, 2014 at 12:46 PM, Oliver Keyes okeyes@wikimedia.org wrote:
Update: Yuvi's pointed me towards a login attempts schema. All 4 are doable. Data tomorrow morning EST at the latest.
On 15 October 2014 15:19, Oliver Keyes okeyes@wikimedia.org wrote:
(With "jiffy" read "a day"; even with sampling, big logs are big, and I imagine we probably want ~30 days of data.)
On 15 October 2014 15:18, Oliver Keyes okeyes@wikimedia.org wrote:
First three are pretty trivial; last one is a bit of a pain, but doable if someone wants to poke me on IRC (/query Ironholds) and chat about what an unambiguous successful login action would look like in terms of requests. But I can do the first three in a jiffy.
On 15 October 2014 13:32, Brandon Black bblack@wikimedia.org wrote:
On Wed, Oct 15, 2014 at 3:43 PM, Oliver Keyes okeyes@wikimedia.org wrote:
You invoked my name!
Emphasis is "logged-in". If you guys want more solid *overall* numbers, I can get those in short order; this seems like a pretty critical question to have data on, fast. Lemme know.
If you can source some good reliable numbers, probably what we care about (all of which have been estimated to some degree in this thread already, I think?) is:
% of all requests from IE6 % of all https requests from IE6 % of all text/html https requests from IE6 (not so important IMHO, if it's difficult) % of all logged-in https requests (or alternatively, % of all successful https login attempts) from IE6.
-- Oliver Keyes Research Analyst Wikimedia Foundation
-- Oliver Keyes Research Analyst Wikimedia Foundation
-- Oliver Keyes Research Analyst Wikimedia Foundation
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
-- Best regards, Max Semenik ([[User:MaxSem]])
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
Is there any way you can look at traffic for particular pages? If so, you could look at traffic to something like Special:Watchlist or Special:UserLogin on a representative sample of wikis - anyone using these two pages is very likely to represent a logged-in user, and traffic numbers to them are high enough you might get useful data even with the sampling limits.
Andrew.
On 15 October 2014 21:50, Oliver Keyes okeyes@wikimedia.org wrote:
Darnit. Ah well! Okay; finished building the code to retrieve this data. Takes ~400 seconds to handle a day of logs, so take into account parallelisation and I should (should!) have something to show in a couple of hours for the first 3 Qs. The fourth, it seems, is beyond our ken.
On 15 October 2014 15:54, Max Semenik maxsem.wiki@gmail.com wrote:
There's no data for IE6 in EventLogging because IE6 gets no JS these days. Maybe, if there's old enough data...
On Wed, Oct 15, 2014 at 12:46 PM, Oliver Keyes okeyes@wikimedia.org wrote:
Update: Yuvi's pointed me towards a login attempts schema. All 4 are doable. Data tomorrow morning EST at the latest.
On 15 October 2014 15:19, Oliver Keyes okeyes@wikimedia.org wrote:
(With "jiffy" read "a day"; even with sampling, big logs are big, and I imagine we probably want ~30 days of data.)
On 15 October 2014 15:18, Oliver Keyes okeyes@wikimedia.org wrote:
First three are pretty trivial; last one is a bit of a pain, but doable if someone wants to poke me on IRC (/query Ironholds) and chat about what an unambiguous successful login action would look like in terms of requests. But I can do the first three in a jiffy.
On 15 October 2014 13:32, Brandon Black bblack@wikimedia.org wrote:
On Wed, Oct 15, 2014 at 3:43 PM, Oliver Keyes okeyes@wikimedia.org wrote: > > You invoked my name! > > Emphasis is "logged-in". If you guys want more solid overall numbers, > I can get those in short order; this seems like a pretty critical question > to have data on, fast. Lemme know.
If you can source some good reliable numbers, probably what we care about (all of which have been estimated to some degree in this thread already, I think?) is:
% of all requests from IE6 % of all https requests from IE6 % of all text/html https requests from IE6 (not so important IMHO, if it's difficult) % of all logged-in https requests (or alternatively, % of all successful https login attempts) from IE6.
-- Oliver Keyes Research Analyst Wikimedia Foundation
-- Oliver Keyes Research Analyst Wikimedia Foundation
-- Oliver Keyes Research Analyst Wikimedia Foundation
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
-- Best regards, Max Semenik ([[User:MaxSem]])
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
-- Oliver Keyes Research Analyst Wikimedia Foundation
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
Sensible! I could. The code is already running, mind, so it would require a restart. But, I'm not seeing why "logged-in" people are a distinct subgroup for the purpose of disabling HTTPS. If we just want "editors", I can get editors, of course.
On 15 October 2014 17:45, Andrew Gray andrew.gray@dunelm.org.uk wrote:
Is there any way you can look at traffic for particular pages? If so, you could look at traffic to something like Special:Watchlist or Special:UserLogin on a representative sample of wikis - anyone using these two pages is very likely to represent a logged-in user, and traffic numbers to them are high enough you might get useful data even with the sampling limits.
Andrew.
On 15 October 2014 21:50, Oliver Keyes okeyes@wikimedia.org wrote:
Darnit. Ah well! Okay; finished building the code to retrieve this data. Takes ~400 seconds to handle a day of logs, so take into account parallelisation and I should (should!) have something to show in a
couple of
hours for the first 3 Qs. The fourth, it seems, is beyond our ken.
On 15 October 2014 15:54, Max Semenik maxsem.wiki@gmail.com wrote:
There's no data for IE6 in EventLogging because IE6 gets no JS these
days.
Maybe, if there's old enough data...
On Wed, Oct 15, 2014 at 12:46 PM, Oliver Keyes okeyes@wikimedia.org wrote:
Update: Yuvi's pointed me towards a login attempts schema. All 4 are doable. Data tomorrow morning EST at the latest.
On 15 October 2014 15:19, Oliver Keyes okeyes@wikimedia.org wrote:
(With "jiffy" read "a day"; even with sampling, big logs are big, and
I
imagine we probably want ~30 days of data.)
On 15 October 2014 15:18, Oliver Keyes okeyes@wikimedia.org wrote:
First three are pretty trivial; last one is a bit of a pain, but
doable
if someone wants to poke me on IRC (/query Ironholds) and chat about
what an
unambiguous successful login action would look like in terms of
requests.
But I can do the first three in a jiffy.
On 15 October 2014 13:32, Brandon Black bblack@wikimedia.org
wrote:
> > > > On Wed, Oct 15, 2014 at 3:43 PM, Oliver Keyes <okeyes@wikimedia.org
> wrote: >> >> You invoked my name! >> >> Emphasis is "logged-in". If you guys want more solid overall
numbers,
>> I can get those in short order; this seems like a pretty critical
question
>> to have data on, fast. Lemme know. > > > If you can source some good reliable numbers, probably what we care > about (all of which have been estimated to some degree in this
thread
> already, I think?) is: > > % of all requests from IE6 > % of all https requests from IE6 > % of all text/html https requests from IE6 (not so important IMHO,
if
> it's difficult) > % of all logged-in https requests (or alternatively, % of all > successful https login attempts) from IE6. >
-- Oliver Keyes Research Analyst Wikimedia Foundation
-- Oliver Keyes Research Analyst Wikimedia Foundation
-- Oliver Keyes Research Analyst Wikimedia Foundation
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
-- Best regards, Max Semenik ([[User:MaxSem]])
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
-- Oliver Keyes Research Analyst Wikimedia Foundation
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
--
- Andrew Gray andrew.gray@dunelm.org.uk
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
"Editors" could also work - does it count IP edits?
AIUI (I may have got this wrong) if we disable HTTPS it shouldn't affect the normal reading experience for a passer-by - it should work without too many problems. (After all, it worked fine six months ago)
But actually logging in *requires* the use of https, and thus if you disable https for IE6 users they won't be able to log in - so we'll be effectively blocking any users restricted to IE6 only, as Chris notes above. Which is, of course, a major issue if there are active editors using the browser, less critical if they're all readers...
Andrew.
On 16 October 2014 00:02, Oliver Keyes okeyes@wikimedia.org wrote:
Sensible! I could. The code is already running, mind, so it would require a restart. But, I'm not seeing why "logged-in" people are a distinct subgroup for the purpose of disabling HTTPS. If we just want "editors", I can get editors, of course.
On 15 October 2014 17:45, Andrew Gray andrew.gray@dunelm.org.uk wrote:
Is there any way you can look at traffic for particular pages? If so, you could look at traffic to something like Special:Watchlist or Special:UserLogin on a representative sample of wikis - anyone using these two pages is very likely to represent a logged-in user, and traffic numbers to them are high enough you might get useful data even with the sampling limits.
Andrew.
On 15 October 2014 21:50, Oliver Keyes okeyes@wikimedia.org wrote:
Darnit. Ah well! Okay; finished building the code to retrieve this data. Takes ~400 seconds to handle a day of logs, so take into account parallelisation and I should (should!) have something to show in a couple of hours for the first 3 Qs. The fourth, it seems, is beyond our ken.
On 15 October 2014 15:54, Max Semenik maxsem.wiki@gmail.com wrote:
There's no data for IE6 in EventLogging because IE6 gets no JS these days. Maybe, if there's old enough data...
On Wed, Oct 15, 2014 at 12:46 PM, Oliver Keyes okeyes@wikimedia.org wrote:
Update: Yuvi's pointed me towards a login attempts schema. All 4 are doable. Data tomorrow morning EST at the latest.
On 15 October 2014 15:19, Oliver Keyes okeyes@wikimedia.org wrote:
(With "jiffy" read "a day"; even with sampling, big logs are big, and I imagine we probably want ~30 days of data.)
On 15 October 2014 15:18, Oliver Keyes okeyes@wikimedia.org wrote: > > First three are pretty trivial; last one is a bit of a pain, but > doable > if someone wants to poke me on IRC (/query Ironholds) and chat about > what an > unambiguous successful login action would look like in terms of > requests. > But I can do the first three in a jiffy. > > On 15 October 2014 13:32, Brandon Black bblack@wikimedia.org > wrote: >> >> >> >> On Wed, Oct 15, 2014 at 3:43 PM, Oliver Keyes >> okeyes@wikimedia.org >> wrote: >>> >>> You invoked my name! >>> >>> Emphasis is "logged-in". If you guys want more solid overall >>> numbers, >>> I can get those in short order; this seems like a pretty critical >>> question >>> to have data on, fast. Lemme know. >> >> >> If you can source some good reliable numbers, probably what we care >> about (all of which have been estimated to some degree in this >> thread >> already, I think?) is: >> >> % of all requests from IE6 >> % of all https requests from IE6 >> % of all text/html https requests from IE6 (not so important IMHO, >> if >> it's difficult) >> % of all logged-in https requests (or alternatively, % of all >> successful https login attempts) from IE6. >> > > > > -- > Oliver Keyes > Research Analyst > Wikimedia Foundation
-- Oliver Keyes Research Analyst Wikimedia Foundation
-- Oliver Keyes Research Analyst Wikimedia Foundation
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
-- Best regards, Max Semenik ([[User:MaxSem]])
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
-- Oliver Keyes Research Analyst Wikimedia Foundation
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
--
- Andrew Gray andrew.gray@dunelm.org.uk
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
-- Oliver Keyes Research Analyst Wikimedia Foundation
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
Methodology: 1. take the last 30 days of sampled logs 2. look for IE6 3. count proportionately for (all requests|all text/html requests)
The results: of /both HTTPS and http/ requests, ~0.20% come from IE6; of all text/html requests, 1.3%. I'd note that this is likely to be an /over/estimate; there are some browsers which spoof IE6 that'll be included in these numbers, but would be excluded from e.g. Christian's.[0] On the HTTPS front, Christian's numbers, I trust - checking for HTTPs didn't work for me, since the terminators aren't actually included in the sampled logs.[1] Full results and codebase at https://github.com/Ironholds/POODLE
[0] I knowingly used a crappy ua parsing strategy because it was also a *really fast* ua parsing strategy, and 30 days of logs, even sampled logs, ain't nothing. [1] This doesn't apply to Christian's results; he took the terminator IPs and checked for requests from those ranges. Sensible!
On 15 October 2014 16:50, Oliver Keyes okeyes@wikimedia.org wrote:
Darnit. Ah well! Okay; finished building the code to retrieve this data. Takes ~400 seconds to handle a day of logs, so take into account parallelisation and I should (should!) have something to show in a couple of hours for the first 3 Qs. The fourth, it seems, is beyond our ken.
On 15 October 2014 15:54, Max Semenik maxsem.wiki@gmail.com wrote:
There's no data for IE6 in EventLogging because IE6 gets no JS these days. Maybe, if there's old enough data...
On Wed, Oct 15, 2014 at 12:46 PM, Oliver Keyes okeyes@wikimedia.org wrote:
Update: Yuvi's pointed me towards a login attempts schema. All 4 are doable. Data tomorrow morning EST at the latest.
On 15 October 2014 15:19, Oliver Keyes okeyes@wikimedia.org wrote:
(With "jiffy" read "a day"; even with sampling, big logs are big, and I imagine we probably want ~30 days of data.)
On 15 October 2014 15:18, Oliver Keyes okeyes@wikimedia.org wrote:
First three are pretty trivial; last one is a bit of a pain, but doable if someone wants to poke me on IRC (/query Ironholds) and chat about what an unambiguous successful login action would look like in terms of requests. But I can do the first three in a jiffy.
On 15 October 2014 13:32, Brandon Black bblack@wikimedia.org wrote:
On Wed, Oct 15, 2014 at 3:43 PM, Oliver Keyes okeyes@wikimedia.org wrote:
> You invoked my name! > > Emphasis is "logged-in". If you guys want more solid *overall* > numbers, I can get those in short order; this seems like a pretty critical > question to have data on, fast. Lemme know. >
If you can source some good reliable numbers, probably what we care about (all of which have been estimated to some degree in this thread already, I think?) is:
% of all requests from IE6 % of all https requests from IE6 % of all text/html https requests from IE6 (not so important IMHO, if it's difficult) % of all logged-in https requests (or alternatively, % of all successful https login attempts) from IE6.
-- Oliver Keyes Research Analyst Wikimedia Foundation
-- Oliver Keyes Research Analyst Wikimedia Foundation
-- Oliver Keyes Research Analyst Wikimedia Foundation
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
-- Best regards, Max Semenik ([[User:MaxSem]])
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
-- Oliver Keyes Research Analyst Wikimedia Foundation
Hi,
On Wed, Oct 15, 2014 at 12:11:17PM +0200, Mark Bergsma wrote:
Disabling SSL 3.0 could break SSL completely for something in the order of 1.5% of HTML page requests, according to http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm Perhaps the Analytics team could do some additional, specific investigation on this to aid this decision?
Of all https requests, ~0.10% come from IE <=6. Of all https requests that respond with text/html, ~0.74% come from IE <=6.
Have fun, Christian
P.S.: In case you want to verify, I used /a/squid/archive/sampled/sampled-1000.tsv.log-20141015.gz filtered to requests that come from an ssl termintator and used ua-parser 1.3.0 to identify User-Agents.
Since we're only interested in ratios, a recent 24h period seemed sufficient.