Drop online web clients support

[vladimiry]

The goal is to keep only the built-in web clients supported for the following reasons:

• Enhanced app security. Built-in web clients are static resources built from the official source code repositories and come prepackaged with the app installation package. So email provider can't ship to you intentionally or not a malicious/hacked web client version.
• Enhanced app stability. The app is more stable in case of built-in web client used since it doesn't depend on the online web client being independently updated and deployed by Protonmail / Tutanota dev teams. See here and here examples of how the email provier's breaking changes happened before affected the app.

When the app with this feature implemented gets started, it will automatically convert used online accounts to the built-in web client version. In order to go that way I will probably need to enable built-in web client for the https://app.protonmail.ch domain too in addition to already enabled https://mail.protonmail.com and https://protonirockerxow.onion domains.

I think that will be ok to keep online web client enabled for https://beta.protonmail.com domain only as beta users are prepared to face possible issues happening.

[vladimiry]

Somehow related issue ProtonMail/WebClients#129.

[vladimiry]

These are only remaining options:

New release is going to be published soon.

[vladimiry]

@nil0x42 do you think there is a need to keep online web client for .onion domain? I'd rather keep online web client enabled for https://beta.protonmail.com/ domain only.

[ghost]

I'm a bit confused about how static the built-in version really is. It looks like EM still grabs the lastest code from PM, but instead of executing it EM somehow autogenerates code from it perhaps to make it resilient (stable) to PM changes. But then that whole process could then be compromised by malicious code from PM to the extent that the untrusted code is used for anything. I'm not a j/s coder so it's not clear to me.

Enhanced app stability. The app is more stable in case of built-in web client used since it doesn't depend on the online web client being independently updated

That's very counter-intuitive. I would expect the static version to be less stable because whenever PM makes a change it could break the API that the static code relies on.

[vladimiry]

I'm a bit confused about how static the built-in version really is. It looks like EM still grabs the lastest code from PM, but instead of executing it EM somehow autogenerates code from it perhaps to make it resilient (stable) to PM changes. But then that whole process could then be compromised by malicious code from PM to the extent that the untrusted code is used for anything. I'm not a j/s coder so it's not clear to me.

The static protonmail/tutanota web clients are built from official repositories based on this constant which I used to update before releasing a new version and verifyling that things are not broken after the update. See details here #79 (comment)

That's very counter-intuitive. I would expect the static version to be less stable because whenever PM makes a change it could break the API that the static code relies on.

Nope. The app is tightly integrated with official web clients via monkey patching. So any UI change of the official web client can potentially break the app. The API changing usually happen quite less often than UI changing which means having the web clients prepackaged/static improves the app stability. If something stops working we will know for sure that the cause is in API/server-side changes as opposed to if we would use the online/live web clients. Besides the web clients is the only thing we can lock ie we can't lock the API as it's not a self-hosted solution and neither protonmail nor the tutanota version their API (the API is not public, they can and they do change whatever they want at any time).