Chris, in what way was the list helpful? I am asking because it might give me a better idea of whom to share it with/ how to move on with it.
About access control I see the problem is not technical but rather cultural. Is this something that is under discussion in WMF or is it absolutely set that it's against WMF policy? Can it be brought up to discuss? If it's not for the "dogma" against access control I imagine some consensus can be reached with conversation.
*>> > 11. Update to the documentation about creating a simple extension that is
XSS safe.
* *This, however, I think I can make happen :)*
Make happen sounds great:) Do you need help? Anything I can do? ( I can't really help with the documentation itself but maybe I can help with something organizational).
Mariya
On Mon, Jan 28, 2013 at 8:15 PM, Chris Steipp csteipp@wikimedia.org wrote:
Maria, I found your list to be very helpful. Thanks for putting that together!
On Mon, Jan 28, 2013 at 8:26 AM, Yury Katkov katkov.juriy@gmail.com wrote:
Hi Maria! Let me clarify the situation about access control. There are several dozens of ways (!) to get the information of a wiki page - and that's only in the core! And what's about extensions? Each of them is responsible for access control by itself, therefore each of them provides another couple of ways to access any content you want. I'm pretty sure
that
now it's impossible to create a reliable (the one you can store your
credit
card number) Access Control extension without hacking and patching the
core
- and aftyer that some ways to get the data still remains. The WMF
position
here is the following: "if you need access control, if you want to hide some stuff from some groups of users - get out of here and choose another wiki engine." If you're asking us about our problems - here is one of the most depressing problem of all.
From my personal perspective (not speaking as a WMF representative), I don't think it would be too much work to support some level of access control in core-- at least standardizing how read access is checked, and then making sure it's checked for each read. Defining the granularity, making sure there's community consensus on it, and auditing extensions for compliance (and somehow marking those extensions as compliant) would take some work. But we already essentially do this for edit access ("blocked users should not be able to edit" is one of our access control policies, and we do a pretty good job of enforcing it throughout the code). Also, auditing access to make sure that policy is being followed would take some work, but is probably not insurmountable as an option in core or an extension.
However, making sure that all core and extension developers are on board with the same idea of what policy should be followed so that code from now on complies with whatever policy is chosen is going to take a lot of training, persuasion, and could even prevent new developers from getting involved if it's treated as more valuable than their contributions.
So I think it's totally possible, but it's not (in my mind at least) so much of a code or feature task as it is a culture and consensus of policy problem. Which I think is a much more difficult problem to solve, but I do hope I'm wrong about that.
- Update to the documentation about creating a simple extension
that is
XSS safe.
This, however, I think I can make happen :)
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l