I don't believe that potentially adding more homographic characters can worsen the panorama for attacks using them - currently there are already plenty of similar characters, and trusting the visual appearance of a character for security won't ever mean anything again. Other security measures have to be taken for this kind of attack - and having more ways to spell out a forward arrow is certainly not changing the current landscape where an homograph, or close homograph for that matter, to every ascii letter can probably be found nearly 20 times in the unicode charset.
On Thu, Apr 10, 2025 at 8:50 AM Marius Spix via Unicode <unicode@corp.unicode.org> wrote: > > I'm afraid, that this would open Pandora's box for more homograph attacks. ∃ > (U+2203) is already a confusable for E in a BiDi context. But this would add > more characters like ꟼ (U+A7FC), ⅃ (U+2143) or ↋ (U+218B) to the list. > > Gesendet: Donnerstag, 10. April 2025 um 00:02 > Von: "Nitai Sasson via Unicode" <unicode@corp.unicode.org> > An: unicode@corp.unicode.org > Betreff: Re: Proposing new arrow characters with Bidi_Mirrored=Yes > Okay, this tangent about ligatures is totally off-topic. There are other > cases where arrows are used as operators or relations within text, so > mirroring arrows are still needed even if they aren't the best solution for > the specific issue of showing "->" as an arrow. Eli, we can continue in > private emails if you want, I don't want to spam this thread with it. > > I am absolutely devastated because I just spent hours writing this email and > Proton Mail just made it disappear. So until I can recover that draft, please > make do with this condensed rewritten version: > > Firstly, you guys should know that Unicode BiDi is FANTASTIC. It makes > everything work. It makes everything easy. Developers are happy to fix bidi > bugs within a day because it's so easy. This is an absolute win for everyone. > > Have some examples: > https://github.com/pachli/pachli-android/pull/906 - fixes linked issue, see > how minor the code change is and how great the benefit! > https://github.com/OSMCha/osmcha-frontend/pull/766 - this previously-linked > issue was similarly easy > https://github.com/openstreetmap/openstreetmap-website/pull/5835 - as was > this (though it took me a while to find the right option), in the end it was > just one line change for a HUGE improvement for all BiDi users > > You're wondering if it was a good move to make characters mirror at all? YES > IT WAS. Templates like "%s (%s) %s" work universally. Imagine what would be > required to make that template work if parentheses didn't mirror in RTL! How > many developers would agree to make the effort to do that, and introduce that > complexity into their codebase? Nearly none, and RTL users would be left in > the dirt. Unicode's BiDi is a godsend. > > Arrows are the only exception. They are the one thing that Unicode does not > give developers an easy BiDi solution for. And they are what I want to fix. > > > > The Proposal Idea > ================= > > (with credit to Mark E. Shoulson) > > Define a new combining character: > > <BDM> Bi-Directional Mirror (working title) > > Binds to the preceding character, and effectively gives it the property > Bidi_Mirrored=Yes. > Only has an effect on characters with Neutral directionality. Does nothing to > characters with strong or weak LTR or RTL directionality. > > Examples: > Within RTL text: > U+05D0 א HEBREW LETTER ALEF > U+2192 → RIGHTWARDS ARROW > <BDM> Bi-Directional Mirror > U+05D1 ב HEBREW LETTER BET > > Renders as: א←ב > (Without <BDM>: א→ב) > Arrow direction is flipped because it's resolved RTL > > Within LTR text: > U+0041 A LATIN CAPITAL LETTER A > U+2192 → RIGHTWARDS ARROW > <BDM> Bi-Directional Mirror > U+0042 B LATIN CAPITAL LETTER B > > Renders as: A→B > (Without <BDM>: A→B) > Arrow direction is maintained because it's resolved LTR > > > That's it. I honestly cannot think of any issue or potential pitfall with > this solution. The only substantial negative feedback I've seen is that > control characters haven't always turned out well in the past. That's a > reason to be cautious, not to reject the idea outright. > >
