= problem =
The Fedora Account System (FAS) has been under near constant attacks by spammers for months. As a security pre-measure, editing privileges on the wiki have been revoked to only those with CLA+1 privileges.
Some teams have a dependence on the wiki for some tasks involving new members or getting started with contributing. This can be a potential blocker for new contributors getting involved with the project.
= analysis =
It was discussed having a FAS group that alleviates this problem without necessarily sponsoring new contributors into a FAS group for a team. For example, a ''wiki-editors'' FAS group that gives interested users access to edit the wiki and access something like their fedorapeople.org space (and subsequently, the Fedora Planet).
= enhancement recommendation =
A few notes:
Curious to know what everyone else's thoughts are on this or if this implementation sounds like a good idea. +1s / +0s / -1s welcome!
I'd like to understand which groups need wiki editing privilege as a pre-requisite for group membership? Could those groups be asked to consider alternatives? This feels like we are setting ourselves up to get "social engineered" into inviting the spammers back.
Replying to [comment:1 bex]:
I feel otherwise. First of all, a spammer might not take the extra efforts to get boot-strapped into the group. Even if he/she does, basset would still detect the spam, delete the page and ban the user permanently. By having such a group, I believe we can take in only whom we think fits in there.
+1 from me.
I know the Ambassadors are one group that are affected by this, as it's a pre-requisite that anyone looking to be involved as an Ambassador create their user page with general info about them, why they want to get involved, etc. The Ambassador mailing list is also only able to be posted to by sponsored Ambassadors as well, which makes it difficult to defer introductions to a mailing list.
CommOps has a requirement for interested members to add themselves to our wiki page, but that's a step that could easily be revised to something else. Marketing doesn't have a ''requirement'' for the wiki, but a lot of the ways a newbie could contribute to Marketing involves poking around / editing on the wiki for existing resources or using it as a whiteboard space.
I think social engineering is something to be aware of and has already happened since we implemented the recent changes to counter the spam, but I wonder if this would be an edge case or something that could become more widespread.
Perhaps the group should be restricted to creating user pages then? It just seems we made a decision to do this and now we are saying we want to either add more overhead or let anyone in and defeat the purpose.
Skamath - my understanding is that we have had some very good social engineering done to us already on irc to get groups for spamming purposes.
jflory7 - I realize your examples may not be exhaustive, but it sounds like only one group is impacted and they may be able to find an alternative. They may not. But then this should be somethign they need to manage as commops probably shouldn't be approving people for applications to ambassadors.
I think limiting the group to only user pages could be a good solution. I'm only partial to keeping a way in on the wiki for eager contributors because I recognize it as a lower-level bridge that can involve users / avid on-lookers with the project. There's also the Fedora common bugs wiki page, which is one way that someone can contribute to the project too, if they're not involved anywhere else.
It's a tough situation because on one hand, we're looking at potentially making it more difficult to get a foothold in the project, but on the other hand, we have the issues with spam and having this turn into abuse very quickly. I'm also trying not to be overly biased since I personally feel like the wiki is a great way for people to become involved at the beginning, but that may just be how I see it.
I'm trying to think of a good middle-of-the-road solution, but having a hard time thinking up something. I pinged a few others to take a look at this ticket, so perhaps some of the affected groups could weigh in on this topic as well.
I suggest a low tech workaround:
Designate a group's proxy for create/update "wiki user home page" under user request in group's mailing list, this will be part of the on-boarding process of the group.(we can use templates for convenience)
Until the user has been accepted into the group can edit the wiki page (at this time will comply with CLA+1)
as skamath said :"a spammer might not take the extra efforts to get boot-strapped into the group". this workaround will works for many groups (counterexample: Marketing, this people use the wiki a lot)
It is my humble opinion.
Replying to [comment:6 bt0dotninja]:
Designate a group's proxy for create/update "wiki user home page" under user request in group's mailing list, this will be part of the on-boarding process of the group.(we can use templates for convenience) Until the user has been accepted into the group can edit the wiki page (at this time will comply with CLA+1)
So you're suggesting that for the groups that have a dependency on the wiki, have an alternative method for an introduction, and when completed, sponsor them into the FAS group for the team, to grant them wiki editing access? Just want to be sure that I understand your suggestion, I wasn't 100% clear if I understood it right.
In my humble opinion, give the groups who need this for onboarding sponsorship (ambassadors, marketing etc) for whomever their mentors are
my2cc
I think the best solution is to change the onboarding processes that require wiki edit before being sponsored to not do it.
After a couple weeks thinking about this, here's my opinion (FWIW!) as a recently-new onboarded person in the CommOps group:
I don't know if step 2 is possible in all cases, but it seems low effort enough to not scare away new folks, and also ensure someone's serious about participation. Perhaps new people could share in an email self-introduction the same content they will (once granted access) post on the wiki.
Replying to [comment:7 jflory7]:
Replying to [comment:6 bt0dotninja]: Designate a group's proxy for create/update "wiki user home page" under user request in group's mailing list, this will be part of the on-boarding process of the group.(we can use templates for convenience) Until the user has been accepted into the group can edit the wiki page (at this time will comply with CLA+1) So you're suggesting that for the groups that have a dependency on the wiki, have an alternative method for an introduction, and when completed, sponsor them into the FAS group for the team, to grant them wiki editing access? Just want to be sure that I understand your suggestion, I wasn't 100% clear if I understood it right.
Yes, basically that's the idea.
Replying to [comment:3 jflory7]:
Most projects require a self-introduction email, any background on why Ambassadors chose wiki user page to come in before mailing list subscription?
Replying to [comment:5 jflory7]:
It's a tough situation because on one hand, we're looking at potentially making it more difficult to get a foothold in the project [...]
Some projects clearly state on their join page the format for the self-introduction email. A new contributor can simply copy/paste that text and fill in the blanks which is as easy as (if not easier than) crafting a cool wiki page.
While mailing lists can be spammed it seems to me that spamming a wiki is a much serious issue which makes admission to a project an absolute requirement to prevent defacing one of the public faces of Fedora.
For that reason I'm a +1 for comment:12.
I suggest a low tech workaround: Designate a group's proxy for create/update "wiki user home page" under user request in group's mailing list, this will be part of the on-boarding process of the group.(we can use templates for convenience) Until the user has been accepted into the group can edit the wiki page (at this time will comply with CLA+1) as skamath said :"a spammer might not take the extra efforts to get boot-strapped into the group". this workaround will works for many groups (counterexample: Marketing, this people use the wiki a lot) It is my humble opinion.
I am afraid of creating groups that are easy. As it was mentioned, it will award CLA+1 status, which means vote, fedorapeople space, mail alias, among other privileges. I am not sure if it is possible to create a group that does not count toward CLA+1.
'''Discussed in [https://meetbot.fedoraproject.org/fedora-meeting/2016-08-09/commops.2016-08-09-16.02.html 2016-08-09 meeting].'''
In the meeting, we determined that having the group doesn't make as much sense as just revising existing on-boarding steps to move away from the wiki. We've already witnessed a degree of social engineering by spammers to try to gain access to CLA+1, and as also mentioned, there are privileges that have a real impact on Fedora's infrastructure too, e.g. a quota of space in fedorapeople.org, when you have CLA+1.
Further follow-up on this issue can be done in the relevant on-boarding tickets for each sub-project / team as outlined in #34. The only team where this would have a more immediate impact could be the Ambassadors, but this varies mentor to mentor, and is, as of recently, being discussed in [https://fedorahosted.org/famsco/ticket/399 famsco#399].
Closing as wontfix.
Login to comment on this ticket.