emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unicode confusables and reordering characters considered harmful, a


From: Eli Zaretskii
Subject: Re: Unicode confusables and reordering characters considered harmful, a simple solution
Date: Fri, 05 Nov 2021 14:12:12 +0200

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 5 Nov 2021 02:58:49 -0700
> Cc: db48x@db48x.net, cpitclaudel@gmail.com, yuri.v.khan@gmail.com, 
>       monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The idea is to make the programmer explicitly say yes to using these
> >> characters.  (Or at the very least give them a way to say no, but I'd
> >> much prefer the former.)
> >
> > IMNSHO, that would be a nuisance.  IOW, this cure is much worse than
> > the disease.
> 
> I very much disagree that byte-compiler warnings would be "worse than
> the disease".  Why should any user be so very inconvenienced by that?

Because the way this is being proposed, i.e. issue a warning whenever
any of the directional controls are present, its signal-to-noise ratio
will be too low to be useful.  If the proposal is to teach the
byte-compiler to identify the cases flagged by
bidi-find-overridden-directionality, then I don't mind to it
triggering a warning.

> Security will always be at odds with convenience.  The question is one
> of striking a balance between the two.

The right balance is where the percent of false positives is very low.
If we are just going to warn because some codepoints are seen in the
source, the absolute majority of the warnings in Real Life will be
false positives, and that is AFAIU a bad idea for a security feature.

> In this case, I think asking users to add one line of code to those rare
> files that need to use these control characters seems like a price worth
> paying to improve security in Emacs Lisp as a whole.

Adding one line is a nuisance.  If it can be avoided, we should avoid
it.  Since we are capable of detecting the really suspicious uses of
those controls, it is much better to use that, because in that case
users will not have to add anything.

Don't you agree that a feature whose signal-to-noise ratio is high
enough to avoid the need of adding anything to the source is better
than a feature which does require such additions?

> Yes, it'll ask more from users that want to write Emacs Lisp with
> strings and comments in RTL languages.  But they can also choose to do
> nothing and live with the byte-compiler warnings instead.

That is not the stance we should take, because basically it says we
don't care enough about users who use these languages in their
programs.  Especially when we have a means of doing that without
causing any inconvenience.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]