Page MenuHomePhabricator

Create Trusted Contributors project?
Closed, ResolvedPublic

Description

First Proposal

What I'd like to create is a new 'trusted contributors' group, or more specifically, an acl project.

The purpose: To serve as a minimal policy control for access to certain features in phabricator which might be prone to abuse. Things like creating a paste, editing tasks, uploading files, or anything else that we identify to be an easy target for spammers or other kinds of abuse from outside the community.

Membership should be maximally-inclusive, essentially anyone who has demonstrated constructive contributions in any area of the wikimedia community should be added - and any member should be able to add members to the group.

Think of it as similar to Project-Admins and Repository-Admins but with much less specialized/technical requirements for membership, no specific responsibilities, just a tiny barrier to abuse.

Alternative proposal

Upon writing this task and reviewing what the upstream phabricator project is doing[1], I thought of proposing an alternative solution, which is as follows:

  • Rename project-admins to something like Trusted-Contributors or Trusted-Contributors
  • Open up the membership to be much more inclusive of all contributors
  • This would generalize the group's purpose to be much less specific.

Then we wouldn't need a new project for the additional anti-abuse purposes that I am attempting to address with this task.

This really works nicely with the changes we have been discussing in T139210: Abandon (or at least strongly simplify) project creation policy...

[1] The Upstream Phabricator has handled a similar problem with two group projects for contributors: #community and #blessed-committers which control general and repository-specific access, respectively.

Event Timeline

mmodell created this task.Sep 16 2016, 1:03 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 16 2016, 1:03 AM
mmodell renamed this task from Create acl*trusted_contributor to Create Trusted Contributors project?.Sep 16 2016, 1:04 AM
mmodell updated the task description. (Show Details)Sep 16 2016, 1:31 AM

Note that we have some similar (ACL) projects already, such as WMF-NDA or Security. Wondering if they could be reused to some extent (but that requires agreeing on what "trusted" means).

@Aklapper: Those a much more trusted than what I intended... I mean a minimally trusted group, as apposed to trusted-and-legally-bound...

Trust isn't really what I meant I guess...

What I'm suggesting is more along the lines of: "real people who have shown some sort of positive contribution, probably not a spambot or vandal."

Paladox added a comment.EditedSep 16 2016, 6:58 AM

+1 good idea for updating the previous project so as not to create a second one.

But we should still allow pastes without groups and tasks just some features could be limited to the group.

We could also potentially do this for creating projects?

Should also limit the *changing priority* right, as this has been violated by Cantonese users (at least) 3 times

revi added a subscriber: revi.Apr 4 2017, 8:21 AM

+1 (sorry for the spam) but i agree with this one as i would like to create pastes that are private sometime between one person.

greg added a subscriber: greg.Oct 4 2017, 9:01 PM

Not responding to any specific implementation proposal, but, after dealing with a couple bouts of spam I think something like this would be really useful for us.

mmodell updated the task description. (Show Details)Oct 4 2017, 9:03 PM

Should also limit the *changing priority* right, as this has been violated by Cantonese users (at least) 3 times

Yeah, changing priorities and moving tasks on workboards are both prone to some minor abuse.

mmodell triaged this task as Normal priority.Oct 4 2017, 9:08 PM

I'm okay in general with the proposal. However its purpose is defeated if virtually anyone can join the group IMHO. Which abilities do you plan to assign to this ACL if created? Thanks.

This sounds like its going to be similar to the "editbugs" permission from Bugzilla?

greg added a comment.Oct 4 2017, 11:06 PM

Basically, if my memory serves me correctly.

I'm okay in general with the proposal. However its purpose is defeated if virtually anyone can join the group IMHO. Which abilities do you plan to assign to this ACL if created? Thanks.

A project can also be created so that only members can add users :)

So should we use the existing project-admins group or should it be something like #acl*community?

should probably be #acl*community :))

Dzahn added a subscriber: Dzahn.Oct 6 2017, 12:05 AM

Membership should be maximally-inclusive, essentially anyone who has demonstrated constructive contributions in any area of the wikimedia community should be added

So this made me think.. Here in Phab people can use either Wikitech/LDAP user or wiki/CentralAuth user to login. For the wiki/CA users, could we (Phabricator) see which user flags they have on wiki and start by auto-trusting those that have any, or could it even check if they have a minimum number of edits. For the Wikitech/LDAP users, could it do the same on Wikitech wiki? if the user exists there and has _any_ number of edits (that have not been reverted) then Phab can trust them with these things here as well? Basically i am thinking it's maybe worth to try and prevent that we have to just manually add people to a trusted list all the time, like we do in Gerrit, where new people constantly will have to ask to be added and somebody has to react to it. Maybe it can be a bit more automatic or smart about it instead.

if the user exists there and has _any_ number of edits (that have not been reverted) then Phab can trust them with these things here as well?

I think we can check the user's edit count via oauth and we can check whether their email address is already confirmed. That said, we should be careful not to lower the bar for spammers. It's already far too easy to create a throwaway account on mediawiki and then jump straight into spamming Phabricator with the same login.

