Privacy: Mailspring loads assets on view even with "automatically load images" unchecked

Bug Reports
#1

Description

Apparently Mailspring loads things like CSS and JS in its viewer? The option for disabling “automatically load images” should be changed to “automatically load assets” and modified to include all assets over remote connections.

I have found that an email containing a remote CSS asset will still load that CSS asset, thus giving spammers or advertisers a means to track the email read.

Aside from this, its probably a bad idea to allow CSS/JS assets to load at all. AND the default should be DISABLED loading of assets. (default security & privacy first?)

To Reproduce…

  1. Disable “automatically load images”
  2. Enable firewall (like little snitch) or load wireshark
  3. Click on email with remote css asset and watch the asset attempt to load. Paypal and Ebay emails are good candidates to trigger this as they both inject css/js into their emails even though its considered bad practice.

Expected Behavior

Other mail clients use the vernacular “automatically load images” because they do NOT EVER load css/js. You might want to consider following that suit. But if not, then you might want to change the concept from “images” to “remote assets” (since local embedded images should load fine)

Screenshots

This screenshot shows Little Snitch asking if we should allow a connection when viewing a paypal email. Note from the top of the paypal email you can see the UI indicating that automatic loading of images is disabled.
image

Setup

  • OS and Version: Mac 12.4
    • Installation Method: Installer / DMG
  • Mailspring Version: 1.10.3

Additional Context

Related to this bug which also breaks Privacy in Composer

#2

100% agree. If it’s true that Mailspring downloads and executes remote JavaScript, that’s a major security vulnerability. What the actual fuck?

@mailspring devs where ya at, can you clarify this?

#3

If it’s true that Mailspring downloads and executes remote JavaScript, that’s a major security vulnerability. What the actual fuck?

@mailspring devs where ya at, can you clarify this?

Not a dev :stuck_out_tongue_winking_eye:

Looks like the JS issue was fixed in v1.10.6

1 Like
#4

Thank you so much for letting me know about that. I’ve been freaked out ever since the news. Turns out I am on 1.10.7, so I have the fix. Phew. Mailspring no longer scares me to death!

I checked what the fix actually did. So I can see that the email is displayed in an iframe, and they added the sandbox attribute:

sandbox="allow-forms allow-same-origin"

Let’s look at MDN’s description of it:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox

“Applies extra restrictions to the content in the frame. The value of the attribute can either be empty to apply all restrictions, or space-separated tokens to lift particular restrictions:”

allow-forms: Allows the resource to submit forms. If this keyword is not used, form submission is blocked.

allow-same-origin: If this token is not used, the resource is treated as being from a special origin that always fails the same-origin policy (potentially preventing access to data storage/cookies and some JavaScript APIs).

So to sum it up:

  • Without having the sandbox attribute at all, there is zero sandboxing. All scripts can run. They even seem to get access to the Electron (host) APIs. Very dangerous. Mailspring before 1.10.6 didn’t have the sandboxing attribute.
  • By adding the sandbox attribute without any value, you block everything.
  • By adding values to it, you allow certain things. They decided to allow form submissions and same-origin content, whatever that means in this context (not sure if that refers to local files or remote files).
  • They didn’t allow javascript. So all scripts are blocked inside the email iframe now.

So at a glance, everything seems good now. I don’t understand why it has to allow form submissions and same-origin stuff inside the email, but it’s probably well thought out and reasoned about already. :smiley: