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(a)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(a)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.
>
>
> >> > 11. 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(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>