[Change] Allow to fully authenticate on a single page

[eugenesvk]

Is your feature request related to a problem? Please describe.
Currently logging into Cryptee with a password manager requires repeating the same action (e.g. pressing an autofill shortcut) twice:

1. to autofill the login/password
2. to autofill the encryption key

Describe the solution you'd like
I'd like to be able to autofill all 3 fields at once (i.e. on the same page)

[pablo03v]

This is related to #170

[johnozbay]

Hi there @eugenesvk !

As @pabloscloud mentioned this is somewhat related to #170, but also related to a bunch of other things.

1) Account Management

This has to do with that fact you still need to be able to login to your account, even if you forgot your encryption key, so you can still cancel your subscription.

If your encryption key was required on the same login page,
and If you forgot your key,
and if you weren't able to login to your account,
we we wouldn't be able to help you login to your account either (since we don't know your key).
= you wouldn't be able to cancel your subscription. = not cool.

So right now, we ask for the encryption key AFTER you login, to make sure you can still manage your account / payments even if you forgot your encryption key. And they key is only required when you're accessing your data.

2) Google Auth

In short, for users who use Google Auth, the auth flow is different from those users who use username/email + pass.

For username/email & pass the login flow goes like this :

[username/email]
[password]
-> home page <-
-> docs / photos
[encryption key]

For Google Auth, the login flow goes like this :

[Google Auth]
-> home page <-
-> docs / photos
[encryption key]

Since Google auth users don't have a username/email & password login, and they just have a google login to authenticate with Cryptee, both when they're creating their account and when they're logging in, encryption key field is presented separately.

