Closed Bug 1101485 Opened 10 years ago Closed 6 years ago

[email] Support "view source" view for HTML messages

Categories

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Product:
Firefox OS Graveyard
Component:
Gaia::E-Mail
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: andre.jaenisch, Unassigned)

Details

(Keywords: feature) 

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141113143407

Steps to reproduce:

Some services (like Mozilla) tend to send newsletters in fancy html style.
I'd prefer to view them in text/plain to guard against myself against loading of resources like tracking pixels or drive-by attacks.

Alcatel OneTouch Fire running v1.3.


Actual results:

When I open a HTML-styled mail, Firefox OS interprets it as a website and renders HTML.


Expected results:

I'd like to have a preference for view. I want to configure, that by default, emails should be displayed as plain text with an option to switch to html view.
Can you clarify your request slightly?  Specifically:

- Is this a request to implement something equivalent to Thunderbird's "View... Message Body As... Plain Text" which uses a (not entirely great) mechanism to parse the HTML and attempt to produce usable text output from it?  Or do you just want us to favor text/plain over text/html in multipart/alternative?

- Can you elaborate on what you mean by drive-by attacks?  I'm assuming your goal is to be able to reduce the attack surface by cutting out as much of the rendering/layout/etc. logic.  But this is related to the prior question since we inherently need to parse the HTML to generate a text representation, and to a good job at it CSS might need to be processed to a lesser or greater extent.


Do note that we already require the user to click the "show remote images" bar before we will load any external resources.  And our sanitizer gets rid of non-image loads.  Any network accesses we perform from loading an image prior to the user hitting "show remote images" is a bug and we will treat it as such.
Hello, Andrew,

I don't want the app to interpret/format the email, but display it as is.
Example:

Newsletter from 14th Nov 2014 in HTML view:
"Hello all,
Today we announced our first two launch partners for sponsored Tiles in Firefox: CVS Health and Booking.com on the Advancing Content blog - blog.mozilla.org/advancingcontent/2014/11/13/announcing-firefox-tiles-going-live-today/."

Same one in plain text:
<html><html>
 <head>
 </head><body>
 
  <table width="100%" cellspacing="0" cellpadding="0" border="0" align="center">
   <tbody>
    <tr>
     <td valign="top" bgcolor="#ffffff">
     <table width="600" cellspacing="0" cellpadding="0" border="0" align="center">

      <tbody>
       <tr>
        <td style="font-size: 10px; line-height: 1.25;">
        <table width="600" cellspacing="0" cellpadding="0" border="0" class="headerTable">
         <tbody>
          <tr>
           <td>
<table cellpadding="0" cellspacing="0" border="0" bordercolor="" width="100%" bgcolor=""><tr><td><table  width="100%" bgcolor="#ffffff" border="0" bordercolor="" cellpadding="5" cellspacing="0"><tr><td style="font-family:Arial; font-size:13px"><p id="text-placeholder" style="margin-top: 0px; margin-bottom: 0px;"><span class="" style="font-size: 15px; font-family: Arial; vertical-align: baseline;">Hello all,</span>
      <br class="" />
      </p><div class="" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;"><span class="" style="font-size: 15px; font-family: Arial; vertical-align: baseline;"><span class="Object" id="OBJ_PREFIX_DWT2262_com_zimbra_date"><span class="Object" id="OBJ_PREFIX_DWT2276_com_zimbra_date">Today</span></span> we
          announced our first two launch partners for sponsored Tiles in
          Firefox: CVS Health and&nbsp;<span class="Object" id="OBJ_PREFIX_DWT2263_com_zimbra_url"><span class="Object" id="OBJ_PREFIX_DWT2277_com_zimbra_url"><a href="http://booking.com/" class="" target="_blank">Booking.com</a></span></span>
          on the <span class="Object" id="OBJ_PREFIX_DWT2264_com_zimbra_url"><span class="Object" id="OBJ_PREFIX_DWT2278_com_zimbra_url"><a href="https://blog.mozilla.org/advancingcontent/2014/11/13/announcing-firefox-tiles-going-live-today/" target="_blank" class="">Advancing
            Content blog</a></span></span> - blog.mozilla.org/advancingcontent/2014/11/13/announcing-firefox-tiles-going-live-today/.

