Question about Whitelist and "API Entry Point"

[git70]

Hi Guys!

Two questions:

1. Where can I find the current entry point whitelist content?
2. If I have "Block non API-Entry-Point" enabled on the onion entry point, is it possible for network requests to leak to another domain (which is also whitelisted)?

I'm asking because when opening the protonmailrmez3lotccipshtkleegetolb73fuirgj7r4o4vfu7ozyd.onion website in TorBrowser, a clearnet connection to account.proton.me appears in the network requests for a short while (this happens for a short while and you may not notice it, because it quickly returns to .onion) This PM behavior completely defeats the purpose of using the onion domain

[vladimiry]

Where can I find the current entry point whitelist content?

The whitelisted array being formed here:

https://github.com/vladimiry/ElectronMail/blob/c4f835f4d30cc5b8ee59dc89f125accdb9851d9c/src/electron-main/web-request/index.ts#L99-L118

In an official browser-based version, the web client configured to use Single Sign On / SSO authentication scheme and so you get redirected to account.proton.me for central/SSO login purposes. There is no SSO use in the app, so the redirect like this won't be happening, regardless of which API entry point is selected for use.

Enabled Block non "API entry point"-based network requests feature will be blocking requests to non API entry point-based addresses (domain origins). So if the app tries to access account.proton.me, the request will be blocked. The blocking happens with a visual error message/alert, so any unexpected request will be very visible to a user and logged too. By the way, this app feature helped to detect privacy issue in ProtonMail web client v4-beta with consequent bug bounty award.

[vladimiry]

Besides, there is no need for the app to do any external redirects since all the needed web clients prepackaged with the app as static resources patched with these patches. So the pages are local, and the external requests are only API requests.

[git70]

Enabled Block non "API entry point"-based network requests feature will be blocking requests to non API entry point-based addresses (domain origins

In other words, when I have the abc.onion entry point selected, only connections to *.abc.onion are allowed? (wildcard)

Interestingly, I noticed that connections (in TorBrowser) sometimes go correctly to account.protonmailrmez3lotccipshtkleegetolb73fuirgj7r4o4vfu7ozyd.onion and sometimes to account.proton.me Of course, in our case it doesn't matter...

[vladimiry]

In other words, when I have the abc.onion entry point selected, only connections to *.abc.onion are allowed? (wildcard)

The app should go to https://mail.protonmailrmez3lotccipshtkleegetolb73fuirgj7r4o4vfu7ozyd.onion only. The mail subdomain required since 2022-04-20, see details in https://github.com/ProtonMail/WebClients/issues/271#issuecomment-1104398459.

[git70]

The account. subdomain is not loaded / allowed? Generally in TB, resources from this subdomain are loaded as described above...

[vladimiry]

The app for API requests prefixes main domain with subdomains like mail-api/account-api/etc depending on the loaded page/web-client/service type (mail/drive/account/etc). Subdomains specified in https://github.com/vladimiry/ElectronMail/blob/c4f835f4d30cc5b8ee59dc89f125accdb9851d9c/src/shared/const/proton-apps.ts. Why these subdomains used, see https://github.com/ProtonMail/WebClients/issues/276.

[vladimiry]

The app for API requests prefixes main domain with subdomains like mail-api/account-api/etc depending on the loaded page/web-client/service type (mail/drive/account/etc).

The exception is that regardless the page/web-client/service type loaded (for the app case, it's mail page/web-client/service with login page), for a few initial login requests, the app forces account-api subdomain use since assigning specific scope to a new user session required for proper the Drive service use (in the settings UI the session type should be displayed as Proton Account for web). It was discussed before here and at https://github.com/ProtonMail/WebClients/issues/ too.

[vladimiry]

To recap, if you select Tor API entry point in the app and enable the "Block non "API entry point"-based network requests" feature, the app won't let any external request outside the Onion protonmailrmez3lotccipshtkleegetolb73fuirgj7r4o4vfu7ozyd.onion domain. More specifically, protonmailrmez3lotccipshtkleegetolb73fuirgj7r4o4vfu7ozyd.onion with mail-api/account-api/etc subdomains get whitelisted.

[git70]

the app won't let any external request outside the Onion

This is the crux of my issue :)

I like PM very much, but unfortunately this is not the first time he is behaving strangely: Some time ago he was moving the connection from the onion domain to clearnet without warning, now he creates a "hidden/temporary" clearnet connection and silently returns to the onion :(

Vlad, You're doing a great job! I'm surprised that PM didn't offer you an official job on a desktop application ;) Cheers!

[vladimiry]

PM didn't offer you an official job on a desktop application ;)

There were a few approaches and brief conversation with one of the engineers on the team, but the fit in with the role didn't look good at that time. They are working on an Electron-based desktop app, which, I believe, at some point might be able to retire ElectronMail app for the good.

[git70]

at some point might be able to retire ElectronMail app for the good.

1. Observing their pace of introducing applications (especially for Linux), the beta version will be in 2035 year ;)
2. It will never be as good and functional as EM, because many EM functions are against the interests of PM
3. I bet EM users will remain loyal to EM :)