Mailinabox: Migrate away from CDNs hosting the CSS / Font / JS assets

Created on 12 Oct 2014 · 15Comments · Source: mail-in-a-box/mailinabox

Wearing my slightly paranoid / infosec / privacy hat for a moment- I noticed that currently the /admin area of Mail-in-a-box serves all the front-end assets from numerous CDNs

It would be nice to have these assets served locally from my trusted Mail-in-a-box server instead of via CDN. There will be a very tiny performance hit the first time I access my 'box but then caching will take care of it. I believe the privacy / security implications far outweigh the performance.

I'm happy to send a pull req with this modification if you agree @JoshData

Source

bnvk

👍1

Most helpful comment

In 0.16 this is still an issue. It still requests CDN versions of at least jQuery and Bootstrap. Adding integrity check does not solve all problems with CDN versions of libraries. For example, every time those libraries are not obtained from cache, Google finds out what site is using them through the Referer/Origin header.

If those libraries are self-hosted (and inline scripts moved to files) a really strict CSP [1] can also be used to further secure the user.

[1] https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Using_Content_Security_Policy

fkooman on 1 Feb 2016

👍5

All 15 comments

Completely agree.

But I also don't want to bloat the repo with these resources. What do you think about downloading them during install time? (We could even check that their hashes are correct after downloading.)

Also not sure if google fonts can be (are allowed to be) downloaded. We can just use the system sans-serif if that's easier.

JoshData on 12 Oct 2014

Nice idea. Agree

jonaslejon on 12 Oct 2014

@JoshData I agree, downloading the files during install + verifying with hashes would be better than the current situation, IMHO. I know you can download fonts from Google's webfont website, not sure about automating those downloads.

However, another point towards bundling them in the repo is that it
would allow from-end devs like me to do more custom changes to CSS
styling and UX'y things.

With Mailpile, I use the http://bower.io package manager for front-end
dependencies (like the entire Bootstrap framework), I then compile down
the final files that the app includes, thus the repo only has 5 or so
files and thus no real bloat.

bnvk on 12 Oct 2014

Too complicated. :)

JoshData on 12 Oct 2014

@JoshData what part is too complicated? I'll happily do it for you and write the docs for other front-enders. Otherwise, I guess you don't want front-end UX help?

bnvk on 12 Oct 2014

Seeing how Mail in a Box is about privacy, I don’t see how putting these small CSS, JS and font files directly into the repository would be considered »bloat«.

Both downloading them during the install process or using Bower is too complicated. Just put them in here directly.

jancborchardt on 27 Oct 2014

Oh I didn't even see @brennannovak's reply, sorry.

bower and putting the resources directly into this repository are a no-go.

A wget in setup/management.sh would be fine. Something more complicated that also checks the resource against a known hash stored in this repo would also be nice (could be via a git clone). Bringing in google fonts locally is difficult, so we could drop the custom fonts for now.

JoshData on 27 Oct 2014

Ok, wget should work then.

It’s still strange though since there will always be at least one request to the CDN then. And that kind of clashes with what you say you want to achieve with Mail in a Box (emphasis mine):

Promote decentralization, innovation, and privacy on the web.

jancborchardt on 27 Oct 2014

There's always a request to _somewhere_. If it's not to the CDN, then it's to github.

These goals are all on a continuum and need to be balanced with the other goals.

JoshData on 27 Oct 2014

Just catching up on this thread. @jancborchardt I think @JoshData means there will always be "a request to somewhere" to initially grab the front-end resources since he's opposed to including them in the repo.

As Josh suggested, using wget and hashes will minimize the security danger. Myself (and probably others) would see this as a big win.

bnvk on 28 Oct 2014

+1! Yes, please.