(i.e. you come back from the auth redirect, THEN you see the encryption key AFTER you're logged in)
(same goes for creating the accounts. you first need to complete the google auth flow, THEN on a separate page, you see the encryption key.

While we could theoretically make this easier for username/email & password users, on the login screen, the app still doesn't know who you are (and whether if you are a google auth or username/email & pass user) so it can't present you different flows.

It's the same old enterprise login issue, and there's no easy way around this. In fact we're working on an even more advanced login security flow as we speak, and while things will change up a little bit, the flow will be a bit more different than the way it currently is, and will have a few more added bells and whistles that will change things up juuuust a little bit.

---

So I'm afraid we can't make this happen, as it would fail to meet the two requirements we have for account management and google auth.

If you can think of a solution that satisfies all these scenarios though, we would be more than happy to consider implementing it.

Hoping this makes sense and helps!

Best,

J

[eugenesvk]

This has to do with that fact you still need to be able to login to your account, even if you forgot your encryption key, so you can still cancel your subscription.

But this can be a separate page (i.e. what the current page is), I don't see how this factor is relevant to having the ability to have a different page that would accept all the information right away.

on the login screen, the app still doesn't know who you are (and whether if you are a google auth or username/email & pass user) so it can't present you different flows.

Same thing: the app knows that I'm a username/email&pass user because I can use the bookmark https://crypt.ee/login/I-am-username-email-and-pass-user to login

Maybe I'm missing something, but where is the issue with a simple separate login page that accepts all 3 fields instead of 2 then 1?

[pablo03v]

Ok, so if I understand this correct, you want to have three inputs on the same page. Username, Password and key.

If your encryption key was required on the same login page,
and If you forgot your key,
and if you weren't able to login to your account,

I don't see why one wouldn't be able to login even then. It could show an error message about the wrong key but still log you in and show the navigation at the top with access to settings.

Though I see how this could confuse users. Maybe a subdomain for photos/docs/any upcoming features could fix this? If one isn't logged in they would be redirected back to the login page and if they are logged in and the key isn't yet confirmed they can enter it on photos.crypt.ee e.g..

https://stackoverflow.com/questions/18492576/share-cookies-between-subdomain-and-domain

[johnozbay]

First off, both @eugenesvk and @pabloscloud you should read up about the benefits of separating username/password fields into separate pages. This design / security pattern exists on tons of services (incl. most banks, google and microsoft itself actually) and there's some good security research and reasons behind this.

So much so that specifically for banks, this is one of several Industry approved "security enhancements" that the U.S. banking industry is requiring member banks to choose from.

In the U.S. in 2011, all banks and credit unions were informed of new cybersecurity policy from the Federal Financial Institutions Examination Council (https://www.ffiec.gov/pdf/Auth-ITS-Final%206-22-11%20%28FFIEC%20Formated%29.pdf), along with authentication guidance presentations (https://chapters.theiia.org/western-new-york/ChapterDocuments/FFIEC%20Authentication%20Guidance.pptx).

Some more related links and reading about this :

https://www.twilio.com/blog/why-username-and-password-on-two-different-pages
https://designsmarts.co/two-page-login/

etc etc...

I'll now address your points individually :

---

@eugenesvk having separate login and signup pages for different login/signhup methods is an incredibly confusing UX idea for users plus it defeats the purpose of why you suggested this in the first place. You wanted to click one less button (for autofill) instead you would be clicking one or two extra buttons now. One to head to /login page, then another to head to /my-login-methods-login-page. (where you'd finally click on the autofill button)

So in total you'd be clicking more, not less, even if we set aside the confusing UX.

Right now the UX is simple, you can login to your account like any other service on the internet, and when/where you need to access your data (i.e. in Docs / Photos etc) you enter your key. Any layout alternative to this (with the current two-key flow at least) is going to cause more confusion than it would cure.

---

@pabloscloud, it would be extremely confusing and bad UX if :
a) you could simply not enter an encryption key, but still login (despite the form showing three input fields)
b) you could login with the wrong encryption key. (but later get a wrong key error, and have yet another key input later again)
So to remedy (b) we would need to ship yet another key screen.

--

As for using subdomains, this is bad security practice, but also bad structural practice, but also bad PWA practice for 100 different reasons and opens the doors to a whole host of other problems. i.e. you wouldn't be able to use Cryptee as a single PWA, but would need separate PWAs for each service, since PWAs (and their storage) are allocated per domain (and not root domain) — so photos and docs would be separate apps that would require separate logins. Bad structural practice because search engines don't index subdomains as a part of whole (unlike sub-directories like /docs etc) Right now all auth requests hit our apis from the same domain = crypt.ee. If you use subdomains all auth requests would have to go to crypt.ee but app specific api requests would have to go to docs.crypt.ee/api etc... and due to the fact that you end up using two separate domains, and you make secure connections to a domain that's not your current one in the address field of your browser, you would need to also do OPTIONS calls for each GET/POST etc that's not on the same domain. So effectively slow all apps and all requests down by 100 - 200ms on the network level alone. Not to mention things like extra auth checks and cookie checks since you're on separate domains now etc.

While the subdomains could easily exchange auth information and cookies, you cannot easily load content from one service into the other. i.e. load photos from cryptee photos into cryptee docs or vice versa due to canvas/same-origin restrictions. which we could work around by setting permissions manually, but still you're adding yet another layer of application level complexity just because of a single input field on the login page.

— While at the moment we're not making use of cross-service features, we're working on 3 big things and we can't talk about them yet {coming soon tho} and once these are out, it will make even less sense to have subdomains 😅

---

I know it's a lot of text, and a lot to summarize in a quick message, and it's a lot to process, but so many things are interconnected that we can't make decisions like these easily. — and all things considered a separate key input isn't that bad. Especially considering that we will very soon allow using passkeys and other physical auth methods once iOS 16 adoption goes up, and we'll introduce different additional steps into the auth flow for users who wish to use it.

Hoping this makes sense,

J

[eugenesvk]

Skimmed the pdf: mentions login 3 times and doesn't explain in those instances that it should be separated. The ppt doesn't open, redirects to their page.

Some more related links and reading about this :

https://www.twilio.com/blog/why-username-and-password-on-two-different-pages

State's that it's not worth it outside of SSO

However it's probably not worth the additional step unless you also have the SSO use case.

Which is solved with a non-SSO page. Same for the following link

https://designsmarts.co/two-page-login/

Phishing shoulnd't be a bit harder with redirects, but should be made impossible with autofill (which will fail with an phishing domain)

By the way, your login page isn't a two-page login like the links above describe: their examples don't show any Google auth buttons, but only ask for an email and decide for themselves, so you already have confusion you are against

(as a side note: financial institutions are way behind the times, they're still using those dumb SMS for 2FA, and their UIs generally suck, so not sure they have much useful to say on the proper UI, even more so the Federal Regulators)

incredibly confusing UX idea for users plus

The confused don't even need to be aware of this, they can stay on your main page and enter one field at a time.

it defeats the purpose of why you suggested this in the first place. You wanted to click one less button (for autofill) instead you would be clicking one or two extra buttons now. One to head to /login page, then another to head to /my-login-methods-login-page. (where you'd finally click on the autofill button)

I wouldn't click two buttons, why? I'd head straight to the /my-login-methods-login-page page via a two-symbol abbreviated bookmark and then click one shortcut to autofill all the data from the password manager

By the way, what I've seen some services do (if I'm not mistaken) is they show you only the email filed, but "silently" , maybe it's because after accepting the username, they show the password field on the same page, so the password manager can autofill on the same page, while it can't autofill with a redirect. So you could do something similar - show the encryption key field on the same page for it to be autofilled

Right now the UX is simple

Having to enter password twice is not simplicity (neither is the G button)

you can login to your account like any other service on the internet,
and when/where you need to access your data

which is almost always, accessing this data is the single most important use case for logging in, and "other services on the internet" usually don't gate data access after logging in (altough, of course, all types of services exist)

[johnozbay]

@eugenesvk :

State's that it's not worth it outside of SSO

We do have SSO. email, username and google to authenticate + encryption key. You can use the same email with pass for regular login or for google login interchangeably in fact.

---

but only ask for an email and decide for themselves, so you already have confusion you are against

We do exactly the same. We check if your email is a regular login or a google login and decide the flow from there. After more than 5 years of building this every literal waking day and knowing every dot in the codebase, I'd respectfully disagree that I think I'm not as confused as you think I am.

---

financial institutions are way behind the times, they're still using those dumb SMS for 2FA

a) This is an in-constructive black-and-white over generalization, the world is not black-and-white, and it's full of nuance. Not "all" financial institutions are behind, and not "all" use sms. Just because FFIEC provides basic guidelines to help make FI safer doesn't mean all FIs are behind the times. In 2021, there were 4,236 FDIC-insured commercial banks in the United States. I doubt you checked all 4,236 of them to see how they're doing security-wise. Therefore it is meaningful and important for FFIEC and federal regulations to have solid security advice. You may personally disagree with these, but doesn't make it any less important.

b) They do this, (and many others do this) because not everyone have or use 'smart'-phones, nor can they easily use other 2FA methods. It's not great, nor is it the safest, but it's safer* than not having it in the first place, and it's a step.

---

The confused don't even need to be aware of this, they can stay on your main page and enter one field at a time.

a) This is an over generalization based on your personal preferences, not backed by actual UX research or data. As well as I'm somewhat confident that nor would you be able to provide a single example of another major service that has two separate login pages and signup pages... There are however many privacy-first services that offer multi-password flows like the one we have. Protonmail, all password managers, any service that ever deals with encryption and key management has multiple key flows, and they use separate pages / input fields for username/password and encryption keys. -> and this also addresses your other point which is :

