Replace TFA with 2FA in all user strings

Where is this official?? Looking at wikipedia, it states:

Multi-factor authentication (MFA; encompassing two-factor authentication, or 2FA, along with similar terms

So the "official" in that case seems to be MFA. Google calls it "2-Step Verification", so for them it is 2SV.

Not to say that indeed, 2FA is by far the most popular search term, but I do wonder how "official" 2FA is. The closest thing to something being "official" in the internet are RFCs, and the one RFC that deals with this (https://www.ietf.org/rfc/rfc6238.txt), never mentions neither MFA, TFA or 2FA. Which makes sense given that the RFC is about the one-time password standard and not the authentication mechanism that uses it.

In any case, I do get your point, and yes, it would make a lot of sense to change all strings from TFA to 2FA.

Adding patch for 8.x-1.2

Adding a new patch for 8.x-1.2 that will work with https://www.drupal.org/project/tfa/issues/3223327#comment-15266621 ✨ Force user to setup TFA when required and there are no remaining skips Needs work

Is it worth replacing TFA with 2FA in a module whose machine name is tfa?

Is it worth replacing TFA with 2FA in a module whose machine name is tfa?

In a lot of places, i suspect not, Locations referring to the module and not the technology likely do not justify changing, especially if they are Admin facing strings.

@yeniatencio
We have recently adopted using GitlabCi in place of the deprecated DrupalCi workflow. This means that we can no longer accept patches and that we need all work to be submitted in an MR going forward. You can tell if a project is using GitlabCI by the presence of a "GitLab CI" status area on the projects page, or the presence of a .gitlabci.yml file in the source code repository.

Addtionaly all work needs to target 2.x first and after being accepted into 2.x we can evaluate it for backport to 1.x.

Is it worth replacing TFA with 2FA in a module whose machine name is tfa?

Is it worth renaming the module to fix the displayed text?

Is it worth renaming the module to fix the displayed text?

Renaming isn't a simple task by any means. I would wonder if this can be done surgically and if that would actually be necessary.

Basically what is the goal of having no mentions of TFA?

Is there admin confusion seeing TFA in the Drupal UI?
If we are looking at marketing than is that a module page change?
If we are looking to make it more clear what it does for users interacting are those targeted UI changes?

The issue was originally created because of admin confusion seeing TFA.

The module name (and the classes/functions) should not be touched... Only the user-facing strings would be affected here. And possibly only where the "TFA" acronym appears.

At a quick glance, this is exactly what #5 is doing (well, that and a lot of irrelevant code comment changes...), with the only exception being the change to the tfa_update_8012() function, which is not desired and should not be applied to the code.

I'm kind of no longer in the driver seat here, so I'll leave it up to @cmlara if he wants to apply this or not. From my point of view, as demonstrated by the google trends search I did in #3, the acronym 2FA has a LOT more use than TFA, so I still think this would be a nice UI improvement.

There are a lot of factors why the module name and classes should never change from Tfa to 2fa, chief among them being that this is impossible: https://www.php.net/manual/en/language.oop5.basic.php#language.oop5.basi...

Given the project/module name (Two-factor Authentication (TFA)), I think the confusion should not last long. Probably, it is simpler to show Two-factor Authentication (TFA) in some places more, just to remind what that TFA is.

The human-facing string for the module name can easily change to be Two-factor Authentication (2FA), while keeping the module name tfa. It only requires the change to the .info.yml files already in #5, and a quick edit to the module homepage after that.

There are lots of tabs and other little things in the user UI where we don't want to expand to have "Two-factor Authentication (TFA)". Those user tabs should stay simply "TFA" or the better-known "2FA" acronym.

I would like to add a vote of support for changing the user facing abbreviations to 2FA. And completely agree the module name should not be changed.

The reasons are:

The different between TFA and 2FA is being noticed by module end users. We have a client pushing back on TFA because they were confused and believe their site users will find TFA confusing.

A large, respected standards organizations recognizes 2FA. The glossary of the NIST Computer Security Resource Center has an entry for 2FA: https://csrc.nist.gov/glossary/term/2fa It does not have an entry for TFA: https://csrc.nist.gov/glossary?index=T

Meriam Webster also has an entry for 2FA: https://www.merriam-webster.com/dictionary/2FA

More importantly, comparing search results for "2FA" and "TFA", there are no quality results found for "TFA".

I believe the module would better serve its user base using 2FA in user facing strings. It would be great to decide for maximum user understandability. TFA is a fine abbreviation for the module, just not it's functionality.

I'm going to disagree that this is as cut and dry as its being made out to be.

It would be helpful if we had a firm grasp of just what types of 'user strings' were discussing and how we want to evaluate the process for choosing if they change or not. We have three types of user facing strings to discuss., we have Admin Users, we have End Users (site users). and we have strings that are displayed to both Admin Users and End Users. So far its not well defined when we say "user strings" which we are targeting?

At a quick glance, this is exactly what #5 is doing

To me that patch appears to be just the equivalent of a sed -i 's/TFA/2FA/g'. I wouldn't call this limited to user strings in the least.

https://localize.drupal.org/translate/projects/tfa will be impacted by these changes. The more strings we change the more translations entries we invalidate. The majority of languages do not appear to have large number of translations, however there are a few languages that this could cause a significant drop in language coverage (Dutch, German, Hungarian, Swedish).

Since the module machine name cannot change I suspect that means some admin facing strings would be referring to the module 'TFA' not the process of 2FA.

Some randomly chosen examples from #5 for discussion:

     validation_plugin_settings:
-      label: 'TFA validation plugin configuration'
+      label: '2FA validation plugin configuration'

I would think these type of references should not change as they are entirely backend, these strings are referring to the TFA module not a 2FA process.

-      '#description' => $this->t('Enable TFA for account authentication.'),
+      '#description' => $this->t('Enable 2FA for account authentication.'),

This is a bit more complex, its referring to the Module, and at the same time is referring to the process. Since these are ADMIN facing terms does it make sense for them to be 2FA when its trying to inform the admin that it is enabling the TFA module internals? Keeping in mind we should consider that sites may be running other modules that try and provide 2FA services, we need to ensure there is some separation for clarity of which module is being used/configured.

-          $status_text = $this->t('Status: <strong>TFA enabled</strong>, set @time.', [
+          $status_text = $this->t('Status: <strong>2FA enabled</strong>, set @time.', [
             '@time' => $this->dateFormatter->format($user_tfa['saved']),

Even more complex since this is an end user facing string, that is referring to the TFA module and to the 2FA process. These type of strings may actually show up frequently. I suspect a number of these benefit from long-form instead of an abbreviation to avoid any possible confusion between module names.

- *   label = @Translation("TFA Trusted Browser"),
- *   description = @Translation("TFA Trusted Browser Plugin"),
+ *   label = @Translation("2FA Trusted Browser"),
+ *   description = @Translation("2FA Trusted Browser Plugin"),

Plugins are also an interesting case, some of these labels end up exposed to Admins and End Users. These really are not "2FA Trusted Browser Plugin" they are a "Trusted Browser Plugin for the TFA module". These can probably be mitigated by just removing TFA/2FA completely from the strings as the @Tfa class inherently makes them TFA only. 📌 Convert plugin configuration to Config Entities Active could mitigate some of that if site owners are choosing how plugins are displayed.

I did not mean to imply this is cut and dried. The information was provided as another set of data points in support of a change.

And I did not examine the patch. If it is too sweeping then absolutely, more thought should be put into it. As you say, it's easy to mislabel TFA the module and two factor authentication (2fa) the functionality. The more clarity the better for usability.

Do I understand correctly you are open to a patch that changes the abbreviation in a more considered way? Or is this a will not fix?

Do I understand correctly you are open to a patch that changes the abbreviation in a more considered way? Or is this a will not fix?

Correct I'm open to making the changes, I'm by no means intending to imply this issue as a whole is a won't-fix, only the Global replacement was of concern and wondering as mentioned by @greggles if this is just a balance issue in places where they need to be shown side by side more,.

I fully agree that 2FA is a more common term, I don't think I ever used or saw TFA as an abbreviation when I did work for a VAR selling MFA/2FA solutions. Re-reading #10 I am a bit surprised to see that TFA caused admin confusion, user confusion I can understand (even 2FA will cause confusion to the uninitiated, though its more likely they will have seen 2FA than TFA.)

Also I did not think much of it at first, however we may want to consider back to #3 and evaluate if we want 2FA or MFA to be the new abbreviation used for user facing strings. if were going to force a UI change we should at least discuss the future proofing.

The "issue" is that, to make more obvious this is a module that implements a 2FA solution, and make that clear even when watching the module files, the module machine name should have ben 2fa, but that is not a allowed machine name, as that machine name should be used as prefix for the name of every function implemented by the module, which is not allowed by PHP.

I can understand why tfa was chosen as machine name; I can also understand it is not immediate that TFA is referring to 2FA.
The only solution which resolves any possible issue would be to have a project whose machine name is twofa and whose name is 2FA, or Two-factor Authentication (2FA), just to make two examples. Unfortunately, that would mean creating a new project.

I am also surprised that TFA caused confusion between users with administrative permissions.
I found Views a more confusing name, which did not make me think of a module to show a list of entities. Still, after I read more documentation about that module, I have not found Views and views confusing terms; I was able to understand when view was referring to the output of the Views module, or something else.

as mentioned by @greggles if this is just a balance issue

I don't think I've commented on this issue (until this one). Where/What was my comment?

Re: #20: @greggles:
My apologies for misattributing.

The post I was referring to was #12 and was actually written by @apaderno.

I have updated the original message above to remove the error.

MFA would be good, as that could be used as module machine name (lowercase) and module name (or in the module name, as in Multi-factor authentication (MFA)).
That would mean creating a new project, though, since a project machine name cannot be changed, once the project is created.

Functions whose name starts with a digit are not allowed in PHP.

Ah an interesting point, I wasn't even thinking about that aspect to this. That likely partially identifies why the module was TFA to begin with.

That would mean creating a new project, though, since a project machine name cannot be changed, once the project is created.

At this point I believe we are still looking at the context of it being the tfa module. As noted by @jcnventura in #13 even the plaintext names of the module can change easily if we needed to do so (though I do not believe we have hit that point in this discussion yet).

I will concede that having the TFA module be "Two Factor Authentcaiton (TFA)" and yet using the terms MFA in the user interface may provoke additional administration confusion. I would however contend that if documenting in the site owners own internal manuals "The MFA process is provided by the TFA module" isn't sufficient enough to dispel that confusion that the site managers likely have much larger management problems to resolve first.

@cmlara you asked me to join the discussion from a translator's perpective. Not an easy task, I have two strong (conflicting) feelings about this question:

1. I would tend to opt for "2FA", remembering that it required quite some discipline to stick to "TFA" all the time while my experience was constantly dragging me to "2FA".
2. There are almost 150 strings containing "TFA" (according to l.d.o) - that will take a while add new translations to upcoming new untranslated strings. Last time it took me around 4 hours to add the missing German translations.

Yet and still I would recommend to differentiate between user-related observations/feedback (users may be site owners or their users, not us site builders/developers in first place). Their perspectives should guide the decision. If there is no clear need for renaming, we should focus on findability and, for example, add the synonym to help pages (not each and every field description though) and maybe claim the namespace on d.o with a sandbox project pointing to tfa.

Noting that the patch in #4 does not apply to 1.4.0

@hexabinaer Module names can't start with a number, so the namespace is already claimed as best as can be, as the next best thing to 2FA is what we already have.