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

From: Jean Louis <[email-masked]>
Date: Thu, 27 Oct 2022 21:25:49 +0300

* Max Nikulin <[email-masked]> [2022-10-27 18:41]:
> Chromium is able to display text/x-org internally just as text/plain and I
> like it as a way to preview and review file contents.

Org file is for Emacs. It is not for Chromium.

Just as you can display application/json in Chromium as text, does not
make application/json less "application/*" MIME type.

Displaying Org in Chromium is useless, as I cannot use Org features,
Chromium is not for that, and it's not suitable example.

Suitable example is that Chromium may be configured to open Org file
correctly with Emacs and as you have mentioned, there will be executions.

> I have not managed to configure Firefox to achieve the same behavior
> that allows to avoid an external application (certainly not Emacs at
> first).

I wonder on which mailing list I am.

Of course I want Org file be opened by Emacs. I am user of Org
files and Emacs. I am not vim user (unless Emacs flunks).

> > We can't just speak of safety alone when we are in general
> > computing environment, we must also speak of usefulness.
> 
> I do not mind to have org-view-mode that saves me from execution some code
> unintentionally. Since most of the code was written without having in mind
> such feature, I expect a lot of iterations before all possibilities to run
> code will be plumbed. I suspect that it is possible to ruin whole protection
> by a small piece of elisp code. I am unaware of sandboxing in Emacs. I
> expect that making Org mode safe enough will require a lot of efforts by
> developers.

Exactly.

> Your are pushing Org to rather hostile environment: highly automated
> attacks to distribute exploits, market of breached computers
> listening for remote commands.

Tittle-tattle. 😵‍💫 But America has been already discovered.

Remember, any type of application, software, is already for billions
of times delivered by Internet and executed on user's devices.

Flatpak, APK, EXE files, Java, shell files, hoooooo, too long
list. And where we are now? In Emacs world, where packages are
distributed from all kinds of sources and executed on users's
computers. 

"Pushing Org" to rather hostile environment is exaggeration.

> A running cryptominer would be rather innocent consequence, through
> the same backdoor you may receive an encryptor or various stuff
> searching for credentials and access tokens in your files.

Of course I understand that.

Do you wish to say that users should not have the freedom to customize
web browser to click on Org file and open it with Emacs?

Are we not on Emacs related mailing list?

If I am pushing Org into hostile environment, than you are implying
that we as Org users are hostile environemnt. Are we really?

> Emacs is protected mostly by its low popularity. A lot of efforts
> have been invested in browser making attacks more expensive, but
> still attractive due to possible benefits. I do not like to increase
> surface for attacks. Someone may create a plugin targeting Emacs
> users just because it would be easy enough.

And? 

> Consider converting Org files to HTML as an unpleasant tax for the
> sake of safety.

Personally, definitely not. Such files do not give me freedom to work
with my Org data. It is way of presenting things, not handling it.

> > All I want is to access my personal read-only Org files by using WWW
> > and browse from one to the other by using links.
> 
> How are you going to distinguish your personal files and arbitrary files
> from non-trusted sources? By signing your files and maintaining list of
> trusted certificates?

🤣 Am I Joe Biden or other gaga that I do not know what are my files? 

> For personal notes I would expect e.g. private instance of nextcloud
> file share (that is internally HTTP server), not accessing files
> directly through HTTP.

HTTP is transfer protocol, not my mamma to tell me what I am going to
transfer in my room.

Nextcloud is application that runs on computer and is served by web
server. It allows file share to public as well. 

I understand your point of protecting private files on web
server. That shall be natural to every person hosting such
files. Nextcloud is bloated way to do such hosting.

Simplest way to protect files is to upload files and use web server
authentication.

And web server does not mean that files are distributed on public
WWW. We use here ethernet, and we share files from device to device by
using HTTP server. You can't access those files, they are beyond
public IP address space.

I need help to make it work right, can you help?

I load this:

(defvar eww-content-type nil)
(put 'eww-content-type 'permanent-local t)

then I put this below in `eww-render' after (let

;;; (setq eww-content-type content-type)

Then I use this:

(defun rcd-eww-content-type ()
  (cond ((string-match-p "text/x-org" (car eww-content-type)) (org-mode))
	 (t WHAT-HERE?)))

(add-hook 'eww-after-render-hook 'rcd-eww-content-type)

But I am doing it wrong, that will correctly invoke org mode, but then
it does not return back to normal EWW work. I have tried to remember
the major mode and invoke it again. But it is not that it works.

-- 
Jean

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

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