twofactorauth
twofactorauth copied to clipboard
2factorauth
Inclusion of Self-hosted Software
Currently, we have a blanket exclusion of self-hosted software on the list. I believe this restriction should be lifted with specific requirements.
- Self-hosted software that is accessible to the public (anyone can register for an account, or that has a public interest) can be listed so long as it meets the other requirements for listing a site (eg. Alexa Top 200k)
- The software must have an independent authentication database (eg. you cannot log in to the site using credentials created on another domain)
- The software must support 2FA natively, not through extensions or plug-ins
- If a first-party or "official" extension created by the original developers is available to enable 2FA, should that be allowed?
- Third-party extensions and add-ons do not qualify
Is this restriction on "self-hosted software" written down anywhere that I can read? Mind linking?
- What is the definition of "self-hosted software"? If something is hosted and accessible to the public where anyone can create an account, how is that different than any other website on the internet?
- Can you please explain this more? How would you propose to identify whether this criteria was satisfied without knowing how the backend architecture and software are actually built?
- Same as bullet 3. How could you know by looking at a website whether they are using plugins or extensions to provide 2FA functionality? Perhaps I am misunderstanding here.
If a first-party or "official" extension created by the original developers is available to enable 2FA, should that be allowed?
IMHO, yes. Modular software architecture is good and should not be punished. Obviously, also for closed-source (not self-hosted) sites, they could have a similar architecture and you would not know. Or consider closed-source self-hosted software, like forum software (e.g. https://github.com/2factorauth/twofactorauth/issues/1296) belongs to this category, too.
Is this restriction on "self-hosted software" written down anywhere that I can read? Mind linking?
Despite being claimed that this is done, it actually is not. See https://github.com/2factorauth/twofactorauth/pull/3550 for a potential fix.
If something is hosted and accessible to the public where anyone can create an account, how is that different than any other website on the internet?
Actually, that is the big point why it made no sense to not include these in the first place. For the end-user they are just usual websites…
How would you propose to identify whether this criteria was satisfied without knowing how the backend architecture and software are actually built?
Well… you usually know. I mean we all have an intuitive understanding of the term "self-hosted", I think. Apart from that, I would however argue that it does not make any difference, because it actually does not. GitLab is e.g. self-hostable and already included, so what…? So you do not need to see it…
How could you know by looking at a website whether they are using plugins or extensions to provide 2FA functionality?
Even for closed-source projects this information is usually easily available. (there is a public plugin website or so…) Or you e.g. just look at some bigger instances or whatever…
@rugk thanks for continuing the conversation.
I think that every single site on the internet that allows anyone to create accounts should be included in the data set. Creating arbitrary rules for reasons to include/exclude publicly available websites does not make sense to me. The only reason that I have heard to date (sorry, cannot find the issue/comment) is related to the rule of only allowing sites in the Alexa top 200k and that reason was that it is difficult to manually review the PRs. While I certainly realize that everyone here is volunteering their own time and not getting paid for this, the maintenance burden of the data set can be significantly reduced using automation, so I do not think that is a convincing reason to avoid adding all publicly available sites to this data set.
The software must support 2FA natively, not through extensions or plug-ins. Third-party extensions and add-ons do not qualify
If I understand this correctly, the argument is that if someone is using a framework to host a forum site and they then use a third party plugin for that framework to provide 2FA to their users, then that should not be allowed into the data set.
If that is the argument, then I strongly disagree with it. Also, I challenge anyone to prove that a site is using such a third party plugin to provide 2FA in less time than it would take to simply review the PR and add the site to the data set. If it takes more time to enforce these rules about which sites can be included in the data set and which cannot, then I am not at all understanding the purpose of said rules.
@conorgil Be my guest and go through these points on any PR in this repository:
- Is the name the same as their official name?
- Is the url correct?
- Can the site be reached by https?
- Does the site provide 2FA?
- Can 4 be validated? Is the documentation sufficiently explaining to the user how two enable 2FA on the service?
- Is the service providing 2FA to all users or only specific users?
- Is the 2FA solutions listed indeed the correct ones? Can this be validated?
- Is the 2FA solution only for third party logins or native login? (Third party as in Facebook login, Google login etc)
- Is the logo the same as the service’s official logo?
- Is the logo not 32x32 pixels or does it contain any text that could be distorted?
- Is the logo larger than it should be? Can it be compressed further without quality compromises? If 10 of 11 is true, open photoshop or equivalent and redo the image.
- Look for unnecessary black spaces in the PR or misspelled tags.
- Look at the name of the PR and make sure it matches the or PRs naming layouts.
- Tag the PR with the correct tag.
- Approve the PR or get in touch with the author or open slack to discuss further actions.
Reviewing PRs takes a long time. Automation helps but automation can’t help with everything. There’s also a lot more work I do around twofactorauth.org to make the project go around.
If we are to list every single site on the Internet then we’d need a crew similar to size of Google’s employee base. Sadly we don’t have that luxury. We have around 10 people maintaining the project and around 2-3 active maintainers each week. Because, you know... life and such.
The 200k rule is made to limit the maintaining burden of the site. Before we had that rule, many sites would be added and then removed a month later because they simply stopped working/responding.
Regarding the forum exclusion: How big of an impact in a consumer’s choice to use said forum does 2FA have? I’d say it’s close to zero. If I’m on a forum for Ford-enthusiasts, will I stop using it because they don’t support 2FA?
Regarding third party plugins, if there are multiple plugin that provides 2FA, which one are we supposed to list? Look at ownCloud, they have +20 TOTP apps. Are we to use the most popular one of those? Are we to only list software support then even though there are other plugins with duo and yubikey support? At the moment our site is built to list one url and one documentations link. That is unless someone makes a PR that fixes this without breaking the api for third parties.
Your goal for our site might differ from our goal. Our goal is to help make the consumer make a better choice when it comes to internet based services they use. To maybe choose one btc exchange service instead of another because they support 2FA to protect your wallet. To make the step to move banks because your bank only uses password to protect your money. To use another ride service that doesn’t rely on SMS to protect your home address. To say “Hey SoundCloud! Until you start taking your user’s privacy seriously we won’t upload our music to you!”
For better or worse, that’s not the case with forums. They’re often too niche to have a competitor.
If you have another vision for our site then that’s fine. We have forks of this site providing things that are out of our scope and as long as they comply with our MIT license then we’re happy to have them.
I hope this answers some of your questions.
Regards, Carl
I think the "Alexa top 200k" is okay, so we can drop all that "maintenance" discussion. This rule was introduced for exactly that reason… But as it has been pointed out before, many self-hosted services have instances that fit the "Alexa top 200k" rule. You don't even need to sum up all instances. So what about these?
Clarification proposal: the Alexa rank of the self-hosted solution should be of the software vendor but not the instance.
I found this thread because I wanted to make a PR to include self-hosted email service sendy (whose rank is 150k-ish) but wasn't sure whether it would be appreciated or not. My own instance of that software doesn't reach that rank though 😅
To whom it may concern: 539f4c47ff7eee2424540e28cf5adf5c621b0b01 is my take an trying to square the circle on this topic. Feel free to revisit and comment. As showing the Exclusions becomes an ever more important topic, we should be trying to merge #3632 within a weeks time. Thank you all for your contributions to the discussion! // Kai
@kmpoppe Your criteria sounds good (as it e.g. makes a reasonable trade-off by allowing "first party" plugins), but this still does not change the fact that directly before your change in the PR, it is written that self-hosted services are explicitly excluded.
@rugk Thanks for your reply.
Yes, it says that self-hosting is excluded. My hope is, that people that intend on contributing to this project would go about reading everything that's written down in the ReadMe/Contributions/Exclusions and will, therefore, read what criteria we allow to include self-hosted sites.
I can only ask you to, for now, consider our position on that we have decided to use this way to keep the project clean. Currently, the active maintainers have not decided on dropping this requirement, literally @RichJeanes, who is part of this group and OP of this issue, proposed the lifting criteria I built into the page.
We are in a very fortunate situation that this project is actively maintained by a dedicated group of people. This allows us to make decisions on a relatively broad base of people. I ask you to trust us that we do not reject changes to this policy purely out of bad intentions.
// Kai
Then do change the paragraph before anyway, to explain that you allow exceptions or only "major" self-hosted software or so. And especially remove these listed examples of excluded software, because things like Mastodon or Nextcloud would be big(!) self-hostable projects I'd like to see included, and they match your second criteria there.
Having stumbled upon the PR at https://github.com/2factorauth/twofactorauth/pull/3550 again (hi, @Gargron we seem to have talked about Mastodon and why it is not included here) due to someone™ making some scientific survey about FLOSS software including that exact PR, I'd like to ask what the current status here is?
In any case, I still don't see Mastodon or Nextcloud being listed on the website. This issue here seems to have stayed silent for more than one year now, despite being in the top 10 of the most wanted issues in this repo (the 7th place if I counted correctly).
despite being in the top 10 of the most wanted issues in this repo (the 7th place if I counted correctly).
Actually, it's tied for 4th place with a few other issues, though that's not saying much when it only takes 3 +1's to do so...
Stumbled upon this issue as I figured Mattermost (open-source Slack alternative) isn't listed here.
I looks to me like it's a very relevant thing for twofactorauth to support FLOSS web projects (thus, hosted) by having them listed.
To feed the discussion about inclusion/exclusion rules, maybe things like https://trends.builtwith.com/websitelist/Mattermost could help to complement the Alexa rule. Also, probably some additional bits of info need to be given to the end-user, like checking the instance version against the latest stable version listed in twofactorauth.
