Re: PDF alternative using HTML (proposal)

On 18 Jan 2016, at 22:14, James May <whatwg@fowlsmurf.net> wrote:
> I think perhaps you dismiss MHTML to quickly ;)


Kind of... it does work, but the tools to create the files are not great, as it uses the same encoding method as an email.

For example, today if you are developing an actual email to send (e.g. marketing), then you generally build it with a HTML/CSS template, with images in a folder, but you then need to use a specific tool to convert that into the correct format for email (i.e. it needs to encode resources, and read/edit the HTML/CSS to change the resource paths).

Whereas this format is just simply a zip of a folder.

Also, MHTML is already established in a way that means it has no concept of a sandbox, so it can still reference resources outside of itself, nor apply any further limitations (e.g. scripting) so it will still be seen as potentially malicious.

And finally, a couple of minor points... it's not compressed, nor is it easy to password protect the content (which ZIP/GZIP can provide already).



> I think careful application of CSP headers could allow safe hosting of arbitrary content.



It would if hosting from a website, but the idea is to have a document that can be emailed and saved (archived), so headers won't really exist.

And as mentioned above, ideally this format would be locked down for every document, so network/computer administrators can trust it (whereas an optional header does not do this).

So in a way, the CSP mechanisms (already in place), would be applied by the browser for every single one of these documents.



> Well, S/MIME exists.


Good point :-)






> On 18 Jan 2016, at 22:14, James May <whatwg@fowlsmurf.net> wrote:
> 
> On 12 January 2016 at 21:54, Craig Francis <craig@craigfrancis.co.uk> wrote:
> [...]
>> Unfortunately you can't just email a HTML document to someone, as this
>> causes a range of security problems, and including resources can be
>> difficult (you can inline them, or use MHTML, but these are tricky to
>> create).
>> 
>> So I was wondering if we could take the approach that Microsoft Word did
>> with the docx format, Java with JAR, PHP with PHAR, etc...
> 
> I think perhaps you dismiss MHTML to quickly ;)
> 
> I'm not sure what advantage using a ZIP container has over the
> multipart MIME container -  They are already supported by IE for
> reading and writing, with Chrome support behind a flag and Firefox via
> an extension[1].
> 
> I'm also not sure why a ZIP container would make it any easier to
> generate or "self-contain"arbitrary content. For new content intended
> to be delivered this way it obviously wouldn't be a problem.
> 
> [...]
>> Then from a security point of view, it can be locked down to its own little
>> box, so no access to other files on the file system, probably no access to
>> cookies/localstorage, no ability to connect to another host (maybe).
> 
> I think careful application of CSP headers could allow safe hosting of
> arbitrary content, but I'd imagine that specifying/enhancing the
> security model of web hosted MHTL files to make it safe 'by default'
> would be desirable.
> 
>> And from the users point of view, the document could be protected with a
>> password (a feature that ZIP/GZIP provides already, and the browser can
>> prompt for when opening).
> 
> Well, S/MIME exists.
> 
> -- James
> 
> [1] https://en.wikipedia.org/wiki/MHTML
> 
>> 
>> So would this help with the security aspects of emailing HTML files to
>> people (e.g. reports), and be better than PDFs?
>> 
>> Craig
>> 
>> 
>> https://code.google.com/p/chromium/issues/detail?id=575677
>> 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1237990
>>

Received on Tuesday, 19 January 2016 11:46:01 UTC