Having to enter password twice is not simplicity

^ No key management is not simple, and it's a shared responsibility between a user and a service to do the right/safe thing.

b) The 'confused' will be aware of this, since there will need to be a link to the /my-login-methods-login-page somewhere on that page that will confuse them.

---

By the way, what I've seen some services do (if I'm not mistaken) is they show you only the email filed, but "silently" , maybe it's because after accepting the username, they show the password field on the same page ...

While some services do this (i.e. iCloud) the security industry has a split opinion on this, and we are internally debating enabling this feature ourselves on the login page as well, and have a split opinion on this ourselves also. The debate centers around the topic of deniability.

In short, to do the magic (i.e. you type the email, and it silently reveals the password field or not) services need a special un-authenticated API endpoint that can 'check' if an account exists or not, and which login method it uses if it does exist. Thus providing malicious actors an easy to use convenient API to check if an account with username/email exists or not.

(This is less critical at Apple / Google scale, since it's already a safe bet that half the world's internet-using population already has a gmail, and enumerating every username / email address doesn't yield anything meaningful)

The reason this is a debate in the first place is because theoretically a malicious actor can still do this on the signup page by attempting to sign up as a new user using that email address for example.

The difference between signup vs login page however is that, we have different types of bot/attack/threat-detection algorithms running on these endpoints. i.e. signup page can detect bot 'signups' so it can check for threat patterns related to signups, i.e. user attempts creating 100 accounts with same IP.

But if we do our job right on the signup page, login doesn't need to be too concerned about how many accounts can login from the same IP. i.e. if 100 people use the same IP from the same VPN provider. So we cannot easily use signup's threat-defense algorithm on login pages or vice versa. It's not as simple as enabling a bunch of checkboxes either.

---

... is not simplicity (neither is the G button)

70%+ of our users disagree with you. They don't need to remember an email address or a password for Cryptee, only an encryption key.

Whereas if you use a username & password instead of the Google Auth ("G Button") you'll need to remember 3 things : username, password, encryption key.

So yes, by the very definition, it is simplicity, as it doesn't require users to remember 3 things, just one.

---

which is almost always, accessing this data is the single most important use case for logging in,

This is a false over-generalization. Not being able to [easily] unsubscribe when we want to is perhaps the single most annoying thing that would drive us all insane. By your logic, you rarely ever need to unsubscribe from mailing lists too... Doesn't mean services should overlook this aspect. And any one who has ever dealt with unwanted spam can agree to this. it's unnecessarily difficult to unsubscribe — and should be made easier.

and "other services on the internet" usually don't gate data access after logging in

Yes they do.

Go to google, try accessing your account activity section, or your security page. It will require you to re-authenticate. (or require an extra 2FA check)

Since we're on github, try generating an API key or doing something that requires access to sensitive data/credentials, it will require you to re-login, or re-authenticate. (or perhaps require an extra 2FA check)

Take any service that KYC'd you where you can do a GDPR data request. They wouldn't send your passport scans to you unless you do some form of extra authentication.

Take any bank. You can initiate small-sum transactions online, but larger bank-trans transfers may require phone calls or in-person authorization. PNC in the US is notorious for this and always require in-person verification.

Lots of services, for various different reasons gate your access to data after logging in and require you to re-login even. Both data you've provided to them, and data they've collected about you.

I'm not sure what your point is here? To summarize — on Cryptee, once you're logged in, you can access your account, and once you confirm your encryption key (no different than a second authentication step like 2FA) you can access your data.

---

Without very clear UX research backing up your reasoning for having two separate login pages OR research backing up your points about all three inputs being on the same page AND address all the UX and security issues and edge-cases, you're simply asserting your preferences, and that's not constructive.

I would prefer for services to magically recognize me and log me in without any input from me, and have zero digital authentication steps, but that's not the reality we live in right now, and for each step we added into this authentication flow, we have a reason. So to remove a step / change these steps, we need just as many good reasons backed with data. Until then we will not be shipping a triple-input authentication flow on a single page, nor will have two separate login pages.

[eugenesvk]

We do have SSO
We do exactly the same

Nope, that's not what it means, the whole point of the SSO factor in the article is that it requires simplification

• from two fields (email+password) and a bunch of buttons
• to one field (email)

not to confuse the users requiring them to remember which SSO they picked. So you're not doing the same, doing the same would look like this from your link https://designsmarts.co/two-page-login/ph-new-1.webp?1670949153:

Do you notice any Gmail icons there? No. Do you notice the password field? Again, no!
So you can't cite SSO as an argument for avoiding the 3rd field with the encryption key when you alread have the 2nd with the password and a separate SSO icon

After more than 5 years of building this every literal waking day and knowing every dot in the codebase, I'd respectfully disagree that I think I'm not as confused as you think I am.

Then why can't you see the difference between one login field and two?

b) They do this, (and many others do this) because not everyone have or use 'smart'-phones