I know, it's unreadable. That's the point, why I asked for an optional switch to HTML view.
I assume, the most users won't be happy with raw text.
But for developers and others, it would be cool to tell the app, to prefer the plain text view over html.

With drive-by attacks, I'm refering among others to links hidden behind a tracking URL, which marketers like to use to measure conversion and the like.
You can read https://blog.mozilla.org/community/2014/10/02/a-new-look-for-our-community-newsletter/ or https://en.wikipedia.org/wiki/Email_tracking#Email_marketing_and_tracking to get an idea …

I'd like to see that upfront.

Am I assuming right, that JavaScript cannot be executed from within a HTML mail?
That is: What would happen if I compose this mail:
<html><head></head><body><script>alert('Buhahaha!');</script></body></html>
There is a sanitization process for the emails to strip out things like scripts, possibly bad CSS, provided via a fork of bleach.js:

https://github.com/mozilla-b2g/bleach.js

and to protect in any potential sanitization misses, the iframe is created with a sandbox attribute that does not allow scripts to run inside of it. Lots of gory details in the iframe_shims.js:

https://github.com/mozilla-b2g/gaia/blob/master/apps/email/js/iframe_shims.js

Images are not loaded by default to avoid the tracking beacons, and all link clicks prompt the user to confirm they want to go to the link by showing the link, before actually navigating to it.

There are more details in the recently filed bug to track improvements in the underpinnings of HTML email display in bug 1102469, the background on the motivations and goals for HTML email are in that bug if that helps.

I expect it will be unlikely that there will be an option to show the plain text of HTML email, just because of the small screen and limited screen area for options. However, we definitely want to address the underlying motivations for the concerns you mention in comment 2, and the email developers want all users to have safety and to avoid tracking as best we can by default. So if you do find a bug or issue with the protections we have in place, we definitely would want to know about them.
Ah, so this is more a request for "view body source" than anything else.  I think view source would indeed be a handy tool for developers and it's also a very Mozilla thing to let people look under the hood of how markup works.

Complications:

- When I look at the message you're referring to in Thunderbird, I don't see any whitespace in the HTML message.  I am assuming you reformatted it yourself or used some type of tool that has a minimal understanding of the HTML rules (after the message was passed through quoted-printable decoding).

- "View body source" does not make sense as a default way to view a message on its own.  It seems like the type of thing that might exist as a menu option and that could then entail its own overlay card to display it.  This would make it more awkward to integrate.  If we end up adding support for pluggable message processing, view body source is something we could potentially sneak in to the secret debug menu (https://wiki.mozilla.org/Gaia/Email/SecretDebugMode) as the transform to always use.  But I don't see us adding a pluggable implementation like that for this app in the medium term.  The experimental desktop/tablet version of the app I'm thinking of, yes.

- The option to switch from the source view to actual HTML view is probably the largest complicating factor.  If you only ever wanted to see the source of HTML, there are minimal backend changes that would be required.  But undoing that change would take a lot of work.

So, as James says, this is probably not something that is likely to be implemented anytime soon.

If this is something you'd like to see across multiple mail apps, one option would be for you to use some type of server plugin to create a virtual folder for each real folder you have.  Something like an "as-source" which would claim text/html parts were text/plain parts.  Dovecot at least has a mechanism for plugins, although I don't think there's anything that would cover this use-case: http://wiki2.dovecot.org/Plugins
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: feature
Summary: View emails in plain text → [email] Support "view source" view for HTML messages
Sorry for the delay. Much to do here.

:jrburke Will this guard against XSS by setting a javascript statement as img-src? (Interesting way to attack a website, imho).

:asuth Since I run on pretty old hardware (single core …), I'm using mutt. HTML mails are dumped through lynx here.

My mail provider does grant me the privileges to change the dovecot settings :)
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.