Re: Local variables insecurities - Re: One vs many directories

[Jean Louis]

* Tom Gillespie <tgbugs@gmail.com> [2020-11-26 05:07]:
> Hi Jean,
> 
> Some points in summary before a long email.
> 1. Having an accepting default behavior as a user (i.e., saying yes to
>    all prompts) is bad security practice. The only thing that systems
>    can do is prompt as infrequently as possible in hopes that people
>    don't get prompt fatigue. Emacs does this.

I know, and do not speak for one person but for those who will not
know. To ask users who do not know programming using editor for text
editing and to assume that users will know programming terms:
variables, values, applying, safe and ANYTHING else that is written in
eval: is bad security practice.

> 2. If mutt is launching Emacs, you can pass --eval "(setq
>    enable-local-eval nil)" on the command line and all file local
>    variables will be ignored and treated as plain text.

Sure, I know, but human text editors will not know. They are faced
with YES/NO. What has to be improved is the YES/NO dialogue that has
no hyperlinks to its corresponding explanations and asks users things
with wrong assumption that user will understand them.

> 3. If people don't read the manual and don't read the prompt, there
>    isn't much more that Emacs can do while still empowering the
>    user.

Empowering can take place in the dialogue as such has enhancement
space. Do you think it is good idea?

>   In those cases we also can't assume that the community will be of
>   much help either, as we are trying to be here.

Community is of great help. Users are many and just fraction of users
are in this community for example. Only subset of users even while
being in community or reading emails or website will be participating
in such.

> 4. That said, the local variables prompt could be more alarming and
>    provide a quick way to access the manual about local
>    variables. I'll look into a patch for that.

Yes, that is it. To empower user is to give him straight better
reference on what to do.

Following places could become buttons:

The local variables list in new-concept.org
    ^^^^^^^^^^^^^^^
    Button to A below
    
contains values that may not be safe (*).
^^^^^^^^^^^^^^^                 ^^^^
Button to A below               Button to A below

Template:

Do you want to apply it?  You can type
               
y  -- to apply the local variables list.
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
         Button to A below
         
n  -- to ignore the local variables list.

!  -- to apply the local variables list, and permanently mark these
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
         Button to A
      values (*) as safe (in the future, they will be set automatically.)

  * eval : (let ((pos (org-babel-find-named-block "stages"))) (when
    pos (save-excursion (org-with-point-at pos
    (org-babel-execute-src-block)))))
    ^^^^^^
    Button to A below.

The template how it looks originally:

The local variables list in new-concept.org
contains values that may not be safe (*).

Do you want to apply it?  You can type
y  -- to apply the local variables list.
n  -- to ignore the local variables list.
!  -- to apply the local variables list, and permanently mark these
      values (*) as safe (in the future, they will be set automatically.)

  * eval : (let ((pos (org-babel-find-named-block "stages"))) (when pos 
(save-excursion (org-with-point-at pos (org-babel-execute-src-block)))))

Button A should follow here:
^^^^^^^^^
File: emacs.info,  Node: Safe File Variables,  Prev: Specifying File Variables, 
 Up: File Variables

49.2.4.2 Safety of File Variables
.................................


Right now situation is this:

- if user press C-g to abort the file will be loaded, which is good

- user will not be able to access any of the visible buttons by using
  cursor because somebody made cursor invisible in that
  dialogue. Cursor should be made visible that keys can be used to
  access buttons

- There shall be on minibuffer some key like "? TO READ MANUAL" to go
  straight to the manual section above which is warning user much
  better.

- IF THE USER press C-g, or tries to escape it or clicks by using
  keyboard on the button, or even switch to the buffer with keyboard,
  or uses mouse to activate the button, or uses ? to activate to read
  manual, in all those cases the dialogue should be interrupted and
  file loaded. User should not be left facing dialogue if it was clear
  from user's interaction that there was doubt with the meanings of
  the dialoue.

- Adding references on unsafe local variables to TUTORIAL

> Full disclosure. I make use of file local variables every day
> and I have spent quite a while writing orgstrap which relies heavily
> on them, so I am definitely biased.

With such enhancement there is no need to change history of the past,
we just change the future and history for the future.

> Emacs is a sharp tool. Experts need sharp tools. If someone
> complains about the security of prompts but also admits that they
> always say yes to prompts without reading them, then no one will
> take them seriously when they try to argue that it is the prompt
> that is insecure.

