Please comment on the draft consultation for splitting the admin role

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Please comment on the draft consultation for splitting the admin role

Gergő Tisza
Hi all,

per the discussion on Phabricator, I'd like to split the administrator
("sysop") user group into two parts - one which can edit sitewide CSS/JS,
and one which can not. You can find the details and detailed rationale in
the task:
https://phabricator.wikimedia.org/T190015

To inform the editor communities, and to make sure we can accommodate their
needs, I plan to run a community consultation; I'll probably kick it off on
Friday and have it run for two weeks. You can find the draft here:
https://meta.wikimedia.org/wiki/User:Tgr/Create_separate_user_group_for_editing_sitewide_CSS/JS

I would appreciate if folks who are knowledgeable about the use of CSS/JS
editing and user rights management in various parts of the community could
look at it and add their concerns or suggestion to the talk page (or
Phabricator if that's more appropriate). Suggestions for a better group
name are especially welcome.

(As I wrote it in the FAQ on the consultation page, I think making sure
that MediaWiki is secure and at the same time empowers its users falls
under the authority of the developer community, and so the normal code
review process is appropriate for this change. Thus the consultation is not
intended to be an RfC or other discussion/veto type process. If you
disagree about the change in general, please discuss that on Phabricator,
or the linked Gerrit patches.)

Thanks!
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Please comment on the draft consultation for splitting the admin role

Petr Bena
Is there any historical evidence that sysops being able to edit JS /
CSS caused some serious issues? Your point that "most of
administrators don't understand JS / CSS" is kind of moot. They are
usually trustworth and intelligent people. They don't mess up with
something they don't understand and therefore it makes little sense to
restrict them from being able to do that.

I remember that many years ago there was an attempt to split sysop
group on English Wikipedia to multiple smaller roles and it horribly
failed.

I understand your points, but do we really need it? Is it going to
improve anything?

On Mon, Jun 11, 2018 at 1:58 PM, Gergő Tisza <[hidden email]> wrote:

> Hi all,
>
> per the discussion on Phabricator, I'd like to split the administrator
> ("sysop") user group into two parts - one which can edit sitewide CSS/JS,
> and one which can not. You can find the details and detailed rationale in
> the task:
> https://phabricator.wikimedia.org/T190015
>
> To inform the editor communities, and to make sure we can accommodate their
> needs, I plan to run a community consultation; I'll probably kick it off on
> Friday and have it run for two weeks. You can find the draft here:
> https://meta.wikimedia.org/wiki/User:Tgr/Create_separate_user_group_for_editing_sitewide_CSS/JS
>
> I would appreciate if folks who are knowledgeable about the use of CSS/JS
> editing and user rights management in various parts of the community could
> look at it and add their concerns or suggestion to the talk page (or
> Phabricator if that's more appropriate). Suggestions for a better group
> name are especially welcome.
>
> (As I wrote it in the FAQ on the consultation page, I think making sure
> that MediaWiki is secure and at the same time empowers its users falls
> under the authority of the developer community, and so the normal code
> review process is appropriate for this change. Thus the consultation is not
> intended to be an RfC or other discussion/veto type process. If you
> disagree about the change in general, please discuss that on Phabricator,
> or the linked Gerrit patches.)
>
> Thanks!
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Please comment on the draft consultation for splitting the admin role

Bartosz Dziewoński
On 2018-06-11 15:28, Petr Bena wrote:
> Is there any historical evidence that sysops being able to edit JS /
> CSS caused some serious issues? Your point that "most of
> administrators don't understand JS / CSS" is kind of moot. They are
> usually trustworth and intelligent people. They don't mess up with
> something they don't understand and therefore it makes little sense to
> restrict them from being able to do that.

Yes, in the recent months there have been several incidents of a sysop
accounts on Wikimedia wikis being taken over by an attacker, and the
first thing done by the compromised accounts was adding nasty code to
sitewide JavaScript to take over further accounts.


--
Bartosz Dziewoński

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Please comment on the draft consultation for splitting the admin role

Thiemo Kreuz
In reply to this post by Petr Bena
> Is there any historical evidence that sysops being able to edit JS / CSS caused some serious issues?

Oh yes, this happens more often than I feel it needs to. I remember a
situation when I posted a fix for a script in the MediaWiki:…
namespace as an {{edit request}}, and a well-meaning administrator
tried to "improve" my line of code and forgot a comma, breaking all
JavaScript for all logged-in as well as not logged-in Wikipedia
editors and readers for some painful minutes.

I believe such can be avoided with more clear roles that are visible
for everybody. A separate "tech admin" role would also allow
volunteers to apply for exactly that, and not be asked why they don't
do enough "administrator actions" with their privileges.

Sure, this is anecdotal evidence. Please forgive me, but I currently
don't have the time to find the pages documenting these situation.

Best
Thiemo

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Please comment on the draft consultation for splitting the admin role

Petr Bena
OK in that case I think this should be done.

On Mon, Jun 11, 2018 at 3:40 PM, Thiemo Kreuz <[hidden email]> wrote:

>> Is there any historical evidence that sysops being able to edit JS / CSS caused some serious issues?
>
> Oh yes, this happens more often than I feel it needs to. I remember a
> situation when I posted a fix for a script in the MediaWiki:…
> namespace as an {{edit request}}, and a well-meaning administrator
> tried to "improve" my line of code and forgot a comma, breaking all
> JavaScript for all logged-in as well as not logged-in Wikipedia
> editors and readers for some painful minutes.
>
> I believe such can be avoided with more clear roles that are visible
> for everybody. A separate "tech admin" role would also allow
> volunteers to apply for exactly that, and not be asked why they don't
> do enough "administrator actions" with their privileges.
>
> Sure, this is anecdotal evidence. Please forgive me, but I currently
> don't have the time to find the pages documenting these situation.
>
> Best
> Thiemo
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Please comment on the draft consultation for splitting the admin role

Gergo Tisza
In reply to this post by Petr Bena
On Mon, Jun 11, 2018 at 3:28 PM Petr Bena <[hidden email]> wrote:

> Is there any historical evidence that sysops being able to edit JS /
> CSS caused some serious issues? Your point that "most of
> administrators don't understand JS / CSS" is kind of moot. They are
> usually trustworth and intelligent people. They don't mess up with
> something they don't understand and therefore it makes little sense to
> restrict them from being able to do that.
>

The primary concern here is someone taking over the account by password
guessing, social engineering, phishing, exploiting some unfixed MediaWiki
vulnerability etc. The secondary concern is admins becoming malicious or
doing something stupid as a way of ragequitting, which is rare but does
happen (for example, not so long ago, someone thought it would be a good
idea to make money by installing a cryptocoin miner on Wikipedia). Admins
making a mistake and breaking the site also happens occasionally, but
that's not a security problem so it's a pretty minor issue in comparison.

I understand your points, but do we really need it? Is it going to
> improve anything?


It reduces the attack surface. Less people with access means less
vulnerable passwords, less people whose system has been infected with the
latest computer virus etc.
Also there are things we might require JS editors to do which might be
inconvenient to some people (e.g. making two-factor authentication
required) so it's good to reduce the number of people who have to be
exposed to that.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Please comment on the draft consultation for splitting the admin role

Petr Bena
Speaking of security, I believe that all sysops and people allowed to
edit JS / CSS anywhere on mediawiki sites should be required to use
2FA.

On Mon, Jun 11, 2018 at 4:53 PM, Gergo Tisza <[hidden email]> wrote:

> On Mon, Jun 11, 2018 at 3:28 PM Petr Bena <[hidden email]> wrote:
>
>> Is there any historical evidence that sysops being able to edit JS /
>> CSS caused some serious issues? Your point that "most of
>> administrators don't understand JS / CSS" is kind of moot. They are
>> usually trustworth and intelligent people. They don't mess up with
>> something they don't understand and therefore it makes little sense to
>> restrict them from being able to do that.
>>
>
> The primary concern here is someone taking over the account by password
> guessing, social engineering, phishing, exploiting some unfixed MediaWiki
> vulnerability etc. The secondary concern is admins becoming malicious or
> doing something stupid as a way of ragequitting, which is rare but does
> happen (for example, not so long ago, someone thought it would be a good
> idea to make money by installing a cryptocoin miner on Wikipedia). Admins
> making a mistake and breaking the site also happens occasionally, but
> that's not a security problem so it's a pretty minor issue in comparison.
>
> I understand your points, but do we really need it? Is it going to
>> improve anything?
>
>
> It reduces the attack surface. Less people with access means less
> vulnerable passwords, less people whose system has been infected with the
> latest computer virus etc.
> Also there are things we might require JS editors to do which might be
> inconvenient to some people (e.g. making two-factor authentication
> required) so it's good to reduce the number of people who have to be
> exposed to that.
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Please comment on the draft consultation for splitting the admin role

Bart Humphries
In reply to this post by Thiemo Kreuz
" I remember a situation when I posted a fix for a script in the
MediaWiki namespace
as an {{edit request}}, and a well-meaning administrator tried to "improve"
my line of code and forgot a comma, breaking all JavaScript for all
logged-in as well as not logged-in Wikipedia editors and readers for some
painful minutes"

Everyone makes mistakes.  I presume that under this revised proposal, that
administrator would still have had JS edit permission, and might have still
made the mistake.  I mean, they apparently knew JS well enough to have been
able to pass whatever test would have been required to get that permission
added to their account.

Perhaps we need a real test environment of some sort, so that changes like
that must be run on the test server for X [time period] before being pushed
to live?  Changes can't happen on live until there's some sort of consensus
that the test code actually works as run -- any additional changes reset
the test time period counter before it can be pushed to live.

Bart Humphries
[hidden email]
(909)529-BART(2278)

On Mon, Jun 11, 2018 at 7:40 AM, Thiemo Kreuz <[hidden email]>
wrote:

> > Is there any historical evidence that sysops being able to edit JS / CSS
> caused some serious issues?
>
> Oh yes, this happens more often than I feel it needs to. I remember a
> situation when I posted a fix for a script in the MediaWiki:…
> namespace as an {{edit request}}, and a well-meaning administrator
> tried to "improve" my line of code and forgot a comma, breaking all
> JavaScript for all logged-in as well as not logged-in Wikipedia
> editors and readers for some painful minutes.
>
> I believe such can be avoided with more clear roles that are visible
> for everybody. A separate "tech admin" role would also allow
> volunteers to apply for exactly that, and not be asked why they don't
> do enough "administrator actions" with their privileges.
>
> Sure, this is anecdotal evidence. Please forgive me, but I currently
> don't have the time to find the pages documenting these situation.
>
> Best
> Thiemo
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Please comment on the draft consultation for splitting the admin role

Steven Walling
I'm definitely supportive of greater security for sitewide JS/CSS, but
Bart's proposal is an interesting one. (Sorry for top posting, on mobile)

What if we required review of edits to JS/CSS in the MediaWiki namespace
(not in other namespaces), ala pending changes or something similar? We
require code review in Gerrit, so why not sitewide code in the wiki?

I propose this because if we split code editing rights into a separate
userright, this entails increased process bloat for managing who and who
doesn't get the right, the criteria for deciding that, and so on. Requiring
code review would allow for more flexibility while increasing security. It
would require less process bloat too because the community already has
mechanisms for requesting edits be confirmed via talk pages and such.

On Mon, Jun 11, 2018 at 8:15 AM Bart Humphries <[hidden email]>
wrote:

> " I remember a situation when I posted a fix for a script in the
> MediaWiki namespace
> as an {{edit request}}, and a well-meaning administrator tried to "improve"
> my line of code and forgot a comma, breaking all JavaScript for all
> logged-in as well as not logged-in Wikipedia editors and readers for some
> painful minutes"
>
> Everyone makes mistakes.  I presume that under this revised proposal, that
> administrator would still have had JS edit permission, and might have still
> made the mistake.  I mean, they apparently knew JS well enough to have been
> able to pass whatever test would have been required to get that permission
> added to their account.
>
> Perhaps we need a real test environment of some sort, so that changes like
> that must be run on the test server for X [time period] before being pushed
> to live?  Changes can't happen on live until there's some sort of consensus
> that the test code actually works as run -- any additional changes reset
> the test time period counter before it can be pushed to live.
>
> Bart Humphries
> [hidden email]
> (909)529-BART(2278)
>
> On Mon, Jun 11, 2018 at 7:40 AM, Thiemo Kreuz <[hidden email]>
> wrote:
>
> > > Is there any historical evidence that sysops being able to edit JS /
> CSS
> > caused some serious issues?
> >
> > Oh yes, this happens more often than I feel it needs to. I remember a
> > situation when I posted a fix for a script in the MediaWiki:…
> > namespace as an {{edit request}}, and a well-meaning administrator
> > tried to "improve" my line of code and forgot a comma, breaking all
> > JavaScript for all logged-in as well as not logged-in Wikipedia
> > editors and readers for some painful minutes.
> >
> > I believe such can be avoided with more clear roles that are visible
> > for everybody. A separate "tech admin" role would also allow
> > volunteers to apply for exactly that, and not be asked why they don't
> > do enough "administrator actions" with their privileges.
> >
> > Sure, this is anecdotal evidence. Please forgive me, but I currently
> > don't have the time to find the pages documenting these situation.
> >
> > Best
> > Thiemo
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Please comment on the draft consultation for splitting the admin role

Pine W
In reply to this post by Gergő Tisza
Hi Gergő,
I think that your proposal makes sense and would be good for the community to consider in an RfC.
Because this could involve complex wikilegal changes to how Wikimedia sites assign user permissions, and presently unforseen side effects, I think that the RfC should be translated into a variety of languages before it us opened, and that it should remain open for one month.
Thank you for requesting feedback early in the process of proposing this change, and for proceeding in a methodical and thoughtful way.


Pine
( https://meta.wikimedia.org/wiki/User:Pine )
-------- Original message --------From: Gergő Tisza <[hidden email]> Date: 6/11/18  4:58 AM  (GMT-08:00) To: Wikimedia developers <[hidden email]> Subject: [Wikitech-l] Please comment on the draft consultation for splitting
  the admin role
Hi all,

per the discussion on Phabricator, I'd like to split the administrator
("sysop") user group into two parts - one which can edit sitewide CSS/JS,
and one which can not. You can find the details and detailed rationale in
the task:
https://phabricator.wikimedia.org/T190015

To inform the editor communities, and to make sure we can accommodate their
needs, I plan to run a community consultation; I'll probably kick it off on
Friday and have it run for two weeks. You can find the draft here:
https://meta.wikimedia.org/wiki/User:Tgr/Create_separate_user_group_for_editing_sitewide_CSS/JS

I would appreciate if folks who are knowledgeable about the use of CSS/JS
editing and user rights management in various parts of the community could
look at it and add their concerns or suggestion to the talk page (or
Phabricator if that's more appropriate). Suggestions for a better group
name are especially welcome.

(As I wrote it in the FAQ on the consultation page, I think making sure
that MediaWiki is secure and at the same time empowers its users falls
under the authority of the developer community, and so the normal code
review process is appropriate for this change. Thus the consultation is not
intended to be an RfC or other discussion/veto type process. If you
disagree about the change in general, please discuss that on Phabricator,
or the linked Gerrit patches.)

Thanks!
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Please comment on the draft consultation for splitting the admin role

Pine W
Apologies for the typos. Speaking of being thoughtful, perhaps I should be more careful when typing on mobile devices.

Pine
( https://meta.wikimedia.org/wiki/User:Pine )
-------- Original message --------From: Pine W <[hidden email]> Date: 6/11/18  1:42 PM  (GMT-08:00) To: Wikimedia developers <[hidden email]> Subject: Re: [Wikitech-l] Please comment on the draft consultation for splitting
  the admin role
Hi Gergő,
I think that your proposal makes sense and would be good for the community to consider in an RfC.
Because this could involve complex wikilegal changes to how Wikimedia sites assign user permissions, and presently unforseen side effects, I think that the RfC should be translated into a variety of languages before it us opened, and that it should remain open for one month.
Thank you for requesting feedback early in the process of proposing this change, and for proceeding in a methodical and thoughtful way.


Pine
( https://meta.wikimedia.org/wiki/User:Pine )
-------- Original message --------From: Gergő Tisza <[hidden email]> Date: 6/11/18  4:58 AM  (GMT-08:00) To: Wikimedia developers <[hidden email]> Subject: [Wikitech-l] Please comment on the draft consultation for splitting
  the admin role
Hi all,

per the discussion on Phabricator, I'd like to split the administrator
("sysop") user group into two parts - one which can edit sitewide CSS/JS,
and one which can not. You can find the details and detailed rationale in
the task:
https://phabricator.wikimedia.org/T190015

To inform the editor communities, and to make sure we can accommodate their
needs, I plan to run a community consultation; I'll probably kick it off on
Friday and have it run for two weeks. You can find the draft here:
https://meta.wikimedia.org/wiki/User:Tgr/Create_separate_user_group_for_editing_sitewide_CSS/JS

I would appreciate if folks who are knowledgeable about the use of CSS/JS
editing and user rights management in various parts of the community could
look at it and add their concerns or suggestion to the talk page (or
Phabricator if that's more appropriate). Suggestions for a better group
name are especially welcome.

(As I wrote it in the FAQ on the consultation page, I think making sure
that MediaWiki is secure and at the same time empowers its users falls
under the authority of the developer community, and so the normal code
review process is appropriate for this change. Thus the consultation is not
intended to be an RfC or other discussion/veto type process. If you
disagree about the change in general, please discuss that on Phabricator,
or the linked Gerrit patches.)

Thanks!
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Please comment on the draft consultation for splitting the admin role

Gergo Tisza
In reply to this post by Steven Walling
On Mon, Jun 11, 2018 at 6:02 PM Steven Walling <[hidden email]>
wrote:

> I'm definitely supportive of greater security for sitewide JS/CSS, but
> Bart's proposal is an interesting one. (Sorry for top posting, on mobile)
>
> What if we required review of edits to JS/CSS in the MediaWiki namespace
> (not in other namespaces), ala pending changes or something similar? We
> require code review in Gerrit, so why not sitewide code in the wiki?
>
> I propose this because if we split code editing rights into a separate
> userright, this entails increased process bloat for managing who and who
> doesn't get the right, the criteria for deciding that, and so on. Requiring
> code review would allow for more flexibility while increasing security. It
> would require less process bloat too because the community already has
> mechanisms for requesting edits be confirmed via talk pages and such.
>

That's a good way to improve security, but orthogonal to separating
permissions (it would probably mean that an attacker would have to find two
vulnerable accounts, while this change will reduce the pool of accounts an
attacker could target; both make attacks harder, in different ways). No
reason not to do both, but separating permissions is (relatively) easy and
a review system is more like something on the scale of FlaggedRevs.

If you are interested, https://phabricator.wikimedia.org/T71445 has plenty
of discussion on code review for gadgets;
https://phabricator.wikimedia.org/T187749 is a variant of it I'm working on.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Please comment on the draft consultation for splitting the admin role

Pine W
I tend to agree with Steven's comments. I think that requiring review would, as he said, be less costly to implement in terms of the amount of volunteer time spent on managing permissions. I think that there would also be less time spent discussing and redesigning social processes than there would be if the existing admin permissions are split and communities must decide who should get which level of admin permissions.
In terms of engineering time, implementing a review process might be more costly, but given the significantly lower cost of social implementation to volunteers, I think that this option would be my first choice in the short term. 


Pine
( https://meta.wikimedia.org/wiki/User:Pine )
-------- Original message --------From: Gergo Tisza <[hidden email]> Date: 6/11/18  3:11 PM  (GMT-08:00) To: Wikimedia developers <[hidden email]> Subject: Re: [Wikitech-l] Please comment on the draft consultation for
  splitting the admin role
On Mon, Jun 11, 2018 at 6:02 PM Steven Walling <[hidden email]>
wrote:

> I'm definitely supportive of greater security for sitewide JS/CSS, but
> Bart's proposal is an interesting one. (Sorry for top posting, on mobile)
>
> What if we required review of edits to JS/CSS in the MediaWiki namespace
> (not in other namespaces), ala pending changes or something similar? We
> require code review in Gerrit, so why not sitewide code in the wiki?
>
> I propose this because if we split code editing rights into a separate
> userright, this entails increased process bloat for managing who and who
> doesn't get the right, the criteria for deciding that, and so on. Requiring
> code review would allow for more flexibility while increasing security. It
> would require less process bloat too because the community already has
> mechanisms for requesting edits be confirmed via talk pages and such.
>

That's a good way to improve security, but orthogonal to separating
permissions (it would probably mean that an attacker would have to find two
vulnerable accounts, while this change will reduce the pool of accounts an
attacker could target; both make attacks harder, in different ways). No
reason not to do both, but separating permissions is (relatively) easy and
a review system is more like something on the scale of FlaggedRevs.

If you are interested, https://phabricator.wikimedia.org/T71445 has plenty
of discussion on code review for gadgets;
https://phabricator.wikimedia.org/T187749 is a variant of it I'm working on.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Please comment on the draft consultation for splitting the admin role

Nathan Awrich
Is the risk of an attacker taking over an account with CSS/JS edit
permissions any more or less because that person knows how to use CSS/JS?
If the criteria will be that only people who know how to use CSS/JS will
get access to make those edits, I'm not sure that is perfectly tailored to
the need being identified - security from outside threats. Can we make the
edit right temporary, so someone can request it through a normal simple
process, execute their edits, and then relinquish it? It can be a right
that admins could grant to each other, as long as they can't gift it to
themselves.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Please comment on the draft consultation for splitting the admin role

Pine W
On Mon, Jun 11, 2018 at 6:26 PM, Nathan <[hidden email]> wrote:

> Is the risk of an attacker taking over an account with CSS/JS edit
> permissions any more or less because that person knows how to use CSS/JS?
> If the criteria will be that only people who know how to use CSS/JS will
> get access to make those edits, I'm not sure that is perfectly tailored to
> the need being identified - security from outside threats.



That's a good point that I hadn't considered, and that I think further
supports the approach that Steven advocated instead of the approach of
developing a new user permission.




> Can we make the
> edit right temporary, so someone can request it through a normal simple
> process, execute their edits, and then relinquish it? It can be a right
> that admins could grant to each other, as long as they can't gift it to
> themselves.
>


I think that a per-edit review would be preferable, so that someone can't
request what they say will be benevolent edits and then do something
malicious before anyone else has enough time to review all of the changes
that they made.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Please comment on the draft consultation for splitting the admin role

Federico Leva (Nemo)
In reply to this post by Gergő Tisza
Personally I'd like us to explore agnostic and non-invasive solutions.

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.

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.

Granular permissions are tricky on MediaWiki, but we might come up with
simple implementations. Maybe, set a rate limit to 0 and add a special
page to temporarily increase it for yourself (or others). Something like
that.

Federico

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Please comment on the draft consultation for splitting the admin role

Gergő Tisza
In reply to this post by Nathan Awrich
On Tue, Jun 12, 2018 at 3:26 AM Nathan <[hidden email]> wrote:

> Is the risk of an attacker taking over an account with CSS/JS edit
> permissions any more or less because that person knows how to use CSS/JS?
>

I tried to address this in the FAQ:
> * The number of accounts which can be used to compromise the site will be
drastically reduced. Less accounts that can serve as attack vectors means a
smaller chance chance of an account being vulnerable when the password
database of some third-party website gets compromised. A smaller number of
accounts is also easier to monitor for suspicious logins.
> * Beyond the mere numbers of accounts, it will remove the most vulnerable
accounts as attack vectors. Users who can write CSS/JS code probably have
better IT skills in general, and thus better password and system security
practices."

Can we make the
> edit right temporary, so someone can request it through a normal simple
> process, execute their edits, and then relinquish it? It can be a right
> that admins could grant to each other, as long as they can't gift it to
> themselves.
>

We can (with some work), and we should. The various ways to make deploying
malicious javascript harder are complimentary, and we should do them all.
Separating permissions just happens to be the easiest one.

I feel most people don't appreciate how *extremely* scary the current
situation is. The public backlash around the Seigenthaler affair was
sparked by Wikipedia carelessly causing harm to a single individual. It
would be child's play compared to what would happen if a few ten thousand
people had their bank accounts cleaned, or a few dozen opposition members
arrested by the secret police, or something like that, because Wikipedians
decided security improvements were not worth the effort of moving users
from one group to another.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Please comment on the draft consultation for splitting the admin role

Gergő Tisza
In reply to this post by Federico Leva (Nemo)
On Tue, Jun 12, 2018 at 8:56 AM Federico Leva (Nemo) <[hidden email]>
wrote:

> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Please comment on the draft consultation for splitting the admin role

Pine W
In reply to this post by Gergő Tisza
Regarding "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.": I think that mandatory code review and mandatory authentication would be far less costly and far faster to implement in terms of volunteer time spent redesigning social processes and managing permissions. These options both sound good to me.


In the longer term, I am thinking about how to implement a new permission as you suggest. The more that I think about it, the more that I believe that it could be done with less time cost to volunteers than I originally was dreading. For example, the new permission could be locally assignable by stewards upon community request, similar to bureaucrat permissions. A month-long RFC with adequate translations would likely be sufficient to surface most major unintended side effects and to surface suggestions for design modifications.


Regarding "I feel most people don't appreciate how *extremely* scary the current situation is. The public backlash around the Seigenthaler affair was sparked by Wikipedia carelessly causing harm to a single individual. It would be child's play compared to what would happen if a few ten thousand people had their bank accounts cleaned, or a few dozen opposition members arrested by the secret police, or something like that, because Wikipedians decided security improvements were not worth the effort of moving users from one group to another.": unless I have overlooked something, there seems to be consensus in this thread that changes are worth considering, and people are discussing which changes to make and in what order. People are trying to be helpful, and please keep that in mind.


Pine
( https://meta.wikimedia.org/wiki/User:Pine )
null
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l