That's irrelevant, they can keep using SMS for those who don't, it doesn't mean that people who do should be forced to use the weak factor

nor can they easily use other 2FA methods.

Nor can they easily be cited as an authorities in the authentication process when such basic things aren't easy for them. Neither can their regulators that couldn't regulate these kind of insecure antiques out of existence (for people with smartphones)

As well as I'm somewhat confident that nor would you be able to provide a single example of another major service that has two separate login pages and signup pages...

Well, there aren't that many major services matching your architecture with two passwords. Usually the 2nd "password" is coming as a 2FA usually requiring a separate device, so showing all the fields wouldn't help

There are however many privacy-first services that offer multi-password flows like the one we have.
, all password managers

1Password allows you to enter both the password and the secret key on the same page

Protonmail

Their reason was that the 2nd password didn't get to the server, but was local-only, so that required a separate page (but even then you didn't need to click on the Mail button and then enter the 2nd password).

^ No key management is not simple, and it's a shared responsibility between a user and a service to do the right/safe thing.

A 3rd field is simple. Gating the 3rd field from the "confused" — yes, that's not simple, but also not very complicated. It's also not simpler than requiring another click on a 'Docs' icon and then on the password manager on every login. But more importantly, it's not clear that the extra burden is actually the right/safe thing.

b) The 'confused' will be aware of this, since there will need to be a link to the /my-login-methods-login-page somewhere on that page that will confuse them.

Not really, you can make it as hidden as you believe is required to separate the confused. Of course, that would hurt discoverability, but if you value avoiding the confusion so much, that's still doable.

In short, to do the magic (i.e. you type the email, and it silently reveals the password field or not)

But in your case it would NOT be a single field, the user would still enter the name and the password. The "magic" field would be the 3rd one with the encryption key.

(by the way, shouldn't the proper solution be to just use random field just like in those passwordless links that have a long hash which you can't guess via enumeration?)

70%+ of our users disagree with you.

You're using your stats wrong. You haven't asked them on this topic to speak on their behalf. And the proper question would NOT be "do you want to use Gmail to authenticate", but closer to:

Which is (a more) simple UI:

• opening the login page with irrelevant email+password fields and a small G button + more SSO buttons as you service expands
• opening the login page with just the email field (like in your SSO articles)
• opening the login page (autofilled from your browser/bookmark) that has a single G button or maybe automatically redirects you to google for auth so you don't even have to press this button
• ...

They don't need to remember an email address or a password for Cryptee, only an encryption key.

That's not true, again from the very articles you linked: they also have to remember how they registered with your service! So much so that the article recommends removing the buttons to avoid this confusion!

Whereas if you use a username & password instead of the Google Auth ("G Button") you'll need to remember 3 things : username, password, encryption key.

No you wouldn't, you'd instead not have to remember anything (including long encryption keys) and just use the password manager to autofill

So yes, by the very definition, it is simplicity, as it doesn't require users to remember 3 things, just one.

Only if you use the most inconvenient definitions

which is almost always, accessing this data is the single most important use case for logging in,

This is a false over-generalization.

Well, that's easy to test how "false" it is with your data: what % of all login sessions end up with accessing the data vs doing account management (unsubsribing or whatever else you think is more important).

Not being able to [easily] unsubscribe when we want to is perhaps the single most annoying thing that would drive us all insane.

