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

From: Jean Louis <[email-masked]>
Date: Wed, 26 Oct 2022 21:37:15 +0300

* Max Nikulin <[email-masked]> [2022-10-26 20:10]:
> If you were just requested mapping of Content-Type to some mode in
> eww, perhaps it would pass.

That is exactly what I need, thanks

> You demanded Org mode configured by default.

Hmm, that could be some misunderstanding. I have .mailcap file and I
know I can configure any browser to open any content type how I wish
and want.

My e-mail client Mutt is opening Org files sent by Sacha Chua in org
mode with Emacs. It is my choice as user to skip downloading such
files and inspecting them.

If Mutt supports me, and Iceweasel, to open Org files with Emacs, why
not Emacs's EWW cannot support me to open Org files with Emacs??  

That is completely not logical.

That is what I need and expect from EWW, it is more general and more
useful to let user customize any content type to be opened how user
wish and want.

This is because in Org files I may have links and wish to open
Gnumeric spreadsheet.

For example, if I get text/markdown (or equivalent) it would invoke
Markdown mode, for Org mode, it would invoke Org mode.

> Org have enough means to execute arbitrary code with minimal efforts
> from user side.  E.g. value of table cell may be recalculated.

Those are not issues of EWW, but of Org mode in general. Similarly,
I can open spreadsheets by using Libreoffice or Gnumeric and such
spreadsheets can execute macros, I do not know how "dangerous" it is,
but that is my choice to decide upon it.

Browser like EWW, being able to accept content types, should give to
user the option to decide if to open PDF file by integrated PDF viewer
or any external PDF viewer, or to download the file, or to open the
file by user's customized function, mode or program.

Setting up content types is freedom for users to do what they want
with files. 

The security aspect is in this moment highly hypothetical as victims
are not there. And it is matter of Org mode in general.

Is there much of difference of opening Org file by using EWW or
sending link to Org file to be downloaded and THEN opened by Emacs?

User not knowledgable may execute arbitrary code anyway.

Please do not blame the communication channel and users how some Org
feature is unsafe.

That is Org security issue, and not EWW issue.

HTTP is for delivery of files.

What user does with files is user's choice.

In general any Emacs package offered for download is in general
security risk, and we freely recommend them to each others. It is
quite clear that it is not safe executing software which one does not
understand or cannot decipher.

https://www.gnu.org/software/emacs/manual/html_node/efaq/Security-risks-with-Emacs.html

Me, as user, I am totally free to configure WWW server to serve
something like "application/e-lisp" as content type, and to open that
type with `emacs --batch file.el' if I want. 

"Insecurity" is thus integral part of user's choice.  

As Ihor and others mentioned, then it will be maybe up to user to use
Org safe mode or similar.

That is not business of web server, HTTP or browser. Those are
delivery, retrieval and presentation tools

> Org files originating from non-trusted sources must be carefully
> evaluated before opening them in Emacs.

Same applies to ANY kind of files that may be inherently
insecure. While HTML is considered secure, Javascript less than HTML,
but still contained, there are many many content types that may be
insecure, startin with APK, proprietary sotware, EXE Windows files,
any kind of programming languages, plugins, etc. Warnings are
everywhere. 

Let users decide what is trusted or non trusted source. 

Programmers of free software shall give users freedom.

I have full freedom to download Emacs Lisp packages and execute them
on my computer. That is same. I just want it faster.

And I also want it executed. I find it excellent that I can instruct
web server to serve me Emacs lisp which I can then execute, great. It
may not be your common usage scenario to find any use of it. I do.

There is freedom to configure browser to open packages and install
them right away, without inspecting anything. 

In proprietary software world that is exactly what billion of people
already do, they download and execute proprietary software, there is
plethora of insecurity issues there.

That is up to Org mode to solve.

It is similar to Emacs warning you about local variables. So put some
warnings in Org mode.

But do not blame browser.

Browser is download, presentation and forwarding tool.

In Firefox, Content type that otherwise is not configured in browser,
may be either saved by default or browser may ask user how to open it
by default.

It is users' decision if something is safe to open or not.

I am sure that safe Org mode will solve that issue. 

Instead of speaking hypothetically of insecurities about delivering
Org mode over HTTP, let us look at numerous advantages of it, they are
analogous to WWW HTML files:

- Publish your Org notes on WWW, and use them from anywhere in the
  world, from any device running Emacs; remove cache if any in EWW,
  and files are gone; privacy preserved;

- Use your Org files from any mobile device running Emacs; I have too
  many of them and in that case I need not synchronize it at all;

- Fetch Org style reports, templates, and workflows, modify and report
  back to manager;

- Browse from Org file to Org file, create Dynamic Knowledge
  Repositore that staff members, group members may access and deal
  with it;

- Automatically publish Org agenda, Org files directly, without
  export, to WWW servers, and access from remove places;

- HTTP offers authentication mechanisms to protect private data;

I do not have special opinion of "publishing Org files" for unknown
people, if such people are not member of the group. That would require
training them to know what is Org mode, and finally why? Emacs is poor
general browser tool.

Greatest benefit of Org files being served and properly parsed by
Emacs by using HTTP is personal and group based. It is not mainly for
public use. 

But one could think of it being analogous to Gemini.

https://gemini.circumlunar.space/

Public who does not use Emacs will not be interested in such.

They may download Org files and open it from file system. Same
insecurity exists by downloading them and opening them.

> Sometimes Org developer and maintainers do not have enough resources
> to react to security-related reports. An issue not so dangerous in
> the current state becomes really weird if Org mode becomes a default
> handler for files fetched from net.

Your interpretation is improper, as you mentioned "default handler for
files fetched from net" -- and I was very specific, for text/x-org
content type that EWW get possibility to invoke org mode on such
files.

Quite logical. Emacs, Org mode and EWW, those shall work together. I
am surprised that it does not.

At least Russian Nginx WWW server supports me as user to configure it
so to serve Org files as text/x-org.

Though personally I have already found buggy solution with Emacs Lisp
modification to eww render function. I must improve it.

> You may fight for your right to freely shoot your legs but you must
> be careful enough to not injury people around. Reputation of Emacs
> may be significantly affected by the requested change.

What a dramatic exaggeration! Congrats.

> I am strongly against Org mode as a default handler for files
> downloaded from web sites. Eww user option, if implemented, should
> have prominent warning that particular mode may not be ready for
> such usage and each case should be carefully evaluated for security
> issues.

Default handler is not necessary. 

It is enough if users can set up how to open different content types
by which application or by which mode. It is now more general
question, like why I cannot invoke Gnumeric on gnumeric files, or
Libreoffice on spreadsheet delivered by HTTP?

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/