I never say YES by the rule. I have explained sincerely that I did say
YES for number of years as I was thinking those are enhancements that
make things work. And I have used Emacs in that way for long
time. Overall I did not encounter many files with local variables
because I did not read other people's files for long time. Please try
to get the perspective. I was programming myself but in other
languages and never used local variables. If I do not read other
people's files it is hard to encounter Local variables. When it came
about 2016 to start reading other people's files that is where I
rather pressed YES. I did not put attention on each function and those
meanings and did not know meanings of functions.

If you say that it is important to take users seriously, then take
their behavior with the editor seriously and their proneness to
failures as well. Do not expect power users.

> It is like complaining that the forest is dangerous while insisting
> on eating the berries of all the plants and picking up all the
> snakes.

I think that analogy of Tom with the racing car is better.

To make your analogy better it would be like you have the forest with
excellent mushrooms and you invite general public to the forest. Then
you face public with some of potentially poisonous mushrooms and you
start asking them if they wish to accept Amanita muscaria mushroom as
it could be possibly unsafe. But people came to see those potentially
good mushrooms and did not hear of posionous mushrooms, damn, let me
say YES, I am here and I feel safe!

> Degrading usability because some users are irresponsible just
> reinforces the irresponsible behavior and everyone loses.

Usability is already degraded. You can enhance it. It is not nice
calling users irresponsible just because they did not read the manual
and fully understand it. In addition to Emacs Manual by asking users
to decide if variables are safe or not, Emacs is in the same time
asking users to know meanings of ALL possible functions and variables
that are located in such files. That is one big chunk of assumptions
and conditions that user should become responsible by such viewpoint.

In that case it would be best to lock the Emacs of using it unless ALL
users can pass the test to know everything written in the Emacs manual
and Emacs Lisp manual as well.

> Furthermore, Emacs does try to account for users who don't read the
> manual and has sane and safe defaults. Namely it does not blindly
> execute code but prompts the user and lets them know that something is
> going on. Further, when it prompts the user it does not provide a
> default action, it forces them to answer so that they must attend to
> what they are doing. This provides the user with an opportunity to
> become aware of a feature of Emacs that is new to them.

While that purpose is good and that is same purpose that I am
supporting our opinions differ.

Do you see how you said: "This provides the user with an opportunity
to become aware of a feature of Emacs that is new to them." -- this is
what is my wish too. I just think that one cannot become aware of a
feature that is new to them.

> The only other option is to never execute local variables until a
> user reads the manual and changes their config.

That is optional only in historical terms or if we make time machine
to go back and make more future prone defaults.

> With regard to the local variables prompt. Maybe the right thing to do
> in this case would be to add a "?" option so that users can open the
> manual?

Button and ?

? was or is at most cases shown to user, but on the dialogue speaking
of safety is not shown. 

> That seems like it would help. That said, the second line of
> the prompt reads "contains variables that may not be safe (*)" which
> should be alarming. I guess it could be changed to "THIS FILE COULD
> PWN YOU. Please review potentially unsafe variables marked with an
> asterisk (*)."

You could include that for advanced users. The point of discussion is
that millions are not advanced users and using terminology such as
variable, value, apply, safe is out of the context for the user who is
not advanced. Using "pwn" would be hard to understand.

When word is out of the context such cannot be understood.

I gave one reference from Stack-something where users do not
understand "safe" and then other one came with the comment also not
understanding "safe".

Safe in the context of the dialogue and relation to computing means
safe to user's data, privacy and safe computing. One has to know
that majority of computer users are not aware of security problems in
computing and that they put things on risk.

Users who are not programmers or just know how to edit files,
translate, make reports, they need not know what is programming and
computer terminology. If that would be so than there would be no
computing dictionaries, the manual and Emacs Lisp manual just to name
few examples.

I have my staff members who are using Emacs. They do not know it. One
is in Tanzania, one is in Kampala, Uganda. They will know how to edit
Org file and how to send me portion of it, but they did not learn
nothing about computing.

For them the word "safe" is never in the context of computing! Because
if one does not know the context around the word meaning is lost. For
them "safe" means free from danger or the risk of harm. That is in the
personal context, did anybody tell them there is something in the
computing context? References from Stack- show example that people
understand it so. When saying "safe" one has to say "safe to your
data" and if there are no references to context then there shall be
references to manual as example.

I am not sure if "bold" is right way to warn users if it does not work
well on console. Underlined, different colored, links are showing
better in console and if somebody does not use colors I think
underlined will show better.

So if you can do something about that to enhance references to
meanings of what dialogue is telling to user, that would be great.

Jean