On Tue, Jun 12, 2018 at 8:56 AM Federico Leva (Nemo) <nemow...@gmail.com>

> Personally I'd like us to explore agnostic and non-invasive solutions.

Mandatory code review (especially with a required waiting time) and
mandatory reauthentication are far more invasive than removing JS editing
permissions from administrators who don't want them.
That's not to say they shouldn't be done (again, most of the things we
could do are complimentary, and pretty much anything we could do we should
do, given the crazy levels of risk involved), but they require more nuance
and experimentation.

The subdivision of permissions across more user groups relies on a
> number of assumptions which may not hold. For instance, on thousands of
> MediaWiki wikis there's only one sysop anyway.

I presume you are talking about non-Wikimedia wikis here, as Wikimedia has
less then a thousand wikis (and about half of them seem to do basically
zero Javascript editing and so wouldn't be inconvenienced by not having any
permissions to do so and having to call in crosswiki helpers, like they do
for vandalism). For small MediaWiki installations this change offers little
extra defense but they are not particularly interesting attack targets in
the first place. For large non-Wikimedia wikis the change will be helpful
the same way it is for Wikimedia.

Something I would like is the ability to "have" a permission, but only
> "activate" it for limited periods of time when needed. The activation
> could require some extra steps (e.g. inserting the password again). It
> could be logged to Special:Log, which people can then monitor as they
> wish. A separate countermeasure (other than deflag) could inhibit it.

I agree reauthenticating before using more powerful or dangerous
permissions is something to look into, and there is ongoing work on that
front. But again the UX implications are nontrivial (what happens if the
timer runs out while you are editing the page?) and again there is no
reason not to do both.
Wikitech-l mailing list

Reply via email to