"Send" in new web client triggers file upload block

[CraigBos]

We are happy to answer your questions about the code or discuss technical ideas.

Please complete the following checklist (by adding [x]):

• [x] I have searched open and closed issues for duplicates
• [x] This isn't a feature request
• [x] This is not a report about my app not working as expected

---

When I attempt to send an email using the new web client, it triggers a file upload block in my company's security software. This affects all web client versions since version 4.x, including the current version 5.0.1.4 beta. This does not affect web client version 3.x. This used to be served by old.protonmail.com, but not any more (as of today).

I'll put a little more information about the behavior and mitigations below.

I'd like to ask the community for information on two questions;

1. What are the differences in send behavior that were introduced in web client 4.x? Looking for enough info to suggest ruleset changes to my infosec team so as not to trigger this file upload block behavior.
2. Is there a way for me to pull sources from the latest 3.x client and create a local instance of the client here? How can I do that?

Thank you for any information.

/cb

To address the problem, I have:

1. Used old.protonmail.com to send emails
2. Begged Support for specific information that may allow me to address this with my company infosec people (all info requests refused, though they did point me to this github page)
3. Begged Support to keep old.protonmail.com active while I try to work this (refused, as of today)
4. Sent an blast to various known email addresses at ProtonMail (contact@protonmail.com, etc.) begging them to keep old.protonmail.com active. They passed the buck to Support.

Some possibly relevant facts about the behavior:

1. Same behavior on Edge and Firefox, the only browsers available in my environment.
2. Same behavior after clearing cache, rebooting, etc. etc.
3. In the new client I can:
   • Read emails
   • Search emails
   • Compose messages
   • Save messages to Drafts
4. In the new client I cannot:
   • Embed an image or add an attachment. This is not a problem -- policy prohibits file uploads and I can live without this functionality. Attempting this triggers the same web file upload block message from the security software.
   • Send an email. In the old client, version 3.x this works fine. In any version since 4.x, including the current version 5.0.1.4 beta, it triggers the file upload block message.

Thanks again for any help with this.

/cb

[bartbutler]

Hi @CraigBos , sorry for the issue.

What probably changed here between 3.x and 4.x is that sending is now done with a form data AJAX request rather than a JSON-encoded one to save 33% bandwidth and time due to avoiding base64 encoding.

This is likely what the security software is detecting as a file upload. I would talk to your security people and try to get this rule removed--there are a million ways to upload a file and a blanket block of form data seems like a really ineffective measure.

Hope that helps!

[CraigBos]

Bart, thanks for this comment -- it makes me think that even if I could pull 3.x sources and instantiate the old client locally, the server side would likely not respond to the old JSON method. Alas.

I have tried to navigate around the github page, and have found quite a bit of source code, so that's good as far as it goes.

But, can anyone point me to any higher-level design or architecture documentation? That'll be more helpful I think.

Thanks again.

/cb

[bartbutler]

I think the JSON endpoint is still there, but probably not for much longer once 3.x is retired. The bottom line is that some types of sending are very bandwidth intensive and reducing them by 33% is a big win in most cases.

Do you think it's possible for you to get your company's security software to remove that rule? It seems pretty silly anyway--if they are worried about data exfiltration literally any connection to the Internet is just as dangerous as allowing form data requests.

[bartbutler]

And yes, there are other ways to do binary uploads (BSON, protobuf) that may get around your particular problem but changing this to accommodate one finicky piece of security software is going to be a tough sell in terms of prioritization unfortunately.