Talk:Security for developers/Architecture

Failure to ensure that new or upgraded extensions function properly with other core extensions
It should be required that all upgraded or new extensions that permit the addition of content visible to the public operate with the revision deletion/suppression module, and that any actions related to content creation be included in the logs reported to checkusers - before installation on any non-testing project. This should be a mandatory criterion before installing, even as a test example, on any "real" project; failure to do this has resulted in extremely inappropriate content addition or difficulty for checkusers to identify and block vandals. AFT5 did not have this ability designed in, and required significant re-engineering to fix the problem; after that, a promise was made not to release future extensions on production wikis, even as tests, until the ability to revision delete/suppress and checkuser was demonstrated. Then Flow was released without the ability to checkuser contributions, or to revision delete/suppress. (Incidentally, the reverse is also true - any actions taken to revision delete/suppress any form of content addition needs to show up in the deletion and/or suppression logs.)

I am certain there are other core extensions with which anything new needs to be able to interact appropriately; these are the two I'm most familiar with, so I'm giving this example. Risker (talk) 01:22, 8 May 2014 (UTC)
 * I have copied and pasted this message from the talk page of the performance guidelines. Thank you, Risker! Sharihareswara (WMF) (talk) 15:00, 9 May 2014 (UTC)

A few thoughts/ideas
Chris, thank you so much for working on this. I look forward to working through the implementation/testing/continuing responsibilities sections when they are more fleshed out.

Some questions, thoughts, and ideas:

"What are we trying to protect?" Are there subcategories here? Also, what about: (I would not be surprised if none of those are applicable, but I want to bring them up.) Sharihareswara (WMF) (talk) 02:51, 16 May 2014 (UTC)
 * the fact that a particular IP address or username visited/read a page? (the specific way we keep this private is by not logging it?)
 * entire wikis? e.g., officewiki, Board wiki
 * integrity of the user experience? (like, around CSRF stuff or the insertion of ads?)

"assess your feature's security" - can we give an example or 2? Sharihareswara (WMF) (talk) 02:51, 16 May 2014 (UTC)

In the examples for "Secure design principles" it's fine to include examples *from the past* and say "we used to do this wrong and now we have fixed it." If you're having trouble finding examples of a few of those principles, that's one source. Sharihareswara (WMF) (talk) 02:51, 16 May 2014 (UTC)

In the "implementation" section I think it's fine to have "redemption narratives" :-) in which a particular bit of code used to do the wrong thing but now we have fixed it to do things properly. One source of examples: you could go through some security fixes from the last 3-4 years. Sharihareswara (WMF) (talk) 02:51, 16 May 2014 (UTC)