From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 0Ez8HUMPvl+WGgAA0tVLHw (envelope-from ) for ; Wed, 25 Nov 2020 08:01:07 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 37joGUMPvl8LAgAAB5/wlQ (envelope-from ) for ; Wed, 25 Nov 2020 08:01:07 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 274E8942004 for ; Wed, 25 Nov 2020 07:50:08 +0000 (UTC) Received: from localhost ([::1]:49398 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1khpZ0-0000w4-RN for larch@yhetil.org; Wed, 25 Nov 2020 02:50:06 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52632) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1khpYe-0000vj-Hz for emacs-orgmode@gnu.org; Wed, 25 Nov 2020 02:49:44 -0500 Received: from static.rcdrun.com ([95.85.24.50]:37773) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1khpYb-00016l-NZ for emacs-orgmode@gnu.org; Wed, 25 Nov 2020 02:49:44 -0500 Received: from localhost ([::ffff:41.202.241.56]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C000B.000000005FBE0C93.00004A6D; Wed, 25 Nov 2020 07:49:38 +0000 Date: Wed, 25 Nov 2020 10:01:57 +0300 From: Jean Louis To: Tim Cross Subject: Local variables issue - Re: One vs many directories Message-ID: References: <87ft4zhyuo.fsf@disroot.org> <877dqbhtgf.fsf@ucl.ac.uk> <87zh36d1xn.fsf@web.de> <875z5uxzev.fsf@gmail.com> <871rgi7zhz.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <871rgi7zhz.fsf@gmail.com> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -0.51 X-TUID: FQNhqv/DaF1x * Tim Cross [2020-11-25 08:54]: > > Jean Louis 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.