Human verification broken regardless of entry point

[Masqued]

Followed the instructions in previous issue to change entry point (which was already https://mail.protonmail.com) and tried both app.protonmail.com and mail.protonmail.com. Both times received a white human verification panel, but it remained blank, with no captcha.

Is there any other workaround?

Thanks for this app. It is the best!

[vladimiry]

Is there any other workaround?

I don't have an answer at the moment. I guess they/proton could change something in their stack since the original issue was placed and processed.

[sometimes-retro]

I had this same issue. I got it to work for me. First, I opened up my browser (Vivaldi, not sure if the particular browser is relevant, but mentioning it in case), I went to the ProtonMail website, and logged into the account that couldn't get past the captcha in the ElectronMail app. Then, without logging out of that account in my browser, I opened up the ElectronMail window and logged in to that same account. No captcha showed up and it logged in without a problem. I can only theorize that this worked because that account was successfully authenticated for this computer by logging in through the browser first. I hope this might help someone else! :)

[Masqued]

@sometimes-retro Thanks. That explains it. I was able to get in, but couldn't figure out how it had happened. I now realize that I had logged in via a web browser, so I would still be able to get mail, then later tried again via ElectronMail, and was able to get in.

[sometimes-retro]

@Masqued You're welcome. Happy to be able to help!

[NtTestAlert]

Same here, nothing works. But for my other, premium account, there is no captcha.

[mastino21]

As I reported last week or so, I can confirm no workaround so far. Even the one suggested by @vladimiry does not work. I have tried on multiple machines (Linux, Windows) and different networks (VPN with several different servers, no VPN, hotspot with mobile phone, etc) at no avail. I understand this is something which should not blame developer for, I guess this is a trick made by protonmail to make life harder to those who use Electronmail (my speculation here, so take it with caution). As a matter of fact, Electronmail is limited by this: any new account can't be used and even old accounts with "Persistent Session" toggled may have issues when logging in on new/other devices.

[vladimiry]

I tried to reproduce the case before releasing 4.13.3 but could not trigger the captcha step and so could not debug the issue.

Even the one suggested by @vladimiry does not work.

I didn't suggest the workaround here but just added a respective label based on the https://github.com/vladimiry/ElectronMail/issues/490#issuecomment-1045233006 message.

and even old accounts with "Persistent Session" toggled may have issues when logging in on new/other devices.

You can copy the files listed in https://github.com/vladimiry/ElectronMail/wiki/FAQ to another device and the login page should be skipped if the saved session is valid.

[mastino21]

I have to apologize here, it seems the workaroud posted before works. https://github.com/vladimiry/ElectronMail/issues/490#issuecomment-1045233006

Tested with Firefox on Linux, no VPN.

• Make sure you are logged in in the browser.
• Keep the browser open
• Launch Electronmail and add account
• Logging in in Electron mail does not trigger chaptcha

Sorry again for the confusion.

[vladimiry]

So it looks like this:

• They don't force the captcha step for the in-browser login which is a SSO scenario. The app by design doesn't use a SSO signing scenario.
• After the successful login via SSO flow they whitelist the IP address in the captcha wall.

[ghost]

Still not working for me. Tried to login with Firefox and Brave which both work. Then while being signed in I tried to login with a freshly installed Electronmail and there's still that POS captcha.

[quarkl8]

I've reinstalled ElectronMail, turned off my firewall, tried logging in with Firefox and Safari, and tried using all 3 packaged API entry points. No change. It's still asking for a verification without any way to verify.

[vladimiry]

Is there anything suspicious in the log file (the log.log file located in the settings folder)?

[vladimiry]

By the way, if I put https://mail-api.protonmail.com/core/v4/captcha?ForceWebMessaging=1&Token=123 url into the browser I get the "CAPTCHA verification is currently unavailable. Please select a different verification method." message. I don't have a valid token value to do a proper test and say for sure then that they just turned the relative service off.

[vladimiry]

@bartbutler / @mmso a quick question, is the https://mail-api.protonmail.com/core/v4/captcha API currently functional (in the way it worked before)?

[prestr]

Still not working for me. Tried to login with Firefox and Brave which both work. Then while being signed in I tried to login with a freshly installed Electronmail and there's still that POS captcha.

Exactly the same here, logged into Firefox and Brave. Having issue on Windows and macOS.

[bartbutler]

It should still work and is used. We did add a frame-ancestors clause to the CSP to prevent it from being embedded in random abusive places, is it possible that this is the issue? I'm not sure how these checks work for Electron.

[vladimiry]

@bartbutler thanks for the hint. This is a good starting point for me to debugging.

[ghost]

Just a little addition to the topic. For the people who can't log in at the moment, wait for a day. It seems there is some lock-out procedure at Protonmail's side. If you first got the captcha it's not going away for a few hours, even if you login to your daily browser. I just gave it another try after a good night of sleep. First I logged in through Firefox and then started a clean instance of the app. And voila, I was in.

[vladimiry]

Going to share soon a test v4.13.4 build to test by those who experience the issue. The build just wipes out the above-mentioned frame-ancestors CSP rule for core/v4/captcha request. This should fix the respective iframe page loading issue. I didn't debug the entire captcha flow in action though since could not yet trigger the captcha wall for my account.

[vladimiry]

The test build is uploaded here.

Remember, you still have to select the https://mail.protonmail.com/ API entry point in the app for the mail account since the captcha backend service is currently not deployed by @protonmail for other API entry points (see #419 and https://github.com/ProtonMail/WebClients/issues/248 for details).

[quarkl8]

@vladimiry The new build worked! That damn captcha is finally appearing, haha. Thank you!

[vladimiry]

Thanks for a quick test. So I will be publishing a new release soon.

[macbugs]

Upon first use, in a test configuration with 3 accounts:

Account A works with entry point app.protonmail.ch (login successful, no CAPTCHA is displayed) (recently used this account in a browser)

Account B & C do not work using the same entry point (login fails - CAPTCHA is not displayed)

When accounts B & C are changed to entry point mail.protonmail.com, CAPTCHA works & login is successful. After login, entry point app.protonmail.ch works for all accounts.

This is an opt-in and per account feature. You might want to try this feature if you like the convenience of automated login into the email accounts

I think most users prefer (or expect) that the default is Persistent session = enabled (because most other desktop mail clients function this way). Perhaps you could change the switch color to red when enabled, to indicate that it is a "less secure" option.

[vladimiry]

When accounts B & C are changed to entry point mail.protonmail.com, CAPTCHA works & login is successful. After login, entry point app.protonmail.ch works for all accounts.

Unfortunately @protonmail didn't enable the captcha endpoint for the domain other than mail.protonmail.com (the respective issue is still open in their public/github tracker). Apparently they reset the captcha wall for the account for some time after the successful login.

I think most users prefer (or expect) that the default is Persistent session = enabled

Yes it's enabled by default since v4.10.2 but only for a newly added accounts. So needs to be enable manually for the existing accounts.

Perhaps you could change the switch color to red when enabled, to indicate that it is a "less secure" option. Screen Shot 2022-04-13 at 23 03 12

Not really less secure since the respective session credentials saved in the encrypted file, see FAQ for details. So it's considered as a more secure option than using a web browser version where session credentials saved in a regular cookies/browser-storage (normally not encrypted on the disk with a master passwords).

[macbugs]

it's considered as a more secure option than using a web browser

I agree that ElectronMail is more secure than a browser, since malicious browser extensions can steal login credentials. But I am surprised by the relatively large size of Electron applications (ElectronMail is 2-3x the size of a web browser and cross-platform mail applications like Thunderbird.)

[vladimiry]

I am surprised by the relatively large size of Electron applications (ElectronMail is 2-3x the size of a web browser and cross-platform mail applications like Thunderbird.)

Aside from the @electron bundle itself (which by the way includes @chromium), the app also comes with 3 sets of static https://github.com/ProtonMail/WebClients bundles of mail/calendar/settings/drive/vpn web clients. Just these 3 sets of web clients take about 403MB of the disk in the unpacked form. Each of that set is mapped to a different API entry point (the only difference). The app's bundled code logic + assets is just about 30MB unpacked (I guess would be ~8-10MB if packed+minimized).

So it's expected to be fat. And I hope it's now more clear that the app is not a regular @electron wrapper that normally just loads a web page from the internet, not static local/prepackaged assets. Besides regular wrappers normally don't provide additional features in comparison with just in-browser/web version.

[macbugs]

the app also comes with 3 sets of static bundles of mail/calendar/settings/drive/vpn web clients

😳❗️I actually did not realize this, since the README only says "ElectronMail is an Electron-based unofficial desktop client for ProtonMail." Now I understand why the bundle is so large. I would recommend that you create an introductory page for this app on github.io which lists all of the features, and several screenshots like this:

Then create a descriptive listing on MacUpdate here. [Just my opinion -- but I would probably have named this application "ProtonSuite" or something similar, so the public understands that multiple services are supported. I certainly respect the scope of the work here, but would personally prefer a dedicated ProtonMail client. And then there is some debate about how PGP is obsolete but discussion of this nature requires a separate forum.]