Local variables issue - Re: One vs many directories

[Jean Louis <bugs@gnu.support>]

* Tim Cross <theophilusx@gmail.com> [2020-11-25 08:54]:
> 
> Jean Louis <bugs@gnu.support> writes:
> 
> > Observing users who are asked questions upon invokation of other
> > software I can say that many times users just click one of the
> > options, either YES or NO, but without real regard to the
> > meanings. The purpose to click either YES or NO is to continue one
> > step forward and randomity decides later what happens.
> 
> You cannot prevent people from making bad decisions. Saying yes to
> something when you don't know what it means is like using the same
> weak password for everything. There has been massive amounts of
> communication and education out there to let people know about the
> risks. If they choose to ignore it or follow practices which are unsafe,
> it is their tough luck.

I do agree only that it is too general to apply here. That is specific
case of showing a dialogue with potential dangers to users who did not
specify those local variables and probably do not need such!

If you personally specify local variables you need them and know what
it is. That is fine.

It is general design that was meant for hackers in beginning stages of
Emacs development. Today many people use Emacs who may not be
hackers. Subset of those people will say YES to anything.

It is possible to prevent people to make bad decisions and it is easy,
simply don't ask them with the option to make bad decision. Disabling
local variables by default would be better decision.

I think that it is not possible today to change the default. Design is
flawed. From a view point of text editor should not ask user to
execute anything by default. User should enable "Local variables
detection" when user wish to get asked about executions.

> We need to encourage people to take more responsibility for their
> actions, not less.

I do fully agree on that statement, only it is too general and not
specific. I have presented my specific case how I have been answering
YES to that dialogue by thinking it is something necessary to read the
file properly. I had misunderstandings. Since some time I have the
general rule to answer NO on such dialogues. Would there be some
malicious intention in those years the intruder would be quite
successful.

One could fetch the external program and call it "general Emacs
enhancement" and open up a backdoor shell into the system.

To encourage people to take more responsibility is not necessarily
general principle for GNU Emacs.

And to encourage them alone will never work. To gain any
responsibility person needs knowledge or information. Driving car
without knowledge is impossible.

Thus pushing some kinds of responsibilities to user, coercing user to
decide on something that user does not understand itself lacks
one part of responsibility.

If user is informed what are local variables or is using them already
or reads manual and understands dangers, then user has acquired
knowledge to be able to reason when such dialogue pops up with YES or
NO. In general the answer YES can ruin your data and computing, and
users are not aware of it.

When somebody is not aware of what is doing that is not condition of
encouragement, rather condition of lack of responsibility.

> One important component of this is allowing the consequences for bad
> decisions to occur and not spend endless resources protecting people
> from themselves.

The YES/NO dialogue was invented by programmers and not by users. So
it was never an initial decision of the user who reads file from other
person, to be asked in the first place if something in that text file
should get executed.

It may also negatively impact Emacs's image as software:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=emacs

> If your asked to do something and your clearly told that doing so might
> be unsafe and your given an option not to do it which is just as easy to
> perform and you still decide to do it, that decision is on you.

Problem is with the assumption that user is "clearly told". I have
used Emacs since 1999 and I was all the time in scratch buffers and
did not really know it is for Emacs Lisp. I have been putting my notes
there. And I have ignored many functions of Emacs and used it to
program in other programming languages. Despite that I did read the
manual I did not clearly get information that there is programming
language built-in and it could execute any code. Despite knowing about
packages and installing them I did not know how it works. That is my
personal reality. I was playing tetris and I did not know it is
program that is loaded and executed. For me that was a built-in
feature, something that Richard Stallman and others invented and
built-in.

> The alternative is to remove extremely useful functionality from
> many responsible users because of an unknown number of others who
> make poor decisions.

Review that statement of yours again as you said what I am saying:
unknown number of others who make poor decisions.

Functionality need not be removed from Emacs to have or to design more
safer computing environment.

I have just opened new.txt file and used M-x
add-file-local-variable-prop-line only to verify how dialogue really
looks like:

The local variables list in new.txt
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.)

  * ivy-mode : 1

