Hacker News Reader

Comment by hnlmorg | Hacker News Reader

If there was ever a clear signal that working with Unicode is incredibly hard, it would be the fact that no one on HN can decide if this is accidental or intentional.

View on HN

Let me take a stab at a definitive answer:

– It is unintentional for DuckDuckGo. The code for DuckDuckGo works correctly but no one who wrote that code thought about whether a reversal would happen.

– It is intentional for the browser. The code for the browser works correctly and someone who wrote that code actively thought about how to make a reversal happen.

I don’t think ‘accidental’ is the right word to use in either case because the outcome is what you would want.

The reason I used "accidental" is because it's not a bug (and you've alluded to that same conclusion too). You could argue it's accidental from the perspective of DDG if it happened by chance rather than design. But the distinction between "accidental" and "unintentional" is nuanced and I'd already offered "intentional" the alternative option so I'd argue you can pretty much use them interchangeably in this specific situation.

It certainly looks like a simple template that DDG applies consistently to all queries for a UTF-8 byte literal. It's the exact same template for a query for a more straightforward literal, like u0041.

So I think it's fair to say that it's not intentional in the sense of being a deliberately added easter egg. Of course, they might be aware of the behavior and decided to leave it that way.

The hardest problem in software engineering: to close with as-designed or out-of-scope.

And some of us don't even get what this is about. Should I be seeing DDG doing something particular here?

The "answer" tab is right to left

I had that turned off. Thanks for explaining it.

Joining two pieces of text and having one destroy meaning in the other is certainly a bug, most commonly a security bug. If you look at the search results in the original link, much of the discussion involves using it to hide file extensions and similar information hiding attacks.

A significant portion of the problem seems to be that some people can't even identify what's going because the tools they're using to inspect the page are also showing it reversed.

This! Also, https://news.ycombinator.com/item?id=21105625

It's accidental, because other characters are also displayed: https://duckduckgo.com/?q=u20aa

It's intentional, because there is no RTL override in the HTML source, the string is merely reversed.

but there is, see:

  document.querySelector(".zci__body").textContent.charCodeAt(0)
  document.querySelector(".zci__body").textContent.substring(1)

> no RTL override in the HTML source, the string is merely reversed

What? After opening the source, ctrl-f "representation" selects the reversed word. The source view just happens to interpret the RTL override.

Yes, but this is not a printable character.

None of these will be shown, but ddg will recognise them as control characters though. https://www.compart.com/en/unicode/category/Cc

Reply on news.ycombinator.com