https://bugzilla.wikimedia.org/show_bug.cgi?id=57891

--- Comment #29 from Chris Steipp <cste...@wikimedia.org> ---
(In reply to Ori Livneh from comment #28)
> (In reply to Yuvi Panda from comment #26)
> > +1 to putting Global JS/CSS behind a flag, defaulting that to off,and
> > deploying this.
> 
> Could we simply remove this feature from the extension? It appears to have
> been tacked on as an afterthought, without a cohesive story about why and
> how it fits with the rest of the extension. (I contrast that with the
> primary functionality of the extension, which strikes me as a deliberate and
> practical solution for a well-defined problem.)
> 
> Hiding it behind a configuration variable does lower the stakes a lot, but
> it still plants a flag on this problem and adds another code artifact with
> which alternative solutions will have to contend.

On other non-wmf wiki farms, I can see this feature being very helpful. So I
think we should leave it in behind the feature flag. If having that means
shoutwiki/wikia/whomever will use it and help maintain the extension, I think
it's a positive addition and we (wmf) shouldn't block it.

Regarding the feature on general WMF-specific security, the only attacks it
would open up would be that meta admins would be able to attack wikis without
the other wiki's users actually visiting meta (where meta's site js can then
talk cross-domain to a wiki, and do whatever the admin wants). CN allows this
too, but provides a lot of additional controls to make sure it's correctly used
(timeouts, and targeting), and IIRC, campaigns can't be suppressed, whereas an
edit to the .js can later be suppressed to hide that it once ran.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to