Reading this thread and thinking about the proposed changes, im getting stuck, and there may be some inconsistencies. The problems identified seem to be
1. Core development is made much harder because of an abundance in local differences in wikis caused by local js and css.
2. Local wikis security may be compromised by lack of formalised structured code review of local js and css. (by staff/core developers?)
The former seems to be generally acknowledged, and a large problem, the latter more or less debated, and a smaller problem (is that correct)
Fixing 1 pretty much seems unfixable apart from completely banning local js altogether, which is something we don't want to do. Most of the solutions proposed as a compromise focus on fixing 2 by use of code review tools and standards, while still using 1 as a reason, though it actually does nothing to fix it.
Is 2 still big enough of a problem to be fixed? If so, what does it need most? A more structured approach? More staffers reviewing gadgets? The use of the same tooling core uses?
To me it seems more people doing review is a good thing, but are there enough resources for that? "There should be more review" more or less implies that that should be done by people who have +2 in core right now. I'm not sure if that is indeed the way to read former posts, but if it is, that is probably a bad idea. Apart from the additional workload that would cause - in this scenario I imagine loads and loads of patches waiting for review - it again moves the responsibility for maintaining a local wiki to a centralized body, which is bad for the local community.
Alternatively, if we want other people to do the code review (e.g. local admins), shouldn't we be asking them what tools they need, if any, to effectively review and deploy patches, rather than centrally decide it for them? If we do ask them, I sincerely doubt their answer will be git and gerrit.
As far as centralized gadgets go, lets not worry too much about those until the infrastructure for them actually exists.
On Dec 12, 2013 8:58 AM, "Chad" innocentkiller@gmail.com wrote:
+1 to everything MZM said.
Except the XSS in user/site/gadget JS vs core/extension XSS. Intuition tells me the former is much more common. We just think about
core/extension
XSS because it gets a security release and tons of attention.
-Chad
On Dec 11, 2013 8:01 PM, "MZMcBride" z@mzmcbride.com wrote:
Bartosz Dziewoński wrote:
I really liked what Jon said at the beginning, and what has apparently been lost in the discussions already – "Keep gadgets for experiment,
but
ensure global gadgets are held to a higher standard of quality and made more visible to a wider audience.". Proper global gadgets still don't exist, but when they finally happen, experienced coders who do this
for a
living should take them under their wings (to clean up existing code,
to
check new contributions – but a "post-merge" code-review might still be more appropriate); but local gadgets should stay the safe haven of innovation they are now.
Yep. We should obviously find ways to improve performance and reduce unnecessary code. Global (Wikimedia-wide) gadgets would be a good
approach
to take. Converting successful JavaScript gadgets into PHP MediaWiki extensions would be another good approach to take. There are others.
The idea being proposed in bug 58236, as it was framed, was a
non-starter.
It simply riled people up and caused them to become defensive. (Its sibling bugs didn't help.) However, if we re-frame the issue, I think
many
people would agree that if there's a desire to enable a gadget for _all_ users, whatever functionality that is being provided by that gadget probably ought to be integrated into a MediaWiki extension.
Brian Wolff wrote:
Submitting patches is not the problem. Getting them reviewed in a timely fashion is a problem. Having power taken out of local wikis hands is a problem.
Yep.
Brian Wolff also wrote:
I also think it would be unenforcable unless one plans to ban personal js in all forms.
Quite: if you ban site-wide JavaScript (Common.js, Monobook.js, gadgets, etc.), people will simply revert to using per-user JavaScript (i.e., User:Foo/script.js) and importScript(), as they did for years.
Tyler Romeo wrote:
I'll be frank. I don't really care. If power is really the issue, then
let
people from the wikis have +2 on their wiki's Gerrit project.
Currently you already have a +1/+2 model on the wiki. Any user can +1 while any local administrator can +2.
Tyler Romeo also wrote:
If the cost of increasing site-wide security and alleviating
developers'
pain is a few upset users who will get over it in a month or two, then
so
be it.
With respect, your posts exhibit hints that you have not been a
community
member of a Wikimedia wiki, though perhaps I'm mistaken. I find it much easier to agree with Bartosz and Brian than with you. It's very
important
that wikis have sovereignty and freedom to experiment.
Daniel Friesen wrote:
Bartosz Dziewoński wrote:
And it's not very easy to cause a major security bug when writing code that runs client-side and usually only in response to user action. Most gadgets don't, say, parse untrusted input from *other* users.
That's not always true. There are a variety of scenarios where a Gadget author may do something relatively common and innocent, and through a bad practice mistake could inadvertently introduce a gaping XSS vector that could be used to attack any user for whom said gadget is merely enabled.
While it's probably impossible to accurately measure, anecdotal evidence suggests that XSS vulnerabilities are far more common in MediaWiki core and its extensions and than in JavaScript gadgets. :-)
Jon Robson wrote:
I'd love us to get into a situation where Gadgets continue to be a platform for innovation but community and developers work hard to
mature
these gadgets into performant, test protected beasts that live in a single code repository. I do feel at times that we treat our users like dirt in terms of their experience...
Further anecdotal evidence: I hear a lot of users complain about
MediaWiki
extensions (UniversalLanguageSelector, ArticleFeedbackv5, FlaggedRevs)
and
even occasionally about MediaWiki core, all of which go through formal code review. I don't hear many complaints about JavaScript gadgets or
CSS.
In fact, in my experience certain actions (such as nominating a page for deletion) have become nearly impossible without the use of gadgets.
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l