From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Bidirectional text and URLs Date: Sun, 30 Nov 2014 22:42:18 +0900 Message-ID: <87zjb8n6th.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87a93cngwv.fsf@uwakimon.sk.tsukuba.ac.jp> <837fyfml31.fsf@gnu.org> <874mtio7wh.fsf@uwakimon.sk.tsukuba.ac.jp> <83r3wml8kq.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1417354982 30761 80.91.229.3 (30 Nov 2014 13:43:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Nov 2014 13:43:02 +0000 (UTC) Cc: larsi@gnus.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 30 14:42:55 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xv4m6-0005Ex-44 for ged-emacs-devel@m.gmane.org; Sun, 30 Nov 2014 14:42:54 +0100 Original-Received: from localhost ([::1]:50508 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xv4m5-0003WU-H2 for ged-emacs-devel@m.gmane.org; Sun, 30 Nov 2014 08:42:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59269) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xv4lu-0003WM-VS for emacs-devel@gnu.org; Sun, 30 Nov 2014 08:42:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xv4ln-0006I2-Et for emacs-devel@gnu.org; Sun, 30 Nov 2014 08:42:42 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:40655) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xv4le-00069a-Um; Sun, 30 Nov 2014 08:42:27 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 124701C3906; Sun, 30 Nov 2014 22:42:19 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id EB7731A273D; Sun, 30 Nov 2014 22:42:18 +0900 (JST) In-Reply-To: <83r3wml8kq.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:178507 Archived-At: Eli Zaretskii writes: > I agree, but the issue discussed here is different: I have to disagree. The issue is about *any* technology that can be used to convince the user that one URL is being accessed when in fact another one is. Whether one should try to warn the user is a separate question, which depends on the probabilities of legitimate vs. fraudulent displays, and the cost of annoyance vs the *avoidable* cost to fraud victims. Unfortunately, the HCI evidence suggests that few potential victims listen to warnings (or even understand them), so you're probably right that it's a bad idea to warn if RTL characters are present. > detecting only the enclosed-LTR case is better than nothing, I > think. Agreed. > > and of course any jumble is possible as a domain or path component > > which is an abbreviation. And any useful jumble can probably be > > registered as a domain, and certainly incorporated in a path. > > I doubt that a domain like this could be registered, as using such > characters in a domain name is AFAIU against the regulations, see > RFC3987. If you mean the controls, you're probably right, although RFC3987 has been updated for international domain names. I suppose those controls are not permitted, though. > The easy cases with RTL text, as mentioned above, should be also > easily detectable, and I agree they should get the same treatment. OK, good enough for me. > > "We need to decide what we want to do, and then look for a mechanism." > > OK, let me rephrase: what effect will "turning off" have on > display? Whatever the display would be in the absence of an attempt to detect and warn about instances of possibly fraudulent use of directional controls. > I very much hope we will find a sane middle ground, possibly subject > to user control. I'd hate to see Emacs become another case of the TSA > disaster. The best I've been able to come up with given the unfortunate conflict between UAX#9 and the "normal" display of URLs as I understand it is a one-off warning (or use of something like the novice mechanism so the user can easily "turn it off" as defined above as soon as it becomes annoying -- I expect your judgment to be that it would *always* be annoying, just mentioning the possibility for completeness). > Someone(TM) should present a list of well-thought requirements, and we > can take it from there. Unfortunately, besides LTR in RTL control, and RTL in LTR control, I can't help, not being familiar with the expected display.