FAQ: Why does Elgg remove images embedded via WYSIWYG?

Aside: We get this question a lot, and I'm trying to work up content for the wiki docs.


In some browsers users can drag/drop an image into the WYSIWYG editor, which embeds the image data into the HTML as an IMG element with a Data URI. Elgg processes user-provided HTML through a security filter called Htmlawed before saving and displaying it to other users. Older versions of Htmlawed (in old Elgg versions) allowed Data URIs to be used, so Elgg used to display those images in the saved page.

However, due to the risk that unsafe content could be embedded via Data URI, Htmlawed removed support for them, and so these features stopped working in later Elgg versions, too.

What can be done?

With a whitelist of acceptable image Content-Types, Elgg could safely accept Data URIs, but there are caveats:

  1. This would require pre- and post-processing to allow the data safe passage through Htmlawed.
  2. Data URIs store image data very inefficiently.
  3. Some browsers may break the data URI during editing.
  4. In a site that does not allow file uploads, this would allow image hosting via any form field that accepts HTML, so it's not clear all Elgg site owners would appreciate this feature.
  5. Unlike uploaded files, embedded images cannot be directly manipulated for resizing, etc.

We could also dynamically convert an embedded image to a file as if the author uploaded it separately. This functionality would come with its own set of caveats and policies that need to be determined (what title and access level to use?).

For these reasons I think it's unlikely that Elgg will support WYSIWYG embedded images out of the box, but we can assist plugin authors to provide this functionality.

  • my 'personal' opinion - judging from the rather not-so-overflowing demands (other topics posts) for that data uri scheme (data:image)... too much trouble to satisfy too few users' 'wanteds' features. the benefits vs disadvantages @ data uri seem kinda balanced.. except -- the (big) http request loads truncation vs the security fanagling headache!

    i cannot find *any cms/platform that caters for this data uri embed/convert ;-) technicallly - can be done; reality.. is it worth the effort ? like those css stds compatibilty issues @ie 4,5,6,7,8..?! i' actually (foolishly) spent some time thinking of (not-so-quirky) design issues to parse out image:data data portion to create Files' object, embed properly, yadda.. yadda.. [ just needs to extract, undo base64 or octets; create file; code proper img src= ]. but then stopped to think -- *maybe - if 10-5% of the (elgg) downloaders (70K?) asked for such a feature, but not quite for a mere <= handful of wishes ;-Ptoo much code and too many side-issues.

    the http request bandwidth savings might still give this some attraction for other uses -- sprites, buttons, builtin imgs, internal images ?! many small files? could might do 1/4 magic for page-load speeds...hmmm ;oO