How on earth would allowing you to enter an encryption key right away prevent from easily unsubscribing??? You've just made that up. You could make it even easier with my single-click-to-loginworkflow by adding an "unsubscribe" button to the Docs page if you wanted to

Go to google, try accessing your account activity section, or your security page. It will require you to re-authenticate. (or require an extra 2FA check)

No, you're making the same mistake as with the previous example (and with the following ones): conflating the most frequent use case with something rare. After a gmail login, you see emails right away. After a cryptee login, you don't see notes right away.

I'm not sure what your point is here?

It's pretty simple — the primary data that the service is used for is usually available right away. You had to come up with rare cases to try to misunderstand it.

To summarize — on Cryptee, once you're logged in, you can access your account,

which is rarely needed compared to getting access to the actual notes within that account

(no different than a second authentication step like 2FA)

of course it's different. 2FA is meant to require another device, which provides extra security and thus can't be simplified to a single click. Encryption key doesn't, so it can be simplified to a single click

Without very clear UX research backing up your reasoning
for each step we added into this authentication flow, we have a reason.
So to remove a step / change these steps, we need just as many good reasons backed with data.

Since you don't have good reasons backed up with very clear UI research and data for this decision (and your own links don't support your argment), nothing prevents you from going with the obvious benefit of saving the extra clicks

[johnozbay]

First off — I'm not sure if I like your tone. Why are you trying to pick and twist things into an argument, instead of a constructive discussion. I have literally zero reasons to continue responding here, yet I'm doing this for the sake of posterity despite your rude tone. Please be civil.

Well, there aren't that many major services matching your architecture with two passwords.

Correct. When they do what we do, and offer a zero-knowledge system with deniability features baked in we can have a more educated conversation. Until then we get to decide what's best with our architecture guided by our own research.

1Password allows you to enter both the password and the secret key on the same page

Good for them. And you've just pointed out their difference yourself with that screenshot. If you lose your secret key, you have to contact customer support according to their help article.

On 1Pass, this could work, because you have to sign up with email (according to the form you screenshotted) — So I'm guessing customer support has the ability to see and manage the subscription details of their users. (and thus unsubscribe users... otherwise if you forgot your secret key, how would you cancel your 1Pass subscription?) So if you contact 1Pass using the email they know and convince customer support that you forgot the secret key, they can unsubscribe you from 1Pass.

You cannot do this on Cryptee, because you don't need an email to sign up to Cryptee. You can use usernames as well. So we would have no way to verify if someone who's contacting us is who they claim or not, as email isn't required unlike 1Pass.

In addition, 1pass's threat model evidently does not include email compromise, while ours do. If your email is compromised, and say I emailed 1Pass as you, and convinced their customer support that I forgot the secret key and can't access account so they should cancel my subscription, this would theoretically allow me to wipe out all your passwords as well.

You cannot do this on Cryptee as our customer support physically cannot unsubscribe you or modify your subscriptions or see your subscription details, only you can for your own security. This is also the reason why we ask for a separate billing email at the time of checkout, which you can also use to manage invoices etc even if you don't use an email on Cryptee but only a username.

It's apples and oranges and not a fair comparison either.

Protonmail
Their reason was that the 2nd password didn't get to the server, but was local-only, so that required a separate page (but even then you didn't need to click on the Mail button and then enter the 2nd password).

On Cryptee your username + email / password is sent, but not your encryption key, quite literally the same as Cryptee.

You're using your stats wrong. You haven't asked them on this topic to speak on their behalf.

Users who signed up with a google account, know that on literally every other website on the planet, they can simply tap the google button to login. Pressing a "g" button isn't that difficult. And I think 70%+ of the users choosing Google vs email/username is a pretty good stats to indicate that people prefer that vs typing out multiple things.

Well, that's easy to test how "false" it is with your data: what % of all login sessions end up with accessing the data vs doing account management (unsubsribing or whatever else you think is more important).

