Re: Unicode confusables and reordering characters considered harmful

[Tim Cross]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Stefan Kangas <stefan@marxist.se>,  cpitclaudel@gmail.com,
>>   emacs-devel@gnu.org
>> Date: Tue, 02 Nov 2021 15:12:56 -0400
>> 
>> > You cannot see those characters on a screenshot, for the same reason
>> > you cannot see any whitespace characters on a screenshot: they are
>> > only discernible when you move cursor through them.  Which is why I
>> > asked how are you looking for them.  If you are looking for them in a
>> > screenshot, you will never see them.
>> 
>> But that's the core of the vulnerability: if you just look at the screen
>> (and just scroll through it) you will have an incorrect understanding of
>> what the code does.
>
> If you want a more prominent display, customize
> glyphless-char-display-control to show format-control characters as
> acronyms, say, or as hex-code.
>
> And anyway, my point was that Emacs deviates from Unicode here, which
> says not to show these controls at all, and by deviating it gives the
> user some defense against these problems.  I did say originally the
> defense was "weak", so if you want to point out that this is a weak
> defense, you are preaching to the choir.
>
>> It's good that such bidi override chars are displayed as a thin space,
>> but it's mostly useful to make it possible to edit them (or to `C-x =`
>> on them), but I don't think it makes a significant different in terms of
>> the security issues introduced by the presence of those chars in the code.
>
> In most cases, there's no need to make these controls stand out,
> because situations where this presents security risks are extremely
> rare, to put it mildly, and OTOH having them stand out more by default
> will make it harder to read text with completely legitimate uses of
> these controls (example: TUTORIAL.he).  Therefore, IMNSHO it's okay to
> have this off by default (and have a way of turning that on in case of
> increased paranoia).  Moreover, I think adding features that detect
> the suspicious uses of this functionality will better serve our users
> than just showing the controls more prominently, because it will have
> a much lower probability of false positives, and will avoid getting in
> the way of reading legitimate text which uses these controls for valid
> reasons.


Totally agree. There is no point having additional visual clues for a
security issue which is not well understood by most users. It will just
cause user frustration and as pointed out, in some cases make legitimate
uses look worse. On the other hand, having features which warn the user
of suspicious instances is likely to be more useful and informative,
even to those who are not terribly aware of the issue (I'm assuming such
feature would provide some sort of warning and a reference to where to
find more detailed explanation).