Opened 6 months ago

Last modified 4 months ago

#31052 new project

Guest accounts in the ticketing system

Reported by: gaba Owned by: qbi
Priority: Medium Milestone:
Component: Internal Services/Services Admin Team Version:
Severity: Normal Keywords: ticket-system-migration
Cc: hiro, ahf, anarcat Actual Points:
Parent ID: #30857 Points:
Reviewer: Sponsor:

Description

Related to the possible migration from trac into gitlab we have been talking about guest accounts. There was a conversation in irc about having them or not. We need to come to an agreement on what to do about it.

Options in gitlab:

1) Having 'guest accounts' like <name>-guest

Pros:

  • anybody can report problems/features and there are less barriers for contribution

Cons:

  • spam

2) Opening registration

Pros:

  • anybody can report problems/features and there are less barriers for contribution

Cons:

  • spam

3) Having accounts by 'invitation only'.

Pros:

  • no spam

Cons:

  • one more barrier to contribute to Tor

Child Tickets

Change History (15)

comment:1 Changed 6 months ago by gaba

Component: - Select a componentInternal Services/Service - trac
Owner: set to qbi

comment:2 Changed 6 months ago by gaba

Component: Internal Services/Service - tracInternal Services/Services Admin Team

comment:3 Changed 6 months ago by gaba

From irc on how riseup manage the anti-spam in their gitlab instance.

  • limiting domains that can signup to ones we know (whitelist), limiting projects/group creation to a low number unless requested to increase, and then searching on the internet for links to our gitlab instance in order to find spam

on spam:
'snippets' are the most common way (eg. https://0xacab.org/snippets/776) . Even with monthly cleanup, we have been put into RBL lists for email delivery blacklisting because of the spam on gitlab. Spam goes in so many different possible ways, its mostly impossible to control, unless you dedicate a HUGE amount of time to it. Its extremely easy to miss spammers. If they don't have access to snippits, they make comments, or user pages, etc

The only thing that works is to close/limit registration (which is what gitlab.com does) or turn on google captcha/akismet

about the amount of labor on fighting spam:
You will spend at minimum 6 hours a week dealing with spam, with an open gitlab. It is not simple as just click a delete button, since you have to copy and paste the names as conformation

Not only will you spend a huge amount of time dealing with the spam, but you will also get the domain blacklisted :(
A huge amount of our spam came from gmail accounts even

We played 'whack a mole' for a while by blocking domains that were spamming but we ended up going crazy, and so we only whitelist domains now.

comment:4 Changed 6 months ago by teor

I think we're missing an option:

4) A shared "cypherpunks" account with a public password

Pros

  • anybody can report problems/features and there are less barriers for contribution
  • a larger contributor anonymity set: contributions from the same person aren't identified with a single name or handle

Cons

  • spam
  • deleting or disabling the shared account removes access for everyone using it, not just the spammer

comment:5 in reply to:  4 Changed 6 months ago by catalyst

Replying to teor:

I think we're missing an option:

4) A shared "cypherpunks" account with a public password

Pros

  • anybody can report problems/features and there are less barriers for contribution
  • a larger contributor anonymity set: contributions from the same person aren't identified with a single name or handle

Cons

  • spam
  • deleting or disabling the shared account removes access for everyone using it, not just the spammer

I think this is useful to consider. In my experience it's mostly a negative. I think anonymity without accountability is inappropriate in the particular context of our ticketing system.

comment:6 Changed 6 months ago by cypherpunks

A shared "cypherpunks" account is the best option

comment:7 in reply to:  6 Changed 6 months ago by teor

Replying to cypherpunks:

A shared "cypherpunks" account is the best option

We need to choose just one of the other options, they are mutually exclusive,

We can also choose to have a cyperpunks account, or not.
Regardless of the other option we choose.

Unfortunately, people have used the cypherpunks account to spam Trac at high rates.
And we don't have the staff or volunteers to deal with all that spam.
So we may choose not to have a cypherpunks account.

If you know of any other options that have worked for open source projects, please suggest them on this ticket.
(Most open source projects I know have registration by invitation or by contacting a support address.)

comment:8 Changed 6 months ago by teor

If we could lock tickets, projects, or the entire GitLab instance, we might be able to handle spam better.

GitHub's "lock ticket" implementation restricts comments to existing contributors. That's pretty close to what we want.
But someone would still have to watch tickets, lock them down, and unlock them later.

comment:9 Changed 6 months ago by teor

Should we try our proposed guest account config on Trac first?
That could be a good way to find out if we missed anything.

comment:10 Changed 6 months ago by cypherpunks

Most open source projects

We are not just open source project. We are anonymous open source project. Don't forget about that.

comment:11 Changed 6 months ago by hiro

Maybe we should think of gitlab (aka dip) as our internal project/issue management system. And consider github or another system for collecting bugs from other people. This way we aren't also overwhelmed with random issues...

There are other open source projects that use github already (even in the anonymity space, for example securedrop), other use also or instead a forum (secruredrop uses discourse in addition to github https://forum.securedrop.org/)

If we have a contributor that is active, we create an account for them. If they use a random protonmail (or any other email service) account they can stay anonymous too. A generic email address doesn't require someone to disclose anything about their real identity.

comment:12 in reply to:  11 Changed 5 months ago by gaba

Replying to hiro:

Maybe we should think of gitlab (aka dip) as our internal project/issue management system. And consider github or another system for collecting bugs from other people. This way we aren't also overwhelmed with random issues...

How this would work? It will not resolve the issue of having a disconnected ticket system with a tool to efficiently work on the roadmap and track work done. In securedrop it seems that they are using the forum differently than the issue system. eg. https://github.com/freedomofpress/securedrop/issues/4595

There are other open source projects that use github already (even in the anonymity space, for example securedrop), other use also or instead a forum (secruredrop uses discourse in addition to github https://forum.securedrop.org/)

Yes. A forum to discuss issues at Tor would be a good thing...

If we have a contributor that is active, we create an account for them. If they use a random protonmail (or any other email service) account they can stay anonymous too. A generic email address doesn't require someone to disclose anything about their real identity.

I personally think we should:

  1. use gitlab with open registraton
  2. only allow users create accounts with specific mail domains.
  3. use a labels to organize and filter tickets that are accepted from guest accounts.
Last edited 5 months ago by gaba (previous) (diff)

comment:13 Changed 5 months ago by cypherpunks

Maybe we should think of gitlab (aka dip) as our internal project/issue management system.

Gitlab is considered a malware for the projects like this one. It requires javascript. It uses recaptcha.

comment:14 Changed 5 months ago by anarcat

recaptcha is a plugin, and not mandatory, and we're unlikely to force our users into it. but it's true it's strongly dependent on Javascript. I think that classifying it as "malware" is a huge overstatement, however.

comment:15 in reply to:  14 Changed 4 months ago by gaba

Replying to anarcat:

recaptcha is a plugin, and not mandatory, and we're unlikely to force our users into it. but it's true it's strongly dependent on Javascript. I think that classifying it as "malware" is a huge overstatement, however.

It requires javascript for some features but not the ones that are key to use gitlab for us.

Note: See TracTickets for help on using tickets.