>> Basically, the ability for someone to log into my account by brute forcing or obtaining my credentials
If that is the threat you are guarding against, that is the very reason for using different factors. In that way, you ensure that people cannot log in with credentials, even if they have them.
In the same way, an atm card cannot get you money, even if you stole it. In the case of an atm card and a pin, you need two factor classes, what you have and what you know.
Regarding the other part of your prior comment that incorrectly used 2FA, that is why Apple uses the terms separately, "two factor auth" and "two step auth". They are not the same.
>> Basically, the ability for someone to log into my account by brute forcing or obtaining my credentials
> you ensure that people cannot log in with credentials, even if they have them.
Except that you left out the second part of that sentence:
>> or being able to bypass the log on process by using the conventional second auth factor against me (by doing the same thing to my email account and/or my cell phone provider).
In that case, the person was a victim of a SIM swap scam which redirected password reset messages to the attacker's cell phone, which then allowed them to access the account.
Regardless of how I initially termed it, having another factor just local to the device one is using rather than a 3rd party service that can be compromised in a way that you may not immediately realize is a far better way of doing multi-factor or multi-step auth.
But this solution should not just be limited to the HTTP application level protocol. It should also be available for other application level protocols (IMAP, SMTP, NNTP, IRC, etc). That means that U2F needs to account for this, or we should have more support for using client-side TLS certificates as part of the authentication process.
When technical security items have been pointed out repeatedly to you, you keep answering without addressing those security points. A valid security design should understand the threats that are being guarded against instead of simply throwing out a favored design.
It seems that you're fixated on the terms used in the discussion rather than the substance of the discussion itself. I already provided an example where someone fell victim to the SIM swap scam because they had their cell phone number on file with their bank.
But rather than addressing the issues where a 3rd party serving as a second factor/step can be compromised without the account holder realizing it in time or the fact that U2F doesn't support other protocols besides HTTPS, you keep going on and on about "security points" which appear to be nebulous in the context of this discussion and also cherry-pick my responses only to go off on a largly irrelevant tangent.
This discussion could have been useful, but, unfortunately, it didn't turn out that way.
You misunderstand. I am not fixating on the terms, but the concept underlying the factors of identification. The point, which I stated in my first comment is that you are not taking into consideration the difference between 1.5 factor auth and 2 factor auth. Then, you are further compounding the security error, but discussing other issues instead of directly addressing that your solution doesn't address the threat model. That is why I asked what threats you are guarding against. There is a large body of knowledge here that may be worth your study, cf cia.
Yes, there is a fixation on security, since authentication is a security function that is often gotten wrong when people don't know the threat model and rush through a solution. This has been pointed out to you by several people more than once in this very thread.
If that is the threat you are guarding against, that is the very reason for using different factors. In that way, you ensure that people cannot log in with credentials, even if they have them.
In the same way, an atm card cannot get you money, even if you stole it. In the case of an atm card and a pin, you need two factor classes, what you have and what you know.
Regarding the other part of your prior comment that incorrectly used 2FA, that is why Apple uses the terms separately, "two factor auth" and "two step auth". They are not the same.