Employed AI to explain why this feature is urgently needed to hopefully get this request needed attention and implementation.
[CRITICAL] Rich Text Email is Inherently Insecure: "Plain Text Default" for ALL Senders Implementation is Critically Needed
The Fundamental Flaw: Email was built in 1971 on a protocol (SMTP) designed for trust, not security. It assumes the sender is honest and the path is safe. In 2026, this 55-year-old assumption is catastrophically obsolete. Rich text (HTML) email layers a complex, modern rendering engine on top of this insecure foundation, creating a massive, unavoidable attack surface. The issue is not just "bad actors"; the issue is the medium itself. Every HTML email, regardless of sender, carries inherent risks that plain text physically eliminates.
Why Rich Text is Simply Insecure (The Data):
The Rendering Engine is the Vulnerability: To display rich text, your email client must act like a web browser, executing complex HTML and CSS code. This creates a direct path for Zero-Click Exploits. Recent critical vulnerabilities like CVE-2025-36918 (MSHTML) and CVE-2026-42897 (Exchange/OWA) allow attackers to execute arbitrary code simply by the email being rendered, with no click required. Plain text mode disables this rendering engine entirely, making such exploits physically impossible.
AI Has Industrialized Deception: As of July 2026, 82.6% of all phishing emails are AI-generated. These are not poorly spelled spam; they are grammatically perfect and contextually aware. Crucially, AI-generated rich text emails achieve a 54% click-through rate (vs. 12% for plain text) because they use HTML/CSS to create visual urgency (fake buttons, cloned branding). The format itself is the weapon.
Invisible Surveillance is Ubiquitous: Approximately 68% of all commercial emails contain invisible tracking pixels. These 1x1 images load automatically in rich text mode, leaking your IP address, device fingerprint, location, and read habits to third parties. This happens even with "known" senders whose accounts may be compromised or who use aggressive marketing tools. Plain text prevents any remote content from loading, guaranteeing anonymity.
AI Prompt Injection via Hidden Layers: A growing 2026 threat involves hiding invisible text (white-on-white) within rich HTML to manipulate AI email summarizers (like Copilot) into marking malicious emails as "safe." This "prompt injection" exploits the gap between what you see and what the AI reads. Plain text strips all hidden layers, ensuring data integrity for both humans and AI agents.
Trusted Senders Are Not Safe: The idea that "known senders" are safe is a dangerous myth. Accounts are constantly compromised (Vendor Email Compromise rose 66% in 2024). When a trusted contact is hijacked, their rich text emails bypass spam filters and exploit your trust. The format (HTML) allows the attacker to inject fake invoices or urgent requests that look legitimate. Security must be based on content verification, not sender reputation.
The Solution: "Plain Text Default" for Everyone We urgently request a "Secure Plain Text Default" mode that treats all incoming emails as potentially hostile, regardless of origin:
Default to Plain Text for ALL Emails: Automatically strip HTML, CSS, and remote images from every single incoming message. This neutralizes rendering exploits, tracking pixels, and hidden injection attacks at the source.
Per-Message "Load Rich Text" Toggle: Provide a prominent "Load Rich Text" button for users to manually enable rendering on a per-email basis only when absolutely necessary (e.g., complex invoices). This forces a conscious security decision.
Safe Attachment Handling: Ensure attachments (PDFs, docs) remain accessible via a sandboxed viewer even in plain text mode, as the risk lies in the HTML body/scripts, not the attachment file itself.
Conclusion: Rich text email is a legacy liability in a 2026 threat landscape defined by AI automation and zero-click exploits. The 1971 trust model is broken; code execution via email rendering is the new normal. A "Plain Text Default" is not a regression; it is the only logical defense against a protocol that was never designed to be safe.
Please urgently prioritize these critically needed feature to align Proton Mail with the reality of modern cybersecurity.
Anonymous
Employed AI to explain why this feature is urgently needed to hopefully get this request needed attention and implementation.
[CRITICAL] Rich Text Email is Inherently Insecure: "Plain Text Default" for ALL Senders Implementation is Critically Needed
The Fundamental Flaw: Email was built in 1971 on a protocol (SMTP) designed for trust, not security. It assumes the sender is honest and the path is safe. In 2026, this 55-year-old assumption is catastrophically obsolete. Rich text (HTML) email layers a complex, modern rendering engine on top of this insecure foundation, creating a massive, unavoidable attack surface. The issue is not just "bad actors"; the issue is the medium itself. Every HTML email, regardless of sender, carries inherent risks that plain text physically eliminates.
Why Rich Text is Simply Insecure (The Data):
The Rendering Engine is the Vulnerability: To display rich text, your email client must act like a web browser, executing complex HTML and CSS code. This creates a direct path for Zero-Click Exploits. Recent critical vulnerabilities like CVE-2025-36918 (MSHTML) and CVE-2026-42897 (Exchange/OWA) allow attackers to execute arbitrary code simply by the email being rendered, with no click required. Plain text mode disables this rendering engine entirely, making such exploits physically impossible.
AI Has Industrialized Deception: As of July 2026, 82.6% of all phishing emails are AI-generated. These are not poorly spelled spam; they are grammatically perfect and contextually aware. Crucially, AI-generated rich text emails achieve a 54% click-through rate (vs. 12% for plain text) because they use HTML/CSS to create visual urgency (fake buttons, cloned branding). The format itself is the weapon.
Invisible Surveillance is Ubiquitous: Approximately 68% of all commercial emails contain invisible tracking pixels. These 1x1 images load automatically in rich text mode, leaking your IP address, device fingerprint, location, and read habits to third parties. This happens even with "known" senders whose accounts may be compromised or who use aggressive marketing tools. Plain text prevents any remote content from loading, guaranteeing anonymity.
AI Prompt Injection via Hidden Layers: A growing 2026 threat involves hiding invisible text (white-on-white) within rich HTML to manipulate AI email summarizers (like Copilot) into marking malicious emails as "safe." This "prompt injection" exploits the gap between what you see and what the AI reads. Plain text strips all hidden layers, ensuring data integrity for both humans and AI agents.
Trusted Senders Are Not Safe: The idea that "known senders" are safe is a dangerous myth. Accounts are constantly compromised (Vendor Email Compromise rose 66% in 2024). When a trusted contact is hijacked, their rich text emails bypass spam filters and exploit your trust. The format (HTML) allows the attacker to inject fake invoices or urgent requests that look legitimate. Security must be based on content verification, not sender reputation.
The Solution: "Plain Text Default" for Everyone We urgently request a "Secure Plain Text Default" mode that treats all incoming emails as potentially hostile, regardless of origin:
Default to Plain Text for ALL Emails: Automatically strip HTML, CSS, and remote images from every single incoming message. This neutralizes rendering exploits, tracking pixels, and hidden injection attacks at the source.
Per-Message "Load Rich Text" Toggle: Provide a prominent "Load Rich Text" button for users to manually enable rendering on a per-email basis only when absolutely necessary (e.g., complex invoices). This forces a conscious security decision.
Safe Attachment Handling: Ensure attachments (PDFs, docs) remain accessible via a sandboxed viewer even in plain text mode, as the risk lies in the HTML body/scripts, not the attachment file itself.
Conclusion: Rich text email is a legacy liability in a 2026 threat landscape defined by AI automation and zero-click exploits. The 1971 trust model is broken; code execution via email rendering is the new normal. A "Plain Text Default" is not a regression; it is the only logical defense against a protocol that was never designed to be safe.
Please urgently prioritize these critically needed feature to align Proton Mail with the reality of modern cybersecurity.