Re: bug#58774: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly

[Tim Cross]

Stefan Kangas <stefankangas@gmail.com> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> The "problem" with shell links you are describing is a question of
>> setting variables and is also disabled by default.
>>
>> eww-mode, when loading Org page, could simply set
>> org-link-shell-confirm-function to its default value.
>
> Note that with the suggested feature, any link you follow risks being
> loaded in Org mode, before the user even has a chance to inspect the
> file.  Which Org features, currently existing or introduced in the
> future, would EWW have to add workarounds for?
>
> It is very hard to foresee which parts of Org will be problematic and
> have to be disabled.  See the security vulnerability in enriched-mode
> that prompted the release of Emacs 25.3, for example.
>
> Adding this opens a can of worms that will expose unsuspecting users to
> a whole class of new problems.  And the only benefit is to save some
> users from having to type "M-x org-mode RET", or adding call to a
> suitable hook.
>
> All in all, this seems like a bad trade-off.  So I don't think we should
> add such a feature.

This concern seems to be based on FUD rather than any real or identified
risk.

The risk here is no different to risks associated with opening any org
document from a foreign source e.g. in an ELPA package. Note that org
mode's default configuration wrt code execution is to ask the user for
permission to execute. If the user can run M-x org-mode on eww buffer
containing a text file which is an org file, the same risks apply and
any vulnerability would need to be addressed anyway.

This is also very different to the issues encountered with enrich text
some years back. The problem then was with elisp code embedded in text
properties. It was a bug in how enriched text processed the data. 

However, I think we are probably looking at this problem from the wrong
level. It isn't really about how to get eww to render org files in
org-mode. This issue is really about being able to customize what
function is called to 'render' the data retrieved based on the
content-type header of the content.

Currently, it is fairly straight-forward to define a custom handler
based on the URL, but not based on content-type. Being able to easily
associate a function to handle downloaded content based on the
content-type would be useful. Users could then easily add whatever
functionality they wanted based on what the server told them about the
content type.