[07:00:16] #startmeeting RFC meeting [07:00:16] Meeting started Thu Feb 14 07:00:16 2019 UTC and is due to finish in 60 minutes. The chair is KateChapman. Information about MeetBot at http://wiki.debian.org/MeetBot. [07:00:16] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [07:00:16] The meeting name has been set to 'rfc_meeting' [07:00:32] o/ [07:00:37] #topic Use Github login for mediawiki.org - https://phabricator.wikimedia.org/T215046 [07:00:44] <_joe_> o/ (more or less) [07:00:48] who else is here? [07:01:41] o/ [07:01:45] (as a reminder while people join please use #info and #action as appropriate to make sure things make it into the minutes) [07:02:19] o/ [07:02:43] so do people have specific questions. It looks like with the recent comments on the ticket it might be worth discussing the privacy implications. [07:03:44] should we talk about what/why or is everyone clear about that? I guess it's kinda self-explanatory [07:04:03] what's our main privacy concerns other than 'some of your data might be accessible to the third party service'? [07:04:07] <_joe_> tgr: it seems pretty clear to me and I commend the idea of integrating [07:04:38] <_joe_> brion: well, not only that, but also at which times you logged in [07:04:46] *nod* yeah [07:04:47] <_joe_> not sure if that would leak your IP too [07:05:14] oauth login i think would, if it sends you to their login page [07:05:21] <_joe_> so my main point is - does this collide with the stated privacy policy we have? [07:05:24] <_joe_> brion: right [07:05:38] but that's a known point of interaction that i think can be fairly well labeled as "off-site service involved" [07:05:40] <_joe_> this is a question for legal, though, hardly for tgr :) [07:05:43] probably the biggest privacy concern IMO is that MediaWiki has public user creation logs down to the second, so it's not completely unrealistic for an eavesdropper to connect usernames to traffic patterns (and thus IPs) [07:06:07] <_joe_> tgr: from a technical PoV that's basically it, I agree [07:06:09] I would be worried about this for a content wiki; I don't think mediawiki.org is much of a target [07:06:20] (perhaps our SUL local user creation-on-visit hack should be reconsidered ;)) [07:06:44] tgr: my main concern is i'm not sure we cna really separate mediawiki.org from en.wikipedia.org etc for this purpose [07:06:54] so there would be a "log in with github" button on the login form, presumably if you don't click on it, there won't be any requests to github.com? [07:07:01] <_joe_> uh sorry, maybe I misunderstood - is this for SUL users? [07:07:06] <_joe_> TimStarling: I would assume so [07:07:10] mediawiki.org has SUL [07:07:18] well, we don't want to create a separate class of users [07:07:21] so yeah [07:07:39] you'd only be able to use it on mw.org but it would log you in globally [07:08:01] to me that'd be weird and confusing if/when i ran into it [07:08:12] like when jumping from docs on mediawiki.org to docs on commons or meta [07:08:27] if i couldn't log back in? [07:08:34] <_joe_> tgr: will the usernames be namespaced somehow? I'm thinking simply of collisions [07:08:53] maybe better than showing the "log in with github" link to all wikipedia users [07:08:57] hehe [07:09:06] that'd be politically... interesting to get through [07:09:09] so the exact way this would work, there would be a github button (which does not load any remote content) [07:09:23] if you click it, you are sent to github's oauth dialog [07:09:41] *nod* sounds sensible [07:09:44] maybe it opens in a popup, if we prefer, anyway, the browser goes to their domain [07:10:26] if this is your first time, you need to signal your permission to github about mediawiki.org accessing your identity (and we probably want the email as well) [07:10:51] then the user is sent back, there is an oauth handshake, we get the user's github ID (and email) [07:11:15] if we have that ID in our records we look up the user account and it's logged in [07:11:44] <_joe_> ok say my github username is "iamninja42", and that is already a SUL username. What happens when I try to auth with github for the first time? [07:11:53] if we don't have it, we show a dialog where you can enter a usernam [07:11:58] <_joe_> ok :) [07:12:09] in theory we could try to auto-assign usernames. IMO not a good idea. [07:12:20] <_joe_> exactly my point, go on sorry [07:12:45] (would be nice to go back in time 15 years and make mediawiki use emails as the primary user ID...) [07:13:10] would they set a password? [07:13:25] :D [07:13:41] so you can either enter a username (with AJAX check for freeness) and create a new account, or do a normal login and attach the github account to the existing account you have logged into [07:14:05] exact UI is TBD, I never managed to finish this part of AuthManager (the backend is there) [07:14:18] we can ask for a password if we want [07:14:24] that's one option [07:15:00] the other is to get the email address from github, and then they can request a password reset with that [07:15:40] the third is to get neither password nor email -> if we need to disable github login for some reason all those users are locked out permanently [07:15:47] ...which is probably not a good idea [07:15:55] <_joe_> I was about to ask [07:16:01] <_joe_> what do we do in that case? [07:16:05] yeah that's the scenario we want to avoid :D [07:16:23] (the drawback of asking emails is that AIUI that's an extra step on the github oauth dialog. Still the best option IMO.) [07:16:25] <_joe_> in case a user has set no password and unlinks from their github account? [07:16:38] <_joe_> also, say they change their email in github, how do we sync it? [07:16:43] If we ask for pass/email whats the point of github login? [07:16:44] they'd have to do a password reset via email [07:16:58] maybe we should do our own email authentication, not rely on github for that [07:17:18] we don't ask for email, we get that from github [07:17:40] we'd be able to re-query it if we want, not sure if it is worth the effort [07:17:57] users can always lock themselves out if they really want, password or no password [07:18:29] bawolff: yeah I don't think it makes much sense to ask for a password, I was just describing the possible options [07:18:37] Ok [07:18:49] there are some benefits to an external provider beyond passwords, though [07:18:50] yeah but in the hypothetical future where github disappears or turns evil, we may have a lot of users in the situation of having an invalid email address and no password [07:19:46] I imagine active users would keep their email up-to-date [07:19:49] and note that email authentication is an anti-spam measure, if you can somehow make github return an unconfirmed email address, you can send spam to that address [07:20:25] ok [07:20:32] it is pragmatic at least [07:20:52] yeah, most of the benefits depend on being able to trust that the external provider does a decent job vetting accounts (email validation, but also rate limiting etc) [07:20:56] we are assuming this is mostly for casual users anyway [07:21:22] if we can assume that, which for github seems reasonable, we can skip a bunch of annoying checks on our side [07:21:56] captcha, throttling (think mass subscriptions at an IRL event), autoconfirmed flag, email confirmation... [07:21:56] There's risk there that ext provider has different goals then us or their goals change in future [07:23:00] presumably if github is replaced with a spam factory we can shut off further account creation [07:23:10] wrt email changes, if get oauth permission for seeing the users email address, that means we can look it up any time, not just during login (I believe) [07:23:39] so if we want we can keep it up to date (assuming they keep it up to date on github), not sure if it is worth the effort [07:24:11] the other thing we can do is to ask users to set a password after a certain level of activity [07:24:24] progressive account onboarding :D [07:24:27] that's actually a nice idea [07:25:00] (like those "please review your security settings" emails every other website is sending all the time, there is a phab task somewhere about doing that) [07:25:32] something we might want to for normal logins as well btw, only with email instead of password [07:25:51] not having email addresses creates all sorts of problems [07:26:16] but this is for active users. I don't think we need to worry about mostly inactive users getting locked out [07:26:47] (although one complication there is we use SUL for a bunch of external things, like Phabricator login, so defining inactive is not trivial) [07:27:58] security-wise, it would be nice to be able to track what login method a session originated from, and that does not seem like an easy change [07:28:28] but a poor man's workaround would be to just audit-log external logins [07:28:40] (and hope no one waits for 60 days before abusing) [07:29:31] Im concerned about the political ramifications of doing this [07:29:33] there are the usualy considerations, like notifying existing users when an external account is connected [07:29:58] <_joe_> bawolff: like what? [07:30:04] If it was just mw.org that'd be one thing. But this is sul with all the wikis included [07:30:13] like the fact that we are favouring github over everything else? [07:30:19] political as in surveillance? [07:30:40] Political as in will enwiki get mad they didnt have a say [07:30:56] i just think you'll get a lot of pushback about supporting a single company as exclusive login provider, even if it's expressed as a practical work step [07:31:00] *nod* [07:31:25] in theory I'd love to support everyone with decent security practices [07:31:25] <_joe_> sorry, I'm not sure I get it, wasn't it supposed to be limited to logging in on mw.org? [07:31:34] Itd seem less risky to start with wikitech if we want to go down this road [07:31:39] in practice I don't think you can make a workable UI that way [07:31:42] <_joe_> but it would still be a sul account [07:31:49] <_joe_> yeah, I do see it now [07:31:59] <_joe_> and yes, I think those are pretty relevant too [07:32:16] <_joe_> I mean, I assume facebook, amazon and google do a great job at protecting their accounts too [07:32:47] <_joe_> I'm more worried about not being able to say no to a "login with X" request in the future [07:32:48] I would like to see google login on content wikis some time in the future [07:32:51] Well if you really want to see politics, try suggesting fb at enwiki ;) [07:33:00] probably not enwiki since I don't think they would agree [07:33:01] <_joe_> tgr: I would absolutely NOT [07:33:18] <_joe_> I would oppose such a thing if not limited to a single oddball like mw.org [07:33:24] an alternative might be to look at github as an alt login provider for phab & gerrit specifically [07:33:28] sidestep the wiki :) [07:33:33] but emerging wikis where there's more need to grow the community [07:33:35] <_joe_> notwithstanding the fact that any such integration needs vetting by legal first [07:33:47] it's an interesting view of privacy [07:33:49] <_joe_> brion: that would be more acceptable [07:33:55] privacy versus abuse control [07:34:17] in the future we can throttle down direct account creations with impossible captchas, IP range throttling, etc. [07:34:34] and everyone can log in using their government OpenID provider [07:35:12] e.g. in China we could request everyone's name, address and social credit score before allowing them to edit [07:35:21] <_joe_> so, there is one huge privacy implication in all this [07:35:30] <_joe_> and tim is skimming its surface [07:35:41] <_joe_> but I'm not sure I can get into the details in a public forum [07:35:59] <_joe_> and also, it's not what the techcom can help with, frankly [07:36:08] #mediawiki_security? [07:36:13] The phab login is already super confusing with 2 login types [07:36:28] can people who log in using github be added to an implicite group? that way, enwiki etc can impose restrictions, such as treating them as unconfirmed forevery or something [07:36:30] I guess 3 doesnt make it worse [07:36:39] I think we really should move towards having a single user identity [07:36:49] But it is a warning for ui issues with multi logins [07:36:52] Phab should make LDAP logins much less prominent [07:37:11] (and eventually Wikitech will be SUL and then we can just kill them) [07:37:26] gerrit etc. should also use SUL [07:37:49] ...to rephrase: would an implicit user group elivate the politics involved with github users showing up on enwiki? [07:37:50] although we might need some non-MediaWiki-based login service before we can reasonably do that [07:37:57] Phab & gerrit are the places where github login makes the most sense [07:38:03] Imo [07:38:24] duesen: I'd like an implicit group, yes [07:38:46] mainly to get around the oauth autoconfirmed limitation on meta [07:38:55] duesen: i think lots of the polotics would primarily be about enwiki feeling unconsulted [07:38:57] the wiki page https://www.mediawiki.org/wiki/User:Tgr_(WMF)/external_login says that one of the reasons for doing this would be for editathons [07:38:58] <_joe_> tgr: wrote there [07:39:20] so you would be telling new editors to log in with their google account or sorry wait until after the event is over [07:39:37] bawolff: phab is where it makes most sense, for sure. mw.org help pages probably make second most sense. gerrit IMO is so hard it does not matter much. [07:40:07] <_joe_> (LDAP logins aren't going away soon, but there is some work on that front going on in SRE foundations, I'd reach out to them if you have plans in that area) [07:40:07] at some point I hope we'll have a SUL-based chat system as well (see T186061) [07:40:09] T186061: Evaluate Matrix / Riot.im - https://phabricator.wikimedia.org/T186061 [07:40:56] TimStarling: I guess [07:41:17] basically it's a way to outsource spam control, which we really suck at [07:41:27] <_joe_> by giving away user's privacy [07:41:38] I dont see how [07:41:46] <_joe_> and our guarantees about the protection of their edits [07:41:50] Unless we only allow github logins [07:42:09] <_joe_> bawolff: a third party can associate ip and time at which you've logged in at some point in time [07:42:19] <_joe_> in most countries that's enough to legally identify you [07:42:29] I mean outsource spam control [07:43:02] If github is optional and harder to spam then spammers just wont use it [07:43:14] <_joe_> bawolff: no spam control solution I know of works without knowing the origin's IP address [07:43:29] <_joe_> bawolff: well, apart one I wrote for a privacy-oriented blogging platform back in the day [07:43:53] as long as github is optional, there is no privacy problem, but as soon as you have a captcha for direct logins that is not there for external logins, it stops being optional for some people [07:44:25] or an IP throttle for direct logins that is skipped for external logins [07:44:26] Maybe i misunderstand how this relates to spam control? [07:44:30] <_joe_> TimStarling: even if it's optional, it will allow a third party to uniquely identify a user [07:45:03] **** 15 minutes left **** [07:45:06] <_joe_> potentially forever. The legal ramifications of this are serious, and I don't think there is a point in progressing this discussion without advice from legal [07:45:20] I'm not so concerned if there is consent, but... what's the GDPR term for bundling consent? [07:45:52] if you have to consent to give up private information in order to get a service which does not strictly require the information, that is a GDPR issue [07:46:03] legally, I'd guess that a "log in with Github" button makes it obvious that Github will see your IP [07:46:20] we should add a help link somewhere, of course [07:46:34] might be a good point to either summarize or add questions to be answered later to the minutes [07:47:48] I honestly think this needs a meta community rfc to progress. I think its beyond techcom scope to decide this for all sul wikis [07:47:59] I guess the conclusion is that it requires legal review? [07:48:16] #info since login is unified, this would allow people to log into e.g. enwiki (although not *on* enwiki) via github. Do the content wikis need to be consulted? [07:48:36] techcom may have a veto power on this for various reasons, but yes, there are considerations outside our realm of expertise [07:48:57] <_joe_> bawolff: +1 [07:49:03] sounds about right [07:49:04] <_joe_> I think that's needed as well [07:49:19] on the bits that are our realm of expertise, maybe we're OK with it? [07:49:29] <_joe_> I don't see the technical shortcoming as insurmountable, no [07:49:41] I have an aversion to movement-wide rfcs because we don't have a sane decisionmaking process [07:49:50] it's basically whoever canvasses hardest [07:49:54] <_joe_> tgr: still, this is widely impacting [07:50:12] tgr: like in real life that way [07:50:15] last time we tried it was the MP4 rfc, and that was basically decided by people going to slashdot [07:50:20] (sadly true) [07:50:52] i don't know how to make this decision _right_ but i do feel that techcom can't approve it alone [07:51:02] in real life you have governments for that kind of thing [07:51:23] unless it can be narrowed dramatically to tech spaces only (phab/gerrit) which i know you'd prefer to go the other way moving them towards using sul [07:51:34] <_joe_> I think it's a given we need a - legal review b - a community wide discussion if this will allow people to log in via github and then edit other wikis [07:51:55] I think a community-wide *discussion* is probably a good thing [07:51:59] <_joe_> regarding how to unify tech spaces login [07:52:13] <_joe_> there are other people that might have other plans in the org [07:52:18] I think there were issues with management of mp4 rfc. Usually canvassing at slashdot does not have much effect on community discussions [07:52:27] <_joe_> and I think they're not thinking of using SUL logins, for good reasons [07:52:32] <_joe_> but I might be wrong. [07:52:48] but how to handle rfcs that are not specific to one wiki community is something we don't really have good norms around [07:53:33] well, if there are conflicting plans, figuring that out should be in scope of the rfc process [07:53:34] Also there is a difference between legal review = wont go to jail and privacy review by legal = this is inline with our principles [07:53:44] are there people who should be informed? [07:53:58] I certainly didn't put much effort into advertising this [07:54:12] <_joe_> let me put it this way: if I was part of community Y, and some other part of the larger community X we're part of did impose on us to accept github as an external auth provider, I'd be enraged. [07:54:24] <_joe_> bawolff: I was thinking about privacy review, yes [07:54:40] <_joe_> where github == any external auth provider [07:54:57] I guess I fail to see the privacy angle [07:55:00] <_joe_> I would request for our community to have the ability to opt-out of that [07:55:06] I know Tony Sebro at least is very interested in user privacy issues beyond the legal minimum [07:55:20] the user doing the login is certainly affected [07:55:27] I dont mean to suggest that legal isnt [07:55:30] the optout for that is obvious [07:55:39] **** 5 minutes left **** [07:55:55] I don't see how my privacy would be affected by someone else using external auth [07:55:59] tgr might you be able to summarize the discussion on ticket since we didn't do so well with the minutes? [07:56:08] or quickly tag things in the next couple minutes [07:56:12] yeah I'll do that on the task tomorrow [07:56:21] perfect, thank you [07:56:23] Just that they are two different questions and its important to not conflate them [07:56:54] <_joe_> not your, but the privacy we guarantee to our users, and you can't blame the user for not seeing how logging in with an external auth provider might compromise our privacy policies [07:58:58] _joe_: in general I think we should focus on weakest links. This would definitely not be a privacy issue that's worse than MediaWiki's level of privacy in general [07:59:11] 1 more minute left [07:59:30] (your IP is public forever if you accidentally forget to log in, all logs are public so it's easy to identify you by traffic analysis etc) [07:59:40] <_joe_> tgr: IANAL, but I disagree. Anyways, this needs a legal opinion. [08:00:07] thanks everyone who joined [08:00:10] I don't think it's legally interesting (which is bawolff's point, privacy is largely not a legal issue) [08:00:43] it needs a legal review, but I imagine that would be mainly around whether we need to change some document somewhere [08:00:56] it needs a privacy review, which is the more interesting part [08:01:10] #endmeeting [08:01:10] Meeting ended Thu Feb 14 08:01:10 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [08:01:11] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.2019-02-14-07.00.html [08:01:11] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.2019-02-14-07.00.txt [08:01:11] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.2019-02-14-07.00.wiki [08:01:11] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.2019-02-14-07.00.log.html [08:01:23] as a last word, anyone has ideas who else should be consulted/notified about this? [08:01:39] beyond legal I mean, putting the community angle aside for now [08:02:03] if you do please mention it in the task :) [08:02:10] thanks all for participating! [08:06:35] tgr: we :-p [08:06:50] well we are probably 'community angle' tho [08:07:06] revi: as in, stewards? [08:07:09] yup [08:07:24] what's the best way for that? email? is there a phab tag? [08:08:14] send email to stewards-l@lists.wikimedia.org using your @wikimedia.org [08:08:56] no personal mails since it will be rejected [08:09:59] my personal feeling is basically 'as long as it respects local block rules (ie. autoblock, titleblacklist, etc etc) it should be fine' tho [08:13:37] mediawiki.org block rules would prevent login/signup I believe [08:14:08] others would prevent account autocreation on that wiki, as it works in other situations where you log in on wiki A and then go to wiki B