Then I switch from my programmers view point to let us say translator
view point. Translator who is introduced to Emacs as excellent text
editor and has to translate from German language to some other
language. Such translator would go through the Emacs tutorial and
learn how to open files, save files, use the keys. Translator cannot
possibly be expected to take any responsibilities for this dialogue as
translator that I know would never understand or be able to understand
what are these terms:

- "local" as in "local variables" would not be clear what it means local
  as there is no context that is understandable. Hacker and
  experienced user can understand it. Translator cannot. There is only
  general definition of "local" and that one does not apply to this
  context, one has to read the Emacs Manual fully to understand it and
  that is not what many people do when editing text.

- "variables" is programming term that translator is faced with and
  cannot possibly know what is meant with it. All what translator
  knows is that he go the file from other person and is now faced with
  the dialogue. There is no way for such person to responsibly make
  any decision, neither YES or NO. Translator will choose one of them
  to pass through the process, not to make the decision.

- "values" from the view point of translator is vague and cannot be
  understood. What values? Where?

- "may not be safe (*)" -- while symbol * may be used as reference
  this also may not be clear. Then what is "safe"? It is not clear
  from the dialogue context how that cannot be safe. Translator is
  sitting on computer and have been using typewriter and other
  computers for whole his life and will say "I was always safe" so why
  should it not be safe for me. And out of misunderstanding or protest
  will say YES to it.

- "Do you want to apply it?" -- to translator this is vague, as
  translator is not programmer but is faced with programming
  decisions that translator cannot understand. If translator wanted to
  open the file this may be understood as further approval to open the
  file. So if translator is opening the file, why would not translator
  like to apply it? Sure translator wants to apply it, damn YES!

- "to ignore the local variables list" -- means as well little and
  nothing to translator. Finally all that translator wanted is to open
  up text editor to translate the legal document hanging in front of
  him from German language to his local language and to earn some
  money. Such person may not be inclined to ignore things, damn YES!

- "!  -- to apply the local variables list, and permanently mark
  these" -- after several botherings translator may be inclined to not
  get bothered again, so let me ! do that, fine!

And after many such attempts translator may get bothered with the
dialogue that in the ends answers YES on any such dialogue.

I do understand that feature is built-in and files depend on it by
default. And while I support more safer solution, I do not support
that it should be removed as a default feature as it is for decades
late to design it safer.

But then this dialogue can be improved as it is very clear that
dialogue is handling possible security issue:
  
The local variables list in new.txt
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.)

  * ivy-mode : 1

Some words there can be hyperlinks to give knowledge to the user on
what is actually user deciding about, so various terms in the dialogue
can be hyperlinks to various parts in the manual. That way user may
get the real and straight access to information to make an informed
decision rather being left alone and called not responsible.

> Furthermore, keep in mind that this ability in Emacs has been around
> for longer than many users have been alive.

Yes, and that does not make it safer. My opinion is that it was bad
design for general public. Before 30 years there was not that many
users and people were in general much more interested in computing and
active computer use such as programming. Today the interest goes more
towards entertainment and passive computer use as that is what largest
corporations promote. The number of programmers did not increase
proportionally with the number of computers and computer users. We are
getting dumber as people, not smarter.

> I've been using it for nearly 30 years and have participated in many
> forums over that time. I have yet to hear of a single security
> incident occurring because of local variables.  That doesn't mean
> such incidents have not occurred, but it does likely mean they are
> rare.

That is hardly indication. When design is bad and something happens to
the user only those experienced and knowledgable will be able to reach
the forum or mailing list to report something like that.

If user is not knowledgable about local variables and already press
YES when it should be NO, then such user will never reach to report it
to you.

End of 1998 proprietary OS on my computer freezed. There was nothing
special going on, it just freezed and I had no other option but to
reset it. After the reset I could enter the system without any
problems or warnings and there was no file any more. While OS did
function files were not there and it was not nice to lose
files. Neither I have went to Internet, neither called anybody to
complain about that, just nothing, I was faced with condition outside
of control and did not know there could be helped to it. This would
happen to those who are affected by security flaws.