[00:00:10] Katie: yes, now-ish [00:00:51] TimStarling: devunt: is it about time to start? [00:00:56] Cool. I'll actually be around for one. :-) [00:01:23] #startmeeting RFC meeting [00:01:24] Meeting started Thu Oct 1 00:01:23 2015 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [00:01:24] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [00:01:24] The meeting name has been set to 'rfc_meeting' [00:01:48] #link https://phabricator.wikimedia.org/E74 [00:02:15] #topic Allow user login with email address in addition to username | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [00:03:11] #link https://phabricator.wikimedia.org/T30085 [00:03:51] devunt: how is the implementation going? [00:04:31] I see there's been no new patchsets in the last week [00:04:53] I was busy last week [00:04:58] codes in the gerrit is the latest version [00:05:18] fair enough [00:05:21] * robla waves at devunt [00:05:23] csteipp: are you here? [00:05:45] Yeah [00:05:55] TimStarling: Given that "@" is generally disallowed in usernames on MediaWiki wikis, what other issues are there from using a single field for both e-mail address or username? [00:06:33] * robla didn't think to put it on csteipp's calendar [00:06:36] well, csteipp's concern with the original patchset was that attackers can use brute force to find valid email addresses [00:06:52] if we give feedback about the email address being associated with a user [00:07:11] that has been addressed, but it means losing some user feedback and thus usability [00:07:37] if the user types their email address into the box, and their password was wrong, we can't tell them that, we can only say "the email or password was wrong" [00:08:15] there is still the possibility of a timing attack, but maybe enough has been done for csteipp to remove his -2? [00:08:54] Yeah, I need to review the current patchset (sorry, haven't gotten to it) [00:09:19] I've suggested some changes on gerrit and some more changes via private message [00:09:28] We're only checking accounts where there's exactly 1 account with that email, and the email is confirmed, right? [00:09:30] not disclosing if the account exists or not is pretty standard on failed web logins I think. It shouldn't be a huge problem [00:09:31] and my changes will probably make the timing attack more severe [00:09:32] The current implementation does not have the possibility of a timing attack [00:09:37] unless I did something wrong [00:09:46] TimStarling: We're still gaining a lot of usability by offering login via e-mail address functionality. [00:10:04] Like I see what you're saying, but I don't think the vague error messages matter very much. [00:10:16] the question is: how do you log in with CentralAuth or some other auth plugin? [00:10:56] csteipp should be thinking "holy crap" right now if he remembers what the CA code looks like ;) [00:11:01] Are we keeping CentralAuth around? [00:11:17] Does devunt care about supporting it? [00:11:18] Timing attack is someone can guess email address and (known wrong) password, and the check is slower if the email exists, right? [00:11:29] I'm going to make some edits on my code to make it works with CentralAuth [00:11:34] yes, we're keeping CA for now [00:13:05] It checks the existence of an email address and if it doesn't exists, just hash a dummy string with the same process as saving a new password [00:13:23] well.... [00:13:23] you wait for AuthManager :) [00:13:23] oh yes [00:13:23] CA is not going anywhere [00:13:24] Even in the post-SUL world CA does a lot for us [00:13:26] it should costs a same amount of time [00:13:41] devunt: cool! [00:13:50] * bd808__ switches to an account that isn't so horribly lagged [00:14:11] so the design options for CA are either to extend the idea of login via email address into $wgAuth and the hook interface [00:14:31] or to map the email address to a username early, and maintain the same login by username interface in the backend [00:14:48] and I am leaning towards the latter since it is less code to touch [00:15:22] Anomie, tgr and I really want to get AuthManager done this quarter and it will open up more possibilities for this kind of alternate auth scenario [00:15:24] but then you don't have a backend login attempt if there is no username [00:16:07] bd808__: I don't think we should block devunt based on wants, even really wants. [00:16:36] TimStarling: Mapping early seems fine. [00:17:12] The idea in the initial implementation is to cover the most basic case, in my understanding. A unique e-mail address with a valid password. [00:17:29] it could be wedged into CA in the same places I wedged in the ability to login with a pre-SUL rename user name I think [00:17:55] A unique e-mail address with a valid password using MediaWiki core. [00:17:56] it's gross but there is code there that does it [00:18:11] So yeah, figuring out how this goes into CentralAuth is going to be a challenge-- legoktm and I should probably figure that out. So this wont work on WMF sites until we do that. [00:18:38] and devunt is doing this for WMF, so it is a blocker [00:18:59] Oh, is he? I thought this was a volunteer project. [00:19:00] mainly for WMF [00:19:25] it is a volunteer project but volunteers always have specific motivations [00:20:21] this is (obviously) based on the task T30085, [00:20:36] AuthManager intends to fully replace wgAuth so it might be worth checking it out to avoid working twice [00:20:38] and the author of that task said "especially on a big project like Wikimedia" [00:20:53] Good to know. So yeah, we'll have to figure how to make CA do similar-- is there a task for that part specifically? [00:21:04] although I don't expect the actual authentication code that handles the email address would have to change much [00:21:18] What needs to change in CentralAuth? [00:21:24] If you map early, why does CentralAuth care? [00:21:42] CA manages email addresses, the user_email field is not used [00:21:51] ^ that [00:22:05] so if we map early, CA needs to hook into the mapping function [00:22:07] Oh, really? Ugh. [00:22:09] Have to get CA's version of the email searchable [00:22:23] So I'm going to mapping function hookable [00:22:25] Because on most wikis, global accounts *shoudn't* have an email in the local wiki DB [00:22:32] for CentralAuth or any other plugins [00:22:33] (there's a bug for that) [00:22:41] if you want a good reason for mapping early, maybe look at autocreation [00:22:44] Not to get off-topic too much, but why is that a good thing? [00:23:12] Like why does CentralAuth, in a post-SUL world, need to do its own special thing here and store e-mail addresses separately? [00:23:16] Limit the number of places we store private data [00:23:33] autocreation by email has to work, if you allow login by email, that is critical for usability [00:23:40] in general mapping early seems like the wrong way to this [00:23:47] * csteipp has to leave.. I think the general direction of the patch now looks good, so -2 removed. [00:24:02] how do you avoid timing attacks if you can't even map non-existent email addresses to users? [00:24:03] ^ for core. We need to figure out CA. [00:24:11] csteipp, thanks! [00:24:20] And about user experiences, [00:24:54] I don't think you can completely avoid timing attacks [00:25:08] I initially designed the messages to work as same as github does. [00:25:17] but CA could provide a dummy-login function which is called when there is no username for an email address [00:26:21] anyway AuthManager when used properly will separate most concerns (such as autocreation) so you would only have to write the code to detect when the content of the username field is an email address and fetch the (central)user object based on that [00:26:53] that would also be reasonably safe timing-wise, assuming that searching the DB by username and by email take a similar amount of time [00:27:38] on second thought you don't really need to assume that [00:28:25] as long as the timing for the email path is always the same you are ok for timing attacks I think [00:28:25] to be safe from timing attacks, the search function needs to be equally fast when there are zero and one matches [00:28:43] how do you take out the mysql row construction overhead? [00:28:54] Can we buffer the time? [00:28:56] I thought we can ignore db querying time, can't we? [00:29:06] I think it's really not critical, security-wise [00:29:14] create a dummy row, make it 1 or 2 results instead? [00:29:44] User::newFromEmail() as written now will leak how many accounts are attached I think [00:29:46] like I say, I don't think you can eliminate timing altogether [00:29:52] I think you can try to limit it to say 1ms [00:30:00] or use a LIMIT to make it always return one result which is sometimes a dummy with a password that never matches [00:30:20] then you can start to talk about realistic architectures instead of accounting for every clock cycle [00:31:06] what we want is for the time difference to be less than the typical timing noise [00:31:25] I think variations of server response time is much larger than variations of sql querying time, so we can ignore them. [00:31:40] I mean, we are only talking about leaking email addresses, which MW does routinely via Special:EmailUser [00:32:22] we also publish people's email addresses in various other places, like mailing lists and gerrit [00:32:47] devunt: as long as that variation has nice properties (e.g. close to normal distribution) an attacker can filter it out [00:33:12] I'm not claiming that is an issue significant enough to block the change, just saying that it exists [00:33:15] the question is whether a spammer would bother to run a thousand queries against a given email address, to average out the times and try to derive a measure of probability [00:33:25] or whether they would find easier targets [00:34:10] TimStarling: I think the more problematic attack model is trying to deanonimize users when you have a suspicion who they might be and what email address they might be using [00:34:11] oh, and if an attacker can run thousands of login attempts, would they not try brute-forcing the password? [00:34:21] logins are already rate-limited by IP [00:34:56] well, if you suspect what their email address is, you could just send mail to it [00:35:15] if you have 100 ideas about what their email address might be, you could send mail to all of them [00:36:06] anyway, that is my position, be practical, benchmark it, don't try to count every cycle [00:36:31] if the benchmarks show a problem then we can find a solution [00:36:47] I agree with TimStarling that there is no way to mitigate timing attack completely [00:38:58] and there is more than a hundreds of thousands ways to find a someone's email address to make a list of email addresses for spamming [00:39:11] #info So yeah, figuring out how this goes into CentralAuth is going to be a challenge-- legoktm and I should probably figure that out. [00:39:36] devunt: I think there are privacy laws that don't acknowledge your point [00:39:52] And? [00:40:06] Katie: laws we need to comply with [00:40:15] there are privacy laws in the US? [00:40:25] If the legal team has a problem, I have faith in them to say something. [00:41:10] TimStarling: IANAL....I do know the state of California has many [00:41:14] again, you might want to make this a part of the AuthManager rewrite instead of doing it twice [00:41:28] well, if we are claiming that the email address is private data, we should stop doing that [00:41:29] What is AuthManager's status? [00:41:46] since like I say, we give it out routinely via Special:EmailUser [00:41:47] https://phabricator.wikimedia.org/T110283 is the rewrite task for CentralAuth although it's not very informative currently [00:42:15] it's a Q2 goal I believe - bd808 / bd808__ are those final now? [00:42:24] * robla doesn't know exactly what our privacy policy says about email addresses as PII [00:42:24] Q2 means quarter two of what? [00:42:50] by the end of the calendar year (Q2 of WMF fiscal) [00:42:51] sorry, that's Oct-Dec this year [00:43:26] MediaWiki won't be the, uhh, first software package to have login via e-mail address functionality. The laws of California really aren't relevant here unless the Wikimedia Foundation legal team comes forward and says so. [00:44:26] do we have to rewrite this login-via-email codes after AuthManager was implemented in core? [00:44:36] oh, I see we've lost csteipp [00:44:37] again, I wouldn't worry about spammers, I would worry about, say, some Chinese dissident being identified based on email address [00:44:49] but TimStarling is right that there are much easier attacks to make [00:44:55] MediaWiki's login usability is horrible. We need login via e-mail address and hopefully case-insensitive login one day. I think timing attacks and legal arguments are mostly silly distractions. [00:45:03] I helped give voice to them, but I think the timing attack problem is mostly FUD [00:45:27] We can reasonably mitigate, but yeah. [00:45:37] so csteipp thinks he and legoktm should have input into the CA interface [00:45:38] In practice account disclosure on a public wiki is not a huge problem [00:45:55] devunt: all authentication code has to be rewritten to adopt AuthManager [00:46:04] well, not so much rewritten as reorganized [00:46:20] and AuthManager is going to be implemented in this winter? [00:46:42] that's the plan I believe [00:46:55] bd808__: good point about timing attack stuff. I just wanted to make sure we didn't glibly dismiss emails as public info, which it sounds like we aren't [00:46:59] so tgr, you are telling devunt to wait, not to implement and migrate? [00:47:09] I really, really don't want to see work here stall as the result of potential future goals. [00:47:30] because I think it is a pretty simple feature and can be done long before December [00:47:50] AuthManager has been in progress for the last 9 months at various rates of speed. Anomie, Tgr and I will be focusing on it as our major body of work for the next 3 months. That should be enough to get it into production [00:48:50] TimStarling: I'd say go ahead with it. we can catch authmanager up later [00:49:08] T30085 can be done in 2 weeks or before the ends of this month, I think. [00:49:13] TimStarling: not necessarily, but he should look at the AM project and check it's not done in a way that's going to be hard to port [00:49:16] but in theory things like this will be easier to accomplish in the world where authmanager exists [00:49:51] In the future, everything will be simpler and better, yes. Today, it'd be really nice to have working login via e-mail address. :-) [00:49:59] well, it sounds like login by email should be included in the AM design as soon as possible [00:50:32] the design is very generic and definitely allows for it [00:51:00] it basically makes it the responsibility of the auth plugin what kind of fields they would like to manage [00:51:14] that is an action item for someone [00:51:23] in the AM model it would be up to each primary provider (eg CA) to handle the input. It breaks things more cleanly than the core code does today [00:51:53] devunt's patch will have frontend stuff, like changing form labels and error messages, which you will need anyway [00:52:27] And I can re-use the codes when migrating this feature into AM after AM is implmented [00:52:54] the part which needs to be rewritten should be <100 lines [00:53:19] thus I think writting codes now is not a waste of time, though [00:53:38] Am I wrong about this? [00:53:55] #action reading-infrastructure make sure email login is not a problem for T110278 and T110283 [00:54:11] devunt: no. I think you should cary on while you have the time and inclination to work on the feature [00:54:52] ok, anything else in the remaining 5 minutes? [00:55:17] I think we are pretty much all done [00:55:26] devunt: I'm really glad you're working on this. I think it will be a major improvement in MediaWiki's login usability. [00:55:47] agree with Katie, this will be great! [00:55:49] we still have one major problem [00:56:07] mediawiki allows duplication of email address [00:56:10] how can I handle it? [00:56:32] I have an idea for this [00:56:43] sorry, I'm late. /me reads up [00:56:54] rejecting multi-user emails is good for the first version IMO [00:56:56] presumably when the same email address is used, it is usually the same person [00:57:02] I agree with tgr. [00:57:16] and thus, in most cases, the same password [00:57:32] legoktm: tl;dr csteipp volunteered you to help figure out CA intergration :) [00:57:42] so if there is a duplicate email, we can just pick an account randomly and validate the supplied password against it [00:58:14] if it matches, then we can report a user-friendly error message [00:58:15] the current implementation will only process if email address doesn't connected with multiple accounts [00:58:51] like "this email address is used by more than one account, please log in with your username" [00:59:26] a good chunk of CA is just core copied into a hook that uses a different database [00:59:31] if the password doesn't match, then we need to give the generic WRONG_INPUT message which doesn't disclose the presence of any accounts [00:59:31] I think it is bad pattern in some ways [00:59:35] I don't imagine it will be difficult, just the timing stuff [00:59:58] TimStarling: People may still complain about that type of error message violating user privacy. [01:00:03] choosing randomly is not a good idea to me [01:00:16] and I think it is not a good design pattern [01:00:23] +1 on skipping the multiple users having the same email thing for now [01:00:40] We can just reject for now and figure out the harder cases later, right? [01:00:45] well, if two people share the same email address, they can reset each others' passwords if they like [01:01:03] they can't really keep anything private from each other [01:01:23] Hmmm, right. You said only if the password works. That seems fine. [01:01:53] We need a good test suite here. There are a lot of cases. [01:01:53] the only drawback is that if the password is not the same everywhere you get somewhat random behavior [01:01:57] yeah, if the password doesn't match, you have to assume it is an attacker scanning for valid email addresses [01:02:37] yes I was worried about what tgr mentioned [01:02:45] which I don't think is unusual e.g. people use the same email for their bot but set a different password [01:02:52] probably not a big deal though [01:03:06] or people who use the same email and password for multiple bots >.> [01:03:37] I think we have a basicially 3 choices here [01:04:03] 1. Only accepts if there is only one email address in the database [01:04:26] 2. Checking the password of randomly selected account (as TimStarling mentioned) [01:04:47] 3. Checking passwords of all accounts that have the same email address [01:04:51] TimStarling's suggestion is still 1 just with an improved error message [01:05:03] we can continue this discussion on phabricator [01:05:24] I am fine with devunt's implementation (1) for now [01:05:29] tgr, oh, yes, it is. [01:05:38] * robla ducks out [01:05:54] #endmeeting [01:05:55] Meeting ended Thu Oct 1 01:05:54 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [01:05:55] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-10-01-00.01.html [01:05:55] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-10-01-00.01.txt [01:05:55] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-10-01-00.01.wiki [01:05:55] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-10-01-00.01.log.html [01:06:17] thanks for the nice meeting! [01:06:45] thanks for showing up on such short notice devunt! glad it worked out! [01:06:51] now I'm really going :-) [01:07:04] I'm excited to see this move forward :) [01:07:22] devunt: thanks for working on it, it's a much-needed feature [17:47:24] Hello everyone. [17:47:29] It's that time again. [17:48:02] We'll be holding Wikimedia's monthly Metrics meeting for October in a few minutes. [17:48:26] I'm the IRC facilitator again. [17:48:46] During the meeting, if you have any questions to ask or points to make, write them in here. [17:49:10] I'll see them, as will others. [17:49:24] People may be able to answer immediately; if so, hurrah. [17:49:33] If not, I'll ask them during the question period at the end. [17:49:53] So, that's my rambling bit done for the next ten minutes. :-) [17:56:02] Good morning. [17:56:03] James_F: are you the voice of IRC today? [17:57:00] Indeed. [17:57:08] 2015-10-01 - 12:40:47 I'm the IRC facilitator again. [17:57:10] Pine: Sorry, you missed my introduction by a minute or so. :-) [17:57:11] Good evening! [17:57:22] Isn't he always, Pine? :) [17:57:40] rdaiccherlb: Sometimes I present. :-) [17:57:49] I have questions ready for today's meeting, even though I don't know exactly what the meeting contents will be. [17:58:19] We'll be starting in about 2 minutes' time. [17:58:37] Agenda is https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/2015-10 [18:00:33] * Fluffernutter didn't know youtube could livestream [18:00:38] technology! [18:00:45] OK, video stream is live or will be very soon. [18:00:52] Shout when you can see/hear. [18:01:08] I can see it [18:01:09] James_F, I see! [18:01:10] If you have any video issues, please comment so I can get someone to try to fix it. [18:01:11] hear nothing [18:01:11] Yay. [18:01:12] i can see [18:01:14] I cannot hear! [18:01:21] there we go [18:01:23] Good. [18:01:31] sound! [18:01:34] and hear! [18:01:53] New slogan: Wiki Loves Video. [18:02:29] (& cheeses) [18:02:39] * guillom salue Pyb. [18:02:50] guillom: coucou [18:03:02] WELCOME! [18:03:13] Wooooo Fluffernutter [18:03:17] Welcome, everyone. :) [18:03:20] * Fluffernutter feels famous [18:04:00] It's also my two-year anniversary as a volunteer. [18:04:05] CONGRATS FOKS [18:04:08] also everyone else. [18:04:08] foks: :-) [18:04:09] yay foks [18:04:22] applause for everyone who's stuck around more than a few days!! [18:04:28] Heh [18:04:35] foks: We haven't hired you yet? [18:04:37] Applause also for the editors who only ever make one. [18:04:45] For editor retention purposes, 5 edits and a few days is indeed something to celebrate. [18:04:48] marktraceur, as of May. [18:04:54] Congrats to the anniversaries too. [18:04:58] But before that I was still with the WMF! [18:05:00] Oh. [18:05:03] Kemayo: 0/ [18:05:04] halfak, glad to see you didn't get skipped this time. [18:05:20] Ahh! metrics. I missed the start [18:05:43] halfak, well, they listed your anniversary. :) [18:05:47] foks = free open knowledge supporter [18:05:48] \o/ [18:05:53] 4 years represent [18:06:00] spagewmf, you know it! [18:06:06] halfak: Congratulations. :-) [18:06:45] gilles: \o [18:07:21] I have a suggested translation challenge: have a Metrics meeting with everyone speaking any language other than English. [18:07:35] o_O [18:07:46] Celebrate linguistic diversity. [18:07:46] Pine, sounds like fun. May I speak in body language? [18:07:48] Pine: Do you think that would serve the purpose of transmitting information clearly to the most people? [18:07:59] * subbu likes this new way of having different people presenting / facilitating the meeting [18:08:01] Seriously though, metrics being dominated by English is a limitatiomn [18:08:02] James_F, there would be simultaneous translation into all UN languages, natch. [18:08:04] We have a great blog post about these milestones. [18:08:07] Just sayin'. [18:08:09] Pine: Somehow I worry. :-) [18:08:17] foks: Links or it didn't happen. [18:08:21] Congrats to the Wikipedias on the milestones. [18:08:25] matt_flaschen: Oh goody. [18:08:35] feed gone freezy for anyone else? [18:08:42] OK for me [18:08:48] Fluffernutter, ^ [18:08:56] Ditto [18:08:57] https://blog.wikimedia.org/2015/09/23/wikimedia-project-milestones/ [18:09:04] Just for future reference: White on forest is not an ideal color scheme. [18:09:04] OMG background with white and white text [18:09:10] * Fluffernutter refreshes, rejoins the living [18:09:37] foks: Thank you. [18:09:42] Not at all. [18:09:50] WHITE TEXT! [18:09:55] Fluffernutter: Sometimes YouTube live streams get stuck on individual clients, sadly. [18:10:13] For those interested, I believe the Wikidata edits for the Swedish Maritime Museum vocabulary added more than 4,000,000 bytes [18:10:23] Ainali: Neat. [18:10:42] Very neat! [18:10:48] 4MB doesn't sound like much for us modern files-sharers, but that *A LOT OF TEXT* [18:11:13] couldn't play this youtube video in firefox, had to use chrome, said my browser doesn't recognize any of the formats avalaible. but i dont have the issue with other youtube videos/streams. just a side-note [18:11:15] Wikidata also has a very terse structured format, so it's even more if you compare to English text. [18:12:11] matt_flaschen, hard to say since wikidata adds a lot of JSON stuffs around the content. [18:12:19] not to mention _every_ statement added was sourced :) [18:12:22] mutante: Have you used it on other 'live' YouTube streams? [18:12:57] mutante: ISTR it's transcoded offline, not whilst it's streaming, so if your client doesn't support the streaming codec it won't work. [18:13:29] heatherw: were you responsible for the visual design of the fundraising report? It looked rather heatherwish. [18:13:46] James_F: i'd claim i have in the past, yea. but that makes sense [18:14:04] Pine: Nope :) just the cover (with the mistake) [18:14:07] Again with the "global north/south"? [18:14:13] I thought we dropped that terminology. [18:14:24] Ok, who was the designer? [18:14:25] foks: why did you think that? [18:14:25] FYI, these colors aren't showing up for me via the stream [18:14:31] That's quite a lot of countries considering there were only 245 people. [18:14:42] Yeah, impressive. [18:14:55] heatherw, I'm sure others had suggested terms that weren't as misleading? [18:15:14] foks, actually I haven't heard a single term that most people like better. [18:15:26] Maybe I imagined it. [18:15:32] Though arguably that's because combining them together is itself problematic. [18:15:34] matt_flaschen: I prefer MEDCs/LEDCs, but I know others dislike the term. [18:15:36] Something like "developing areas". [18:15:45] I don't remember exactly. [18:15:47] developing is the worst one :) [18:16:00] Let's not fight about it. :-) [18:16:05] At least it doesn't sound like it includes Australia. ;) [18:16:22] But yes. This is tangentical. [18:17:24] foks: abartov's job title mentions 'emerging communities', perhaps that's better? [18:17:37] I think that's the term I'm referring to. [18:17:40] Anyone else here prefers looking at the speaker & the slides rather than just the slides? [18:17:53] Niharika, I prefer looking at the slides, personally. [18:18:07] I like when it goes back and forth. [18:18:10] But I know that's more work. [18:18:14] depends on the slides [18:18:30] Anyone else struggling with the color pallet? [18:18:31] You need a director/producer :) [18:18:31] The white on green, and white on gray is also hard to read. [18:18:37] palette* [18:18:44] thank guillom ;) [18:18:47] :) [18:18:51] Even the white on orange, somewhat, though I'm not sure why. [18:19:06] It's weird that the text in the table is blurry [18:19:13] Their entrance to the plan was late, so they are using slides made for other reasons (not following color guidelines) [18:19:23] halfak: I bet that's a jpg or similar and not a text in the presentation itself [18:19:24] heatherw, gotcha Makes sense. [18:19:36] JPG of text is a serious offense [18:19:41] ;) [18:19:47] *nod* [18:19:50] :) [18:20:26] +1 to "I think it would be great to provide access to WMF tech staff to grantees". This should be treated as a budgetary expense, just like money, but can be appropriate in some cases. [18:20:53] I've been pining for that for years, and it's increasingly happening. [18:21:00] lol @ pine pining [18:21:48] low-risk should not be seen as equivalent to low-cost. [18:21:53] But yeah. +1. [18:22:04] Something can be high-risk (it could either work really well, or flop) but low-cost, and might be worth supporting. [18:22:17] matt_flaschen: yes. A number of APGs are low risk and high cost, and IEGs can be the other way around. [18:23:19] HAHAH Look at Asaf [18:23:21] (If you have questions for Siko's bit, think about asking them now.) [18:23:28] From what I can tell, there is a *lot* of WMF staff time, from Grants and Eval, that gets devoted to the APGs, and I would like to see some of that attention shifted to the smaller grants programs. [18:23:39] heh, Asaf :) [18:23:45] ps - don't ask about slide colors ;P [18:25:21] Is there a list of which countries are considered Global North/South for this graph? [18:25:29] Why isn’t there a banner/notification bar on mobile web to ask people to download the app? [18:25:42] While we're having trouble with some of the visuals in this meeting, I for one am thankful that the audio is much, much better than it used to be. [18:25:47] victorgrigas: There was, for Swedish Wikipedia. [18:25:53] victorgrigas, there was a whole conversation about that on Wikitech. Why do you think that would be good? [18:25:55] \o/ HaeB [18:25:59] victorgrigas: Not sure what's the latest on that. [18:26:14] I noticed on svwiki, that on weekends when desktop dips, mobile rises [18:26:19] victorgrigas: JonKatz might know. [18:26:20] important to be aware that https was rolled out gradually - the vertical line in https://commons.wikimedia.org/wiki/File:Wikimedia_daily_pageviews,_all_vs._mobile_(April_2015-).png only marks that start of the rollout [18:26:26] I actually have less of a problem with it than other people. [18:26:27] victorgrigas, why do we want people to have the app more than mobile web? [18:26:28] matt_flaschen, https://meta.wikimedia.org/wiki/List_of_countries_by_regional_classification maybe? [18:26:48]