Architecture meetings/Security guidelines discussion 2014-06-13

LINK:

15:01:56 <sumanah> #startmeeting Security guidelines | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours
15:01:56 <wm-labs-meetbot> Meeting started Fri Jun 13 15:01:56 2014 UTC and is due to finish in 60 minutes.  The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:56 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:56 <wm-labs-meetbot> The meeting name has been set to 'security_guidelines___channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours'
15:02:05 <sumanah> #chair sumanah csteipp
15:02:05 <wm-labs-meetbot> Current chairs: csteipp sumanah
15:02:11 <sumanah> Sorry for the late start, folks!
15:02:11 <csteipp> Thanks sumanah!
15:02:15 <sumanah> Sure csteipp
15:02:23 <sumanah> #link https://www.mediawiki.org/wiki/Security_for_developers/Architecture
15:02:49 <sumanah> so, first, raise your hand if you've read this in the last 2 weeks?
15:02:51 <sumanah> o/
15:02:58 <csteipp> o/
15:03:11 <zwol> o/
15:03:24 <sumanah> Hi zwol! great to see you!
15:03:35 * halfak clicks link
15:04:03 <parent5446> Unfortunately I haven't. :( I'll check out the updates now.
15:04:16 <sumanah> So first off, do people think this is overall going in the right direction, to help developers know how to design and write secure code?
15:04:17 <superm401> "IP address or UserAgent of editors" should be rephrased.
15:04:27 <sumanah> #action csteipp "IP address or UserAgent of editors" should be rephrased.
15:04:29 <sumanah> got it superm401
15:04:42 <csteipp> superm401: how so?
15:04:54 <superm401> csteipp, IP of logged out editors is not confidential.
15:05:08 <csteipp> Ah, yeah, good clarification :)
15:05:18 <csteipp> I'll step back and say,
15:05:46 <csteipp> I think this document has morphed into a little of "secure development process" as well as "best practice for security architecture"
15:05:53 <csteipp> I'm not sure if they should be split.
15:06:14 <csteipp> I don't want yet another thing for users to read, but if it seems too processy, I can split it out.
15:07:06 <csteipp> If anyone has feelings one or or the other, yell
15:07:16 <sumanah> (/me thinks
15:07:18 <sumanah> er
15:08:55 <sumanah> so csteipp it seems to me like https://www.mediawiki.org/wiki/Performance_guidelines ok, so I'm going to talk about whether the same model applies here
15:09:11 <zwol> This is kind of the obligatory thing for an academic security researcher to say, but I think there should be a section discussing the threat model.
15:09:21 <zwol> Who is the adversary, and what are they trying to accomplish?
15:09:33 <csteipp> zwol: You mean for MediaWiki as a whole?
15:09:57 <sumanah> BTW I perceive this guideline to be aimed at people writing code that will run on Wikimedia servers
15:09:58 <zwol> (This can wind up being just a perspective flip of the existing "What are we trying to protect" section, but it's valuable because people find it difficult to think from the adversary's perspective.)
15:09:58 <sumanah> primarily
15:10:14 <sumanah> with a secondary purpose of helping people writing code that will run in other MediaWiki installations
15:10:17 <zwol> (Especially, people often have a blind spot when it comes to realizing what the adversary can _do_)
15:10:20 <sumanah> and this includes core, extensions, gadgets, templates
15:10:29 <zwol> csteipp: this is pretty generic advice
15:10:45 <superm401> zwol, there are a lot of threat models I think ("people who want to spy on users", "people who want to vandalize the wiki", "people who want to do things without accountability"...)
15:10:45 <csteipp> zwol: I think that would be a good update
15:11:11 <parent5446> I mean, the threat model between Wikipedia and an intranet private wiki are going to be a lot different.
15:11:14 <zwol> superm401: yes but they're buried in the "what are we trying to protect" section
15:11:22 <csteipp> #action: Update "stuff we're trying to protect" to be more clear about the threat model
15:11:25 <sumanah> For comparison: the performance guidelines say "here are our performance principles and here are top-level guidelines on how to implement them (and NOT implement them), with brief explanations of good and bad examples. One of those guidelines is "follow the secure dev process, e.g., making this diagram." Really detailed stuff, such as HOW to make the diagram, should go in different pages IMO
15:11:40 <superm401> sumanah, Lua modules too.
15:11:49 <zwol> parent5446: that's kind of a mechanism-versus-policy issue from where i'm sitting
15:11:54 <sumanah> zwol: I think superm401 is saying that those adversaries *exist* not that they are described in the doc yet
15:12:12 <zwol> ...maybe i'm reading between the lines too much :)
15:12:46 <sumanah> Could be. :-)
15:12:58 <superm401> sumanah, correct, my point was there are a lot of threat models, not sure how useful it is to explicitly mention them all.  But it may be good to explicitly mention the biggies (either in a dedicated section or elsewhere).
15:13:41 <sumanah> btw folks Zack is an old pal of mine from my pre-Wikimedia days and I owe a bunch of my early FLOSS/engineering informal education to him :)
15:13:57 <sumanah> (Zack being zwol)
15:14:02 <csteipp> Yeah, exhaustive list is pretty much impossible... but we can certainly call out the major ones
15:14:21 <csteipp> zwol: Nice to meet you!
15:14:40 <superm401> Yep
15:14:50 <zwol> It may help to say that I'm the person who was talking about traffic analysis on wikitech-l last week.
15:14:55 <superm401> What does, "(neg) User identification" mean?  Is it saying our user identification is too complex?
15:14:59 <sumanah> zwol: you may already know the folks here from the list, but csteipp is Chris, our Security Engineer; parent5446 is Tyler, a volunteer & CS student; superm401 is Matt, who works as an engineer at WMF
15:15:22 <zwol> Thanks, Sumana.  I may or may not remember those names from the list :)
15:15:31 <csteipp> parent5446: And I do totally agree, wmf vs intranet wiki are very different, but I *think* intranet wiki will mostly be a subset of big public.. but are there any specific threats to the intranet wiki scenario you're thinking of?
15:16:54 <superm401> Alright if I add wgEnableUploads (default false) as another example of fail-safe defaults?
15:17:02 <csteipp> I don't spend a ton of time thinking about non-public wikis, so I could totally be missing a threat model.
15:17:15 <sumanah> superm401: btw I would love from you an answer to my early question -  do people think this is overall going in the right direction, to help developers know how to design and write secure code? I know you see problems but I wanted to check whether you overall are liking this
15:17:34 <parent5446> csteipp: The primary consideration is that confidentiality of content is a more important factor in a private wiki, whereas a public wiki prioritizes integrity.
15:17:41 <superm401> sumanah, sorry, the reason I didn't answer that is that I'm reading during the meeting for the first time, but it looks very good so far.
15:18:12 <sumanah> :) thanks superm401
15:18:16 <superm401> csteipp, also, confidentiality of users.
15:18:44 <csteipp> parent5446: cool. That probably is a good distinction to call out, based on our history of assuming everything is public.
15:18:53 * sumanah agrees
15:19:18 <csteipp> #action threat models should call out private wikis-- where confidentiality is more important than integrity, vs. public wikis.
15:19:53 <zwol> concur
15:20:38 <phuedx> sumanah, superm401: seconded. i've enjoyed reading it
15:21:07 <sumanah> Thanks, that's great, phuedx! Was there anything in particular you either learned, or liked how Chris phrased maybe?
15:22:21 <csteipp> Btw, on the security principles section, I recently read, "I�ve learned that preaching about security principles, �economy of mechanism� and �complete mediation� and �least common mechanism� (and whatever else Saltzer and Schroeder talked about 40 years ago) and publishing manifestos are a waste of time. There�s nothing actionable; nothing that developers can see or use or test."
15:22:22 <phuedx> i was actually thinking that the sections could be reordered to: Threat Modelling, Implementation, Assess your feature's security, Security Testing
15:22:28 <csteipp> (https://blog.whitehatsec.com/easy-things-are-often-the-hardest-to-get-right-security-advice-from-a-development-manager/)
15:22:33 <csteipp> Agree/disagree?
15:22:46 <phuedx> which, in my head, is the way i'd go through the process of building a thing
15:23:32 <sumanah> csteipp: I'm gonna defer here to more experienced engineers, but I'm leaning towards agreeing with that author
15:23:33 <csteipp> phuedx: Yeah, that part is hard. I want to emphasize people should think about the threats before they build. But you're right, it's also after implementation.
15:24:11 <phuedx> csteipp: maybe: Thread Modelling, Assess your feature's security, Implementation, Validation/Security Testing?
15:24:54 <zwol> Oh, hey, yeah.  The "security testing" section deserves to be quite a bit longer.
15:25:10 <csteipp> phuedx: Yeah, validation is probably a good way to put it.
15:25:15 <sumanah> phuedx: csteipp - maybe there's some kind of milestone or ritual we can tie this to in our Agile Nimble world ;-) -- how do we integrate this into the rhythm of a team's iterations?
15:25:26 <superm401> I find things like https://www.owasp.org/index.php/Top_10_2013-Top_10 (security issues that are specific, but not too specific, and keep coming back) helpful.
15:25:50 <zwol> And it's a bit buzzwordese right now.  Someone in a QA mindset might not realize that "positive and negative tests should be used" entails "obsessively test the code's response to *invalid* input, because the adversary can send in whatever the heck it feels like".
15:25:54 <phuedx> sumanah: to answer your question: in particular: STRIDE/MITRE's CAPEC list (that's /awesome/), and that section on psychological acceptability was really nice
15:25:55 <parent5446> So keep in mind every software process follows the process of Requirements -> Design -> Implementation -> Testing. During requirements is when threat modeling should be done. In design, it should be made explicit what security features are put into the feature. Then during testing, security testing should be done.
15:25:58 <phuedx> there's probably more ;)
15:26:00 <superm401> I think things like "least common mechanism" (need to learn what this is) are useful to, but to a different audience.
15:26:14 <sumanah> parent5446: *every*?
15:26:15 <phuedx> s/probably/definitely/
15:26:35 <zwol> I like the "all input is evil unless proven otherwise" formulation in that article
15:26:44 <csteipp> And yeah, "Security Testing" needs a fair amount more. Mostly because that is where we spend the least amount of time in our process currently (sad but true).
15:26:58 <parent5446> sumanah: Yes. Even if you're following an agile development process, software features still do have requirements, and still need to be designed before they are implemented.
15:27:16 <parent5446> The difference is just in what order you do things and how often you do each phase.
15:27:27 <parent5446> Of course it's a bit more complicated, but that's the general idea.
15:27:36 <phuedx> sumanah: i think including security requirements (gathered during the assessment phase) should be part of the ticket
15:27:37 <sumanah> parent5446: OK, glad to see you're backing off a bit :)
15:28:02 <parent5446> sumanah: Yeah, trust me, I've worked with waterfall before. It's not the greatest. :P
15:28:03 <phuedx> that way a feature couldn't be complete until those requirements are satisfied
15:28:22 <sumanah> parent5446: I don't need to trust you. I've spent more years in the tech industry than you have. ;-)
15:28:45 <superm401> Yeah, security basically needs to be baked in at every phase.
15:28:53 <parent5446> Lol good point
15:29:04 <csteipp> phuedx: Yeah, I was thinking about adding a section on that.. Non-functional requirements, or something along those lines.
15:29:12 <sumanah> zwol: (on the matter of prose: I've been fighting some other developers who want to put passive voice into guidelines and make things generally more "official-sounding". Argh.)
15:29:20 <superm401> From user-facing requirements (i.e. "assess whether this feature is a good idea", high-level security) all the way down to XSS prevention while implementing.
15:29:50 <csteipp> superm401: That's exactly what I'm trying to do :)
15:30:18 <zwol> sumanah: 'Official-sounding prose makes you sound more authoritative but also more boring, you risk people not paying attention'?   /table for later
15:30:19 <sumanah> phuedx: part of the Trello/BZ/etc. ticket?
15:30:28 <csteipp> superm401: One thing I was trying to do with this document is to convey that, without making a developer feel overwhelmed, and give up.
15:30:31 <sumanah> (Mingle/Phabricator/etc.)
15:30:32 <phuedx> sumanah: yeah
15:30:34 <sumanah> nod
15:30:39 <phuedx> all of 'em
15:30:46 <zwol> Here's something else that's not covered.  I don't see exactly where to fit it in, though:
15:31:08 <zwol> Interaction of security requirements with other requirements (e.g. usability, performance, features)
15:31:16 <sumanah> #idea Sam Smith suggests: i think including security requirements (gathered during the assessment phase) should be part of the [Trello/Mingle/Phabricator/Bugzilla] ticket
15:31:43 <sumanah> right
15:31:55 <zwol> Sometimes they go hand in hand and sometimes they conflict.  And a system that's super-secure but unusable ... won't get used.
15:32:04 <sumanah> YES
15:32:26 <csteipp> phuedx: Thanks. On platform, we don't do trello, I'd definitely love to hear ideas on how your teams could do that..
15:32:52 <superm401> Do what?
15:33:11 <zwol> (Reliability is kind of an exception -- I have yet to see a case where improving security hurt reliability or vice versa.  Some people encourage developers to think of security as a special case of reliability, in fact.)
15:33:32 <csteipp> superm401: Make gather requirements in the requirements phase integrate with your teams process
15:34:05 <mutante> let's say you changed the SSL cipher settings to have better security but it would exclude all IE users
15:34:15 <mutante> would that be an example of security hurt reliability?
15:34:35 <zwol> mutante: I'd characterize that as security hurting usability, but not affecting reliability.
15:34:39 <mutante> or is it availability
15:34:43 <zwol> mutante: That's a great example, though.
15:34:44 <mutante> ok
15:35:01 <sumanah> So I want to remind people that we do have some additional pages right now - https://www.mediawiki.org/wiki/Security_checklist_for_developers and https://www.mediawiki.org/wiki/MSG help you see them - in case some things from the current guidelines ought to be split off onto those
15:35:03 <zwol> mutante: Ideally what you do in that circumstance is find a way to offer the weaker ciphers only to IE users
15:35:10 <superm401> csteipp, we tend to work by creating Trello cards, sometimes breaking them down, and using meetings with video calls and Etherpad (copied to MediaWiki.org after the meeting).
15:35:29 <zwol> and then put a banner on the page saying "hey, your browser is forcing us to use weak security"
15:35:36 <superm401> MSG => MediaWiki Security Guide
15:35:40 <zwol> ... but sometimes that's just plain impossible.
15:36:04 <sumanah> mutante: btw would you characterise yourself as someone who can speak to the needs of non-WMF MediaWiki installations as well? we need to be thinking about their threat models as well, as parent5446 pointed out
15:36:40 <superm401> #action "For a long time, MediaWiki" needs to be more specific
15:36:48 <csteipp> zwol: I think a section like that does need to be in there. I want to think that all the way through. I personally like to take the optimistic approach that security is an enabler, but I know there is a conflict often. And it needs to get resolved at the correct level.
15:37:04 <mutante> sumanah: hmm, spontaneous thought is "it's maybe not so much WMF vs. non-WMF wiki but it is 'private' wiki vs. public wiki"
15:37:15 <greg-g> (yes)
15:37:18 <sumanah> oh right. Because we do have a 1 or 2 private wikis too!
15:37:18 <mutante> so a private wiki (which mediawiki was never really made for) also wants to hide content
15:37:28 <mutante> true, office wiki
15:37:30 <csteipp> #action Section about conflict between security and other requirements, and thoughts on where to address those in the process
15:37:35 <mutante> we don't want people to read that
15:37:40 <sumanah> nod
15:38:13 <sumanah> hey greg-g - sorry I didn't catch what you were saying yes to?
15:38:36 <phuedx> csteipp:i think it could be made as simple as: whenever a new card/ticket/thing is created with a user story and a requirements section simply add a distinct "Security requirements" section to it
15:39:03 <greg-g> private vs public wiki instead of non-wmf vs wmf, I didn't want to interrupt, mostly ignoring and trusting ya'll+chris :)
15:39:04 <phuedx> as a team you'd have to commit to giving the security requirements the same weight as the other requirements
15:39:06 <sumanah> zwol: greg-g is Greg, release manager at WMF; mutante is Daniel Zahn, an Operations engineer at WMF; phuedx is Sam Smith, who hacks MediaWiki for WMF
15:39:16 <mutante> every public wiki wants to do something against spam, sooner or later they activate captchas, if the captchas are broken (re-captcha f.e.) that's no good.
15:39:21 <phuedx> hullo o/
15:39:40 <phuedx> i'm on the growth team with superm401 and halfak
15:39:52 <zwol> captchas are pretty much broken in general, these days :-/
15:39:53 <phuedx> well, i guess, halfak's not "on" the growth team
15:39:55 <sumanah> greg-g: phuedx & mutante - zwol is Zack Weinberg, security researcher who has been helping us think about traffic analysis, HTTPS, etc on wikitech-l
15:39:57 <mutante> as opposed to WMF wikis they don't have an army of anti-vandalists and tools
15:40:11 <mutante> zwol: hi
15:40:15 <halfak> phuedx, :P
15:40:17 <csteipp> phuedx: that would be nice.. we can talk more later, but I'd actually love to try that out with a/your team and see what happens. If "n/a" just becomes the automatic response, or if it does provide a good constant reminder.
15:40:20 <phuedx> zwol: hullo
15:40:21 <zwol> Pleased to meet all of you :)
15:40:21 <halfak> I'm straddling
15:40:33 <mutante> zwol: i like to suggest Asirra
15:40:35 <phuedx> halfak: you're a master of bridging
15:41:11 * halfak waves at zwol
15:41:14 <sumanah> #idea bring up 'whenever a new card/ticket/thing is created with a user story and a requirements section simply add a distinct "Security requirements" section to it; as a team you'd have to commit to giving the security requirements the same weight as the other requirements' on https://lists.wikimedia.org/mailman/listinfo/teampractices ?
15:41:34 <phuedx> csteipp: i suspect that n/a might be a normal response
15:41:43 <parent5446> It'd be nice if Phabricator has some sort of security planning widget. I wonder if such an app exists.
15:41:48 <phuedx> but reminders are Good Things (TM)
15:41:54 <superm401> Yeah, I'm not sure if requiring it on every card is the right approach or not.
15:41:58 <sumanah> #idea <parent5446> It'd be nice if Phabricator has some sort of security planning widget. I wonder if such an app exists.
15:42:09 <sumanah> superm401: we don't need to decide that here & now - let's talk about it on teampractices maybe?
15:42:10 <superm401> But IETF RFCes do that, and it seems to work pretty well.
15:42:20 <zwol> mutante: It's an arms race.  Anything that gets used as a captcha, suddenly the black hats start pounding on that as a machine learning exercise.  I give "is this a cat or a dog?" two years.
15:42:20 <csteipp> phuedx: Yeah, at least there's a chance it will trigger action, vs the current :)
15:43:06 <sumanah> Should we have something about spam & captcha in the security doc? is that what I'm hearing? that one adversary is the spammer, and the threat model & prevention need to be covered?
15:43:15 <_joe_> I may introduce myself as well - I'm Giuseppe Lavagetto, operations engineer as mutante. I'm looking at the PFS implementation on ops side
15:43:25 <parent5446> Solution: just conduct the Turing test. If a WMF staff person thinks they're human, it's good enough.
15:43:34 <sumanah> "PFS" - Perfect Forward Secrecy for those who don't know :-)
15:43:34 <csteipp> mutante / zwol, did you see google's blog about how the captcha system is no longer about getting the right or wrong answer, but it's now a platform where they watch *how* the useragent interacts to determine spam/human?
15:43:43 <_joe_> sumanah: sorry, yes
15:43:57 <sumanah> no prob _joe_ - I am a pathological explainer, that's all ;-)
15:44:01 <phuedx> csteipp: link? that sounds interesting
15:44:05 <parent5446> Speaking of PFS, was that nginx patch merged yet?
15:44:16 <parent5446> Sorry, I'm going off-topic. Nevermind
15:44:21 <mutante> zwol: i think it has survived more than 2 years, but yea, remember when they talked about Google Labs making the self-learning machine cluster just by feeding it random images from the internet and first thing it learned was to recognize cats?:)  who knows, maybe even a hidden pun against Microsoft's captcha ? haha
15:44:24 <zwol> csteipp: Yeah, I saw that.  I'm sure that works great for them because they have dozens of people thinking about nothing else, and giant compute farms to back it up.  WM is not so fortunate...
15:44:56 <sumanah> hey zwol mutante csteipp - do we need to talk about CAPTCHA now or should we take that to the talkpage/another time? we have about 15 min left here and I wanted to ask people about giving us the examples we are missing
15:45:13 <csteipp> phuedx: http://googleonlinesecurity.blogspot.com/2013/10/recaptcha-just-got-easier-but-only-if.html
15:45:14 <zwol> sorry, it's an easy rabbit hole
15:45:17 <phuedx> ta
15:45:25 <mutante> sumanah: no, we don't need to talk about captcha now
15:45:28 <mutante> go ahead
15:45:30 <superm401> sumanah, it already has ConfirmEdit, which equals captcha
15:45:31 <sumanah> like, good & bad examples for https://www.mediawiki.org/wiki/Security_for_developers/Architecture#Secure_Design_Principles
15:45:32 <superm401> I say move on for now.
15:46:06 <csteipp> sumanah: I think at the architecture level, we need to stress integration with anti-spam. But the exact methods there are going to be very narrow, and probably not applicable to 99% of developers.
15:46:12 <sumanah> Nod nod nod
15:46:54 <sumanah> so, we need a past example of how Wikimedia (doesn't HAVE to be MediaWiki specifically) screwed up on "Secure (fail-safe) defaults"
15:46:56 <sumanah> for instance
15:47:05 <csteipp> And I actually need to leave in about 7 minutes, since I have to catch a 9:03 train :)
15:47:32 <sumanah> ah :)
15:47:39 <mutante> eh, we just had an example where the new Match captcha was used as a defualt
15:47:43 <mutante> the other day
15:47:49 <sumanah> can you link at all mutante?
15:48:34 <sumanah> We also need a positive example of how we have done "Simplicity"
15:49:25 <superm401> sumanah, kind of subjective.  Candidates:
15:49:35 <superm401> 1. One markup language (although it's certainly debatable if that one is simple).
15:49:48 <sumanah> superm401: hold on
15:49:59 <sumanah> superm401: I'm talking about simplicity *in security*
15:50:00 <csteipp> Also food for thought: If anyone has a project they would like to threat model, I'd love to do a real example and link from there.
15:50:21 <superm401> sumanah, I meant that, markup is security-relevant since the parse has to validate/sanitize.
15:50:24 <sumanah> at least, I am. Maybe I misunderstood Chris!
15:50:26 <sumanah> ohhhhhhhh
15:50:30 <mutante> sumanah: https://gerrit.wikimedia.org/r/#/c/138572/16/MathRenderer.php,cm
15:50:37 <sumanah> thanks for unpacking that superm401 :)
15:50:42 <superm401> No problem.
15:50:42 <parent5446> sumanah, do you mean simplicity in the implementation of security? or are you referring to an internal security module whose interface is simple?
15:50:50 <csteipp> Yeah, sanitization in our language is good... I'm not sure how simple it is :)
15:50:51 * sumanah defers to Chris
15:50:52 <mutante> see how the default is the MathMath ML
15:51:19 <superm401> 2. Pretty simple user-user email model (no formatting, email is shown to recipient so no reply proxying).
15:51:28 <sumanah> #action csteipp add https://gerrit.wikimedia.org/r/#/c/138572/16/MathRenderer.php,cm as a bad example of "Secure (fail-safe) defaults" - the new Match CAPTCHA was used as a default (per mutante)
15:51:29 <csteipp> parent5446: Preferably some place where the simplicity of a feature / internal mechanism / api has kept it secure in the long term.
15:51:30 <superm401> Or to simplicity in the feature, which reduces attack surface?
15:51:34 <parent5446> Because HTMLForm, while incredibly complex, has a relatively simple interface for security, i.e., built-in CSRF tokens and validation.
15:52:07 <zwol> I know of examples in the broader environment, but not within WP/WM
15:52:14 <sumanah> #info <csteipp> sumanah: I think at the architecture level, we need to stress integration with anti-spam. But the exact methods there are going to be very narrow, and probably not applicable to 99% of developers.
15:52:37 <zwol> e.g. the notoriously complicated OpenSSL programming interface .vs. djb's NaCl
15:52:40 <superm401> mutante, might want to take that offline, but don't see how that change connects to a CAPTCHA (although MathCaptcha uses that extension as one)
15:52:50 <sumanah> zwol: I may ask you for those if our local well runs dry. But my rationale is that the deep shared context of Wikimedia/MediaWiki will help developers grok these examples better and help them emotionally hit harder
15:52:59 <zwol> makes sense
15:53:13 <superm401> sumanah, we's always been pretty stingy on allowed file types, partly for security.
15:53:41 <mutante> superm401: it's not related to captchas, i was trying to find an example where the default value was causing issues for the site
15:53:55 <sumanah> #info "Minimize the attack surface" - we've always been pretty stingy on allowed file types, partly for security.
15:54:20 <superm401> May not want to put stingy in the actual doc, but yeah. :)
15:54:30 <csteipp> parent5446: I think I'm liking the htmlform example. That shows one side of the issue pretty well. I wish we had something else really simple, but I think we tend to complicate a lot of features :)
15:54:42 <sumanah> :-) CAREFUL. CAUTIOUS. SIDE-EYE.
15:55:04 <sumanah> ok, csteipp I want you to catch your train so maybe we can throw these questions to wikitech-l
15:55:16 <parent5446> Yeah, simple != MediaWiki
15:55:33 <csteipp> Alright folks, thanks for the help. sumanah, can you send me any further conversation? I should get  a bouncer one of these days..
15:55:39 <superm401> sumanah, https://www.mediawiki.org/wiki/Manual:$wgFileExtensions
15:55:54 <sumanah> sure will do csteipp
15:56:00 <mutante> example for least permissions, in the past we had our admins::restricted class also on hosts just needed for deployers, nowdays it just gives you bastion access
15:56:03 <mutante> cya
15:56:52 <sumanah> so "simple" may be Chris's translation of "economy of mechanism" which I will quote from the Saltzer paper
15:56:54 <sumanah> "Keep the design as simple and small as possible. This well-known principle applies to any aspect of a system, but it deserves emphasis for protection mechanisms for this reason: design and implementation errors that result in unwanted access paths will not be noticed during normal use (since normal use usually does not include attempts to exercise improper access paths)."
15:56:57 <sumanah> http://www.cs.virginia.edu/~evans/cs551/saltzer/
15:58:01 <sumanah> if that helps us get ideas about what we have done simply! HTMLForm and "only 1 markup language" seem like candidates
15:58:45 <sumanah> it could be that there are past good examples where we *did things right* and had a simple, secure design to *start* with, then mucked with things....
15:58:46 <superm401> Not sure how great "only 1 markup language" is now that I think about it.
15:58:51 <_joe_> sorry, I've got to leave as well - it's the end of the work day for me.
15:58:54 <sumanah> does anyone want to talk about "Secure and split"?
15:58:59 <zwol> closely related principle: in API design, the _easiest_, _most normal_ thing to do should also be the secure thing. Sometimes you need to allow people to do something unusual that is less secure, but then they should have to jump through extra hoops to demonstrate (to themselves and to future readers of the code) that they have thought about it and understand the implications.
15:59:04 <sumanah> I agree zwol
15:59:11 <sumanah> #info <zwol> closely related principle: in API design, the _easiest_, _most normal_ thing to do should also be the secure thing. Sometimes you need to allow people to do something unusual that is less secure, but then they should have to jump through extra hoops to demonstrate (to themselves and to future readers of the code) that they have thought about it and understand the implications.
15:59:31 <zwol> I can provide tons of external negative examples (starting with, of course, SQL injection...)
15:59:35 <sumanah> #link http://pyvideo.org/video/2647/designing-poetic-apis - the bit about building shoulders for the road is applicable here! http://www.slideshare.net/ErikRose/poetic-apis is the slides
15:59:35 <superm401> Counter-argument, if it's too common, people learn to jump through the hoops, and ignore them when it's actually dangerous.
15:59:50 <superm401> E.g. SSL certificate warnings (now people just click through three dialogs without a second thought).
15:59:51 <zwol> superm401: yes, you have to be sure you understand the use cases
15:59:52 <sumanah> superm401: um, how is that a counterargument?
16:00:26 <superm401> sumanah, because if they have to jump through the hoops for something mildly dangerous, they don't worry about jumping through them when it's really dangerous.
16:00:31 <zwol> I understand superm401 to be saying that if a case that you _think_ is unusual and should require hoop-jumping is in fact common, then all you've done is train people to jump through the hoops
16:00:31 <sumanah> anyway, it's noon here which means I'm gonna end the meeting - any last praise for Chris? ;-)
16:00:40 <sumanah> ah thanks zwol - that helps!
16:00:48 <zwol> and SSL cert warnings are a great example of that
16:00:48 <sumanah> yeah agreed
16:00:52 <sumanah> yuppppp
16:01:55 <superm401> You and csteipp (and the other contributors) have done a great job.
16:02:05 <superm401> Got to go.
16:02:13 <zwol> (and the related "if you ask users to make apparently-irrelevant decisions in the middle of task flow they will ignore everything you are telling them and smack the 'whatever' button" phenomenon)
16:02:13 <phuedx> thanks sumanah, csteipp
16:02:18 <phuedx> gotta go
16:04:41 <zwol> I'd like to leave everyone with some thoughts from a site called "The Codeless Code" that I find is really good at explaining this sort of thing (if you don't mind a bit of cartoonish violence every now and then):
16:05:02 * sumanah waits for this before ending the mtg
16:05:08 <zwol> http://thecodelesscode.com/case/148 <-- nominally about caching, but just substitute security and it's the same principle
16:05:30 <zwol> http://thecodelesscode.com/case/138 <-- why is computer so hard anyway?
16:05:43 <zwol> http://thecodelesscode.com/case/140 <-- "Code as if everyone is the thief."
16:05:48 <zwol> --
16:06:34 <parent5446> Love that site.
16:07:03 <sumanah> OK!
16:07:05 <sumanah> #endmeeting

Architecture meetings/Security guidelines discussion 2014-06-13

Text to review[edit]

Summary and logs[edit]

Meeting summary[edit]

Action items[edit]

Action items, by person[edit]

Full log[edit]