^ We can't test this, because we don't collect user usage data like other services do, we instead respect your privacy, and that's why you're here in the first place.

How on earth would allowing you to enter an encryption key right away prevent from easily unsubscribing??? You've just made that up.

Again. Watch your tone, there's literally no reason to be rude.

if you forget your encryption key and have a subscription, and the login form requires you to type username, password and encryption key how would you login to cancel your subscription? I described the difference between 1Pass in the paragraph above. Again.

It's pretty simple — the primary data that the service is used for is usually available right away. You had to come up with rare cases to try to misunderstand it.

No, we didn't misunderstand it. We implemented the most common (or yet another) form of authentication for two-password flow, same as protonmail and their two-pass flow. It's also a logical one, as it is more or less the same flow as a 2FA flow from a design perspective.

---

Just letting you know that if you cannot continue this conversation in a constructive and not-rude tone, I won't be answering your comments any futher.

[pablo03v]

@eugenesvk

1Password allows you to enter both the password and the secret key on the same page

But can you login without the key? That needs to be the case for cryptee.

you wouldn't be able to use Cryptee as a single PWA, but would need separate PWAs for each service, since PWAs (and their storage) are allocated per domain

Got ya!

[eugenesvk]

Why are you trying to pick and twist things into an argument

To help you improve your service for to the benefit of all your users and help you correct some errors

Correct. When they do what we do, and offer a zero-knowledge system with deniability features baked in we can have a more educated conversation.

That's not a blocker as it didn't block your from providing links that have nothing to do with deniability etc.

Until then we get to decide what's best with our architecture guided by our own research.

Don't worry, you'll get to decide even after that. There is no magic here where someone else's research can change the decision maker for your service

Good for them.

But bad for you claim that everyone is doing the same thing. Some services do better

otherwise if you forgot your secret key, how would you cancel your 1Pass subscription?

if you forgot your Cryptee password, how would you cancel your Cryptee subscription? The answer to this question has no bearing on whether you allow entering two passwords at login or just one.

threat model evidently does not include email compromise, while ours do.

And this is relevant how? No one prevents you or 1Password from blocking account cancellations via email only "for security", that's a separate decision. Likewise you could block account cancellation if the user forgets the encryption key "for extra security"

cancel my subscription, this would theoretically allow me to wipe out all your passwords as well.

Or practically it wouldn't, it's up to the service to choose what and when to wipe on subscription cancellation

It's apples and oranges and not a fair comparison either.

Not really, you've picked the oranges from a different basket (differences in account cancellation), the login issue of multi-password fields is the same

On Cryptee your username + email / password is sent, but not your encryption key, quite literally the same as Cryptee.

it's not literally the same as I've explained in the rest of the sentence: "(but even then you didn't need to click on the Mail button and then enter the 2nd password)."
And even then: is it not possible to send only the first two fields (name+pass), but not the third (key)?

And I think 70%+...

I've already addressed this mistake, you're just repeating it without addressing my response, that's not constructive

We can't test this

So your accusation "This is a false over-generalization" was backed by no data
But still we can test this without much user tracking: you do have data on how many login sessions there are since your servers do auth.
You also have data on how many accounts are cancelled.
No need to track beyond that

if you forget your encryption key and have a subscription, and the login form requires you to type username, password and encryption key how would you login to cancel your subscription?

By clicking on the "forgot my encryption key button"? Contacting support and getting this info how to cancel an account without a key? Reading a help article or a FAQ with the same info? Every single password-related services has these visible help links on what to do

I described the difference between 1Pass in the paragraph above. Again.

And this description is not relevant as I've also pointed out multiple times

same as protonmail and their two-pass flow.
It's also a logical one, as it is more or less the same flow as a 2FA flow from a design perspective.

It's not the same, I've explained how it's different both from Proton and more importantly from 2FA, there is a big difference from a design perspective between your extra two steps and those of 2FA, and it's not constructive to just ignore those explanations