Base64 encoded images not displayed in Markdown cells

[philippjfr]

This change breaks many our notebooks which have base64 encoded SVGs and PNGs in them. For instance, here is a notebook published by a colleague, listed in the official gallery: GCAL notebook (see for instance, the figure under the heading 'Sheet Definitions').

The ability to use base64 in Markdown cells was one of the primary features that made the notebook format useful. A single .ipynb file could hold both dynamically generated or statically embedded (i.e base64) content. Having to bundle files together with the notebook (or having to put all the linked files online) dampens the appeal and damages the utility of notebooks.

It is important that the raw base64 encoding is not displayed as the encoding itself is typically very long and useless to look at. The %%HTML and %%SVG magics aren't very useful for this reason as they only apply to code cells which show all content. For simply displaying static images, there should be no need for code cells which is one reason why allowing base64 encoding in Markdown cells was so useful.

I understand that this change was made as part of a redesign of the security model of IPython Notebooks and it seems reasonable to disallow execution of Javascript and CSS by default but using the data URI doesn't pose any greater security issue than embedding an image files from a URL. There is currently this Issue filed on Google Caja, which aims to discuss support for data URIs and the consensus there too seems to be that this should be safe and supported.

I'd greatly appreciate if this feature could be brought back or an alternative, allowing inlining of base64 images, could be offered.

[minrk]

Thanks, we'll keep an eye on that issue in Caja. I don't see a good reason why non-js data URIs are excluded, assuming they are sufficiently distinguishable.

[philippjfr]

I should have mentioned that SVG is also completely unsupported by Google Caja (see this issue).

I just commented out the Caja sanitization in security.js and everything seems to work so would it be possible to provide a flag in the IPython notebook profile to disable it, at least until they address these issues?

[minrk]

You can disable sanitization in custom.js with:

IPython.security.sanitize_html = function (html) { return html; };

[jlstevens]

It is good to hear that there is a reasonable way to disable HTML sanitization. To better understand the problem, I've gone through all my notebooks to check for inline HTML and find out what else might now be broken by default.

The release notes state that "HTML and Javascript in Markdown are never trusted". This is a little misleading as some HTML elements do seem to work - thankfully! The Twitter Bootstrap tags still work (e.g. various alerts, description lists) as do anchor tags (which I've needed to link to headings containing spaces).

As Markdown is only appropriate for very simple formatting tasks, it is important that these additions to the basic Markdown syntax continue to work. I'm sure I am not the only IPython user that relies on these extra tags to make Markdown cells more useful.

Inline base64 encoded raster images and SVG definitely do not work with sanitization enabled. Even if data URIs become supported by Google Caja, this still won't allow for inline SVG images. The %%SVG magic would be viable if you could just hide the contents of the code cell - there is way too much content in a typical SVG to always be displaying the raw contents. Is this feature still planned for a future release?

As notebooks containing inline SVG (which include base64 rasters) have already been committed to the Topographica project, we will have to supply a custom.js file to work around this issue (should we plan to support IPython 2.0). We will probably be forced to disable HTML sanitization until we find a sensible, alternative approach that allows inlining of SVGs.

Thank you.

[minrk]

The release notes state that "HTML and Javascript in Markdown are never trusted". This is a little misleading...

The relevant bullet points are:

• untrusted HTML is sanitized
• HTML in markdown is not trusted

That means that the HTML in markdown is sanitized, not that it is entirely removed. HTML that Caja considers safe will work just fine. I will try to add some clarification that sanitization != removal to the doc.