Hacker News Reader

Comment by Rygu | Hacker News Reader

I'm pretty shocked that I have never heard of the RLO unicode character before this article. Let's see if it works: ppa.emorhCelgooG => ‮ppa.emorhCelgooG

View on HN

Whoa. Check out you did to the markup of this page. http://d.pr/HKSQ

The HTML standard specifies that changes in text direction are bounded to the block they occur in: http://www.w3.org/TR/1999/REC-html401-19991224/struct/dirlan...

I discovered this as I was writing a paranoid HTML cleanup library and wanted to prevent the attack where a user sticks a text-direction-change character into the page and reverses the whole thing. As we've all just witnessed, that can't happen in a conforming browser.

But when viewing the page as a text stream, yup, it reverses and then never really unsticks. Everything's working as designed!

(Maybe my library should still restore the page flow after all... I never thought of how it could mess up view source. As attacks go, it's weak sauce... but like I said, it's meant to be really, really paranoid.)

Doesn't the library just have to perform a simple search-and-replace on the entire page's HTML for the blacklisted characters to remove them?

Normally blacklisting is bad, but we're only targeting the few text-direction-changing characters that exist.

Is this 'really, really paranoid' library available somewhere?

Not yet. But it'll be in Haskell anyhow, so you're probably not actually interested :)

There are other such libraries for other languages, poke around. See for instance http://htmlpurifier.org/ .

Even more intriguing. What exactly were you writing in Haskell that needed a super-paranoid html sanitizer? Yet another web server/blog/cms? Or something way more cooler?

Yet another blog, except not targeted for release or anything, just to run my own site. To replace the Django blog that runs my site. It's sort of my entertaining diversion, you know? Working with my own fresh, clean code base where I can try some ideas out without having to carry around a couple of man-centuries worth of legacy code every time I step at work. The cleansing library doubles as my HTML formatter, too, doing things like ensuring close italic tags and such. The paranoia is half real, half fun exercise.

Ah, yes - I see where you're coming from. Some day I hope to finish my blog, written in C :D Good luck for your haskell blog :)

Looks like the bug is in Chrome's View Source - the markup itself is fine.

Is it a bug? Or is chrome correctly interpreting the right-to-left override character it sees in the source?

Good point. It is probably the right thing to do technically, since the source view can't rely on parsing the markup. I think I'd prefer such non-printable characters to be simply escaped though.

Are you sure? curling from Terminal, I get the same result.

That's probably because your terminal interprets the RLO character. Should it? I'm not sure.

rxvt-unicode, despite being perfectly able to display unicode characters (hence the name), drops the RLO.

Ha, nice catch!

edit: I get the same in Opera 11.50, Firefox 5.0 and some Chrome version.

This is an interesting page from 2006: http://digitalpbk.blogspot.com/2006/11/fun-with-unicode-and-... and seems to demonstrate to me that Firefox, Opera, and Internet Explorer all will eagerly display the RLO character, and Chrome and Safari will not.

Is Chrome and Safari broken or being responsible? (Are there settings to change the behaviors in any of these browsers...?)

Try selecting the text, it behaves funnily in a way that I can't understand!

It behaves funny in a very "simple" way. Selections have this little problem where you move your mouse over the visual representation but the selection is in the logical representation.

So say your logical text is this:

  ltr LTR.

where the capital letters are RTL chars (whether because they're actually RTL or because of an RLO in the char stream). That is, the above represents the reading order. Visually this would look like this:

  ltr RTL.

assuming that this paragraph directionality is left-to-right; a reader reading this text would read the letters in the order 'l', 't', 'r', ' ', n 'L', 'T', 'R' (which if you note matches the logical order, hence the name).

Now say you mouse down between the 't' the 'r' and drag right until your mouse is between the 'R' and the 'T'. Those are your selection endpoints. But the selection happens on the _logical_ text, so what's selected is the 'r', the space, the 'L', and the 'T' (and even in that order). You can see that in the example above; if you mouse down between the two 'o' chars in "elgooG" and drag right to between the two 'o' chars in "Google", then you get exactly this sort of behavior.

Ah, that makes sense. I didn't think that text selection defines end points and everything between the endpoints (in the physical text) is highlighted. So, if you have:

    Hi RLO elgooG
    ^ select ^

I expected (everything between the logical end points selected):

    Hi Google
    ^^^^^^^ (selected)

In other words, I expected text selection to obey RLO character as well.

Nope - selection is on logical text, not on visual text. For tons of "fun" reasons. If you want an afternoon of madness, read the Chrome or WebKit sources relating to BiDi text.

If that's not enough pain, read http://unicode.org/reports/tr9/ (the unicode BiDi algorithm)

If you're still liking it, I know a few people who'd love to hire you :)

I think you're confusing your logical and physical, or I'm misunderstanding you.

Moving your mouse happens over the physical text and sets the selection endpoints. Then everything that's logically (as opposed to physically) between those endpoints is highlighted. Your "I expected" diagram is showing the text physically between the endpoints, not the text logically between them...

Go to ‮http://www.yahoo.com/q=google+oohay=q?/moc.elgoog.www//:ptth :ta elgooG

This is really dangerous. Luckily the status bar reveals the real URL. However it's still dangerous when you use a visually trusted address like Gmail:

‮ http://nyan.cat/?0/u/liam/moc.elgoog.liam//:sptth

Inspecting the element with Chrome shows an amusing behavior. Try it.

How many failed 0x202Egp registrations do you suppose there have been in the last hour?

Reply on news.ycombinator.com