Problem is, this behavior is so outside of the range of common expectations, it's really hard to say if it's harmless or not and what are the worst cases for (ab)using it.
It's telling that the description (https://unicode-explorer.com/c/202E) even acknowledges that 202E is commonly used as an exploit. "The Right-To-Left Override character can be used to force a right-to-left direction withing a text. This is often abused by hackers to disguise file extensions: when using it in the file name my-text.'U+202E'cod.exe, the file name is actually displayed as my-text.exe.doc - so it seems to be a .doc file while in reality it is an .exe file."
An expression in French for this: "Tomber en marche" (literally: falling into walking). When something breaks we say it "tombe en panne" (falls into being out of service), when something works we say it "marche" (walks). So this expression is like "falling into a working state".
I wonder about the ratio of unknown bugs vs features that accidentally work, in the wild. Such features are time bombs waiting to explode during the next refactoring.
I don't think it's intentional but just recoginzes a unicode code point with the uXXXX syntax even without the backslash and then includes the literal character in the info box without any consideration for special characters.
I don't know. I feel at unease when the info banner reverses all the text ("This Instant Answer was made by the DuckDuckHack Community.").
Because the text looked very odd to me I highlighted the nonsensical text "noitatneserper lausiv" and context-menu searched it on Google. To my surprise it googled for "visual representation", and while retrying because I thought that maybe Google's engine auto-"corrected" the text, I noticed that even the text in the context-menu stated that it would google for "visual representation".
Then seeing that it was "noitatneserper lausiv" in reverse, maybe also in combination from the first hit "U+202E RIGHT-TO-LEFT OVERRIDE - Unicode Explorer", it felt like the browser had done something it should not do by actually applying the reversion to the info box.
When inspecting the HTML tag of the info box it displays the string "‮ U+202E RIGHT-TO-LEFT OVERRIDE, decimal...", but whenever I try to do something with it, it get's eiter reversed or messed up.
Another bug: When I select the entire text in the info box, I get " U+202E RIGHT-TO-LEFT OVERRIDE, decimal: 8238, HTML: No visual representation, UTF-8: 0xE2 0x80 0xAE, block: General Punctuation" <-- (btw, this was NOT what I had first entered into the textfield before this edit)
And trying to append a double quote to the text above, it inserts it at the beginning of the line, actually after the E202+U. When I expand the textbox so that the entire paragraph is in one line, E202+U moves to the end.
All this is creepy and I bet that it won't be long until an exploit with this uncontrollable Unicode character will hit the first vulnerable servers and browsers. This feels like Unicode is playing with fire.
The Right-To-Left Override character can be used to force a right-to-left direction withing a text. This is often abused by hackers to disguise file extensions: when using it in the file name my-text.'U+202E'cod.exe, the file name is actually displayed as my-text.exe.doc - so it seems to be a .doc file while in reality it is an .exe file. There's even an xkcd comic for this character!
Probably a bug, browser history shows the title as "[object Object]", which is what happens if you print an object value that cannot be 'adequately' serialized to string in javascript e.g. ({}).toString()
Comments
Everyone here is asking if this is an "intentional easter-egg" or an "accidental bug"
But what about accidentally working-as-intended?
Sure it's a little trickier to read, but it's certainly not a "bug" that will cause any damage / danger / instability / etc.
I don't get your take.
Even the most strict definition of bug doesn't imply it has to "cause any damage / danger / instability / etc." to be one.
And I won't call it "work as intended" when the purpose of this feature is to provide an answer for human to read, and it failed on that.
I'd warmly beg to differ, I personally think it's illustrating how it is supposed to work, most elloquently.
I propose "accidental feature" for this sort of thing.
I like it, surprised the legions of Skyrim players haven't already coined that term
“It’s not a bug it’s a feature”
Problem is, this behavior is so outside of the range of common expectations, it's really hard to say if it's harmless or not and what are the worst cases for (ab)using it.
It's telling that the description (https://unicode-explorer.com/c/202E) even acknowledges that 202E is commonly used as an exploit. "The Right-To-Left Override character can be used to force a right-to-left direction withing a text. This is often abused by hackers to disguise file extensions: when using it in the file name my-text.'U+202E'cod.exe, the file name is actually displayed as my-text.exe.doc - so it seems to be a .doc file while in reality it is an .exe file."
An expression in French for this: "Tomber en marche" (literally: falling into walking). When something breaks we say it "tombe en panne" (falls into being out of service), when something works we say it "marche" (walks). So this expression is like "falling into a working state".
I wonder about the ratio of unknown bugs vs features that accidentally work, in the wild. Such features are time bombs waiting to explode during the next refactoring.
The page redirects to u202E (no backslash) which is a normal word. I think it's an Easter egg.
I don't think it's intentional but just recoginzes a unicode code point with the uXXXX syntax even without the backslash and then includes the literal character in the info box without any consideration for special characters.
For example this shows an @: https://duckduckgo.com/?q=u0040&ia=answer
I don't know. I feel at unease when the info banner reverses all the text ("This Instant Answer was made by the DuckDuckHack Community.").
Because the text looked very odd to me I highlighted the nonsensical text "noitatneserper lausiv" and context-menu searched it on Google. To my surprise it googled for "visual representation", and while retrying because I thought that maybe Google's engine auto-"corrected" the text, I noticed that even the text in the context-menu stated that it would google for "visual representation".
Then seeing that it was "noitatneserper lausiv" in reverse, maybe also in combination from the first hit "U+202E RIGHT-TO-LEFT OVERRIDE - Unicode Explorer", it felt like the browser had done something it should not do by actually applying the reversion to the info box.
When inspecting the HTML tag of the info box it displays the string "‮ U+202E RIGHT-TO-LEFT OVERRIDE, decimal...", but whenever I try to do something with it, it get's eiter reversed or messed up.
Another bug: When I select the entire text in the info box, I get " U+202E RIGHT-TO-LEFT OVERRIDE, decimal: 8238, HTML: No visual representation, UTF-8: 0xE2 0x80 0xAE, block: General Punctuation" <-- (btw, this was NOT what I had first entered into the textfield before this edit)
And trying to append a double quote to the text above, it inserts it at the beginning of the line, actually after the E202+U. When I expand the textbox so that the entire paragraph is in one line, E202+U moves to the end.
All this is creepy and I bet that it won't be long until an exploit with this uncontrollable Unicode character will hit the first vulnerable servers and browsers. This feels like Unicode is playing with fire.
Edit: From https://unicode-explorer.com/c/202E
Probably a bug, browser history shows the title as "[object Object]", which is what happens if you print an object value that cannot be 'adequately' serialized to string in javascript e.g. ({}).toString()
The title of the page is "u202e at DuckDuckGo" which doesn't even have any funky unicode in it.
So you might have something else going on if it shows up as "[object Object]" in your browser history.
It is almost certainly an accident, but it might have been left in on purpose!
Ha, it changed. It was indeed a bug