The extra step of manually adding people to the trusted group is a critical step that a spammer will have a hard time accomplishing. It might inconvenience legit users slightly but it will (hopefully) frustrate spammers more so.

The extra step of manually adding people to the trusted group is a critical step

As someone needs to spend time doing this, I wonder how this could scale. (Seeing the time spent on requests for WMF-NDA / LDAP group / Security access etc.) And criteria to be defined. And people to decide and spending time deciding.
(You could say "Allow any group member to make another user also a member" but with my evil hat on I'd just behave inconspicuous for a while and once someone has added me I'd add a bunch of other accounts and the concept would become useless. We'd be back to the usual problem with trust on the internet. Maybe I miss something?)

@Aklapper: those are valid concerns but it would certainly raise the bar significantly for abuse. Whether it would raise it high enough to prevent it? I don't know. More importantly, would the administration overhead outweigh the benefit gained from the reduction in abuse? That I cannot answer without trying it.

mmodell added a comment.EditedOct 23 2017, 4:58 PM

I'd like to try this. If someone evil manages to get past the web of trust they will be found out and we can remove them / block them. It's still raising the bar which doesn't seem like a bad thing to me. @Aklapper: are you apposed to trying it?

(You could say "Allow any group member to make another user also a member" but with my evil hat on I'd just behave inconspicuous for a while and once someone has added me I'd add a bunch of other accounts and the concept would become useless. We'd be back to the usual problem with trust on the internet. Maybe I miss something?)

Wasn't this the same strategy we used with granting editbugs? And at least from my memory it seemed to work reasonably well.

demon added a subscriber: demon.Nov 9 2017, 10:23 PM

(You could say "Allow any group member to make another user also a member" but with my evil hat on I'd just behave inconspicuous for a while and once someone has added me I'd add a bunch of other accounts and the concept would become useless. We'd be back to the usual problem with trust on the internet. Maybe I miss something?)

Wasn't this the same strategy we used with granting editbugs? And at least from my memory it seemed to work reasonably well.

Yes, it was. And it worked just fine.

it's not going to stop the person who's determined to socially engineer their way in to wreak havoc--nor will it stop someone who's long been trusted from going on a rampage. But it does stop drive-by accounts from being able to do lots of harmful things.

We should do this again.

What permissions does this group have?

Currently the only special permission is the ability to create private pastes.

Currently the only special permission is the ability to create private pastes.

Weird... https://owo.sh/e50d5d.png

Nirmos added a subscriber: Nirmos.Nov 10 2017, 2:13 PM

I'm here for the same reason as TerraCodes. Until recently, I was able to read the herald transcripts shown in the screenshot. If I understand correctly, these transcripts are just the rules by which a software adds someone as a subscriber to a task. That does not seem like very sensitive information to me, and judging by mmodell's last comment, it does not seem to have been the intention to restrict access to this information.

What was the criteria for being added in the first batch of people?

@Krenair: It was mostly people who have submitted a paste recently. I just manually added a bunch of names so it wasn't thorough or very systematic.

@Nirmos, @TerraCodes: Sorry I didn't intend to restrict that. I will fix it right away.

@Nirmos, @TerraCodes: Sorry I didn't intend to restrict that. I will fix it right away.

thanks

@Nirmos, @TerraCodes: Sorry I didn't intend to restrict that. I will fix it right away.

Well, I also wanna join, as I was created a vote months ago

revi added a comment.Nov 11 2017, 7:52 AM

Maybe can we have 'all Triagers who are not already in the Trusted-Contributors' added to the Trusted-Contributors ?

I would greatly appreciate being added. I currently help out in a few projects.

greg added a comment.Dec 14 2017, 5:43 PM

Sooo, this project is created yet we haven't removed the default rights of newly created accounts, correct? Can we? Can we use this to try to reduce the amount of quick spam (adding lots of sub-tasks etc)?

@greg: correct. I'll try updating the phab security policies now.

This comment was removed by MacFan4000.

Are we going to restrict things like editing tasks, and creating pastes?

MacFan4000 raised the priority of this task from Normal to High.Jul 2 2018, 7:29 PM

Raising as we had a vandal mess up about 4000 tasks recently. This may be effective to prevent that if more policy’s get changed as proposed.

Aklapper lowered the priority of this task from High to Normal.EditedJul 16 2018, 8:30 AM

We do not plan to restrict task editing or participation and collaboration in Phabricator to Trusted-Contributors so I'm reverting the last priority bump. (Also see T198614).

Is it possible to set group-specific rate limits on Phabricator? If yes, I think we should set lower limits for people who aren't part of this project, to hamper vandalizing in the future.

@MGChecker: That is already the case.

Aklapper closed this task as Resolved.Sep 4 2018, 11:13 AM
Aklapper assigned this task to mmodell.

The project has been created, hence closing this task. For any further tweaking please file separate tasks.