Reforming rot13
rot13.com is a service frequently used here to hide spoilers. I really hate it, though. If I had the time, I would build a simple, but much better alternative. Maybe somebody has more time to do that, so I’ll share my rough specification:
Dynamic. The encoding happens on the client automatically, whenever the content of the input textbox changes. No Submit key needed.
Fully client-side. No server-side script, just a static page with Javascript.
Decoded content can be reached through an encoded URL. Instead of the receiver pasting the ciphertext into the rot13.com textbox, the sender can provide an encoded URL, and the receiver simply clicks on the link. This is slightly less convenient for the sender, but is much more convenient for the (hopefully many) receivers.
Many people can decrypt parts of rot13 ciphertexts without conscious effort. This defeats the purpose. The new service could provide some alternative encryption that is not a substitution cipher. It should still be a reciprocal cipher, that is a nice property of rot13.
rot13 fails for non-ASCII characters. (rot13.com leaves them intact.) The alternative encryption should work for all Unicode strings.
Strong, password-based encryption could also be added as an extra feature. I could send you a very long URL, and tell you a password on the phone, or only tell you the password at a later date.
The only important design problem I don’t know how best to solve is making the encryption work for Unicode, with the following three constraints: making it a reciprocal cypher, outputting visually nice strings, and making it map ASCII to ASCII. One possible solution is to drop the constraint that it is a reciprocal cypher. For this service it is probably not crucial anyway: the ciphertext can be base64, with some escape prefix distinguishing it from plaintext.
After writing the above, I found this LW thread: Does anyone else find ROT13 spoilers as annoying as I do? There were several suggestions there, and two of the commenters, sketerpot and LightningRose even coded their own solutions to the spoiler problem. Each solution had some merit, and LightningRose’s in particular was far superior to the rot13.com site I used to use, but basically, they only dealt with the third point of my proposal.
Is there anything like what I envision? Is anyone interested in building it? What changes or extra features would you like to see?
The purpose of rot13 is hiding of spoilers. An improvement over current situation should be in methods for hiding spoilers, not in methods for managing rot13, which is a lost purpose. (I realize the post applies to use of rot13 alternative on arbitrary sites, but that particular conversation shouldn’t be on LW.)
What is needed is support for spoiler markup and hidden-until-activated rendering. This is how it’s implemented as an extension to Markdown on Stack Exchange.
Seconded. Although I’d say discussion of rot13 alternatives is relevant to LW-Meta until the site itself supports proper spoilers.
I agree that site-specific solutions are superior (if they are actually implemented). I agree that considering this, my original post was quite off-topic. Fortunately, my original off-topic thread about a proposed general solution was hijacked into an on-topic conversation about the best LW-specific solution. I think satt and Misha gave a quite acceptable temporary solution that would deserve some more visibility. Meanwhile, HonoreDB implemented my proposal (big thanks, HonoreDB!). So everything turned out fine.
It’s done in this thread.
I think one alternative works right now, although it’s not elegant: use Markdown’s ability to add a title attribute to links for spoilers. Make a link (a spurious one pointing nowhere, if necessary) with the bracket syntax and then, after the URL, add a space and your spoiler text in double quotes. The Markdown would look something like
An example: hover over this text.
This isn’t a disinterested suggestion, by the way. I find ROT13 far more annoying than spoilers so I’d prefer a simple hover-to-reveal trick.
This brings up something I’ve been meaning to figure out for a while: is it possible to get to hovertext (on images or hyperlinks) on smartphones? Touchscreens don’t really support mouseover, after all.
If not (and all my research indicates not), this would be rather annoying for me, as that’s how I most frequently access the site.
I was thinking about this question today and had an idea: instead of putting a fake URL, link to a ROT-13 site like decode.org with a URL that decrypts to the desired text. Thus, if you wanted to say “Snow is white” in a spoilered fashion:
equals
Good question. I don’t have a smartphone and don’t know. And now I think a bit more about it, I wonder about screen readers. If screen readers indiscriminately read out links’ title text then people using them would automatically get spoiled.
First of all, if you’re using Firefox, just install some addon like “LeetKey” which allows you to rot13 by selecting the text and choosing ROT13 from the popup menu, or even by using some shortcut key. It’s stupid to have to go to a different site to decode, regardless of whether it’s javascript-based or server-side scripted.
Secondly, we just need an enhancement of the available markdown tags like siodine suggests in a comment below.
I came here to suggest LeetKey too. It’s client side, and supports a number of reversible transformations. Most of the encryptions work with all types of punctuation (morse/rot13 being the exceptions). Some people might be able to decrypt rot13, a handful morse, and a couple hexadecimal; nobody is going to accidentally read AES encryption. It supports password based encryption/decryption for those encryptions that require it. Also, it’s free and easy to use. The following encryptions all took about 2 seconds each. If we were all using leetkey, swapping to a new spoiler type would be as easy as picking and choosing.
Here’s a spoiler in Rot13. Urer’f n fcbvyre va Ebg13.
Here’s a spoiler in base64. SGVyZSdzIGEgc3BvaWxlciBpbiBiYXNlNjQu
Here’s a spoiler in AES encryption. (Key: lesswrong)
XqqfeDMBITAhITAhLV5g2FnewrRa20y8iuzAA/AttnBO8f40jPAUYDulZnYyVi16mco=
You can also type in reverse, if you really want. .tnaw yllaer uoy fi ,esrever ni epyt osla nac uoY
Edit: Removed binary, morse, DES encryption, etc because they looked really annoying on the page and that many examples were unnecessary.
I like this solution.
(Dislike presence of tooltip text obscuring the text already appearing in the mouseover area. No need for the many flavors of specialized spoilers.)
Strongly agree, though I don’t think it’s worth the effort to implement a new spoilers standard on the boards considering how rarely I see any posts containing spoilers AND how few people can naturally read rot13
Here’s the code. Should work for lesswrong too, I think.
I’ve written something to your spec, tested it briefly in a couple browsers. It uses a bitwise not on the unicode values, basically the generalized version of rot13. It’s technically still a substitution cipher, but due to the way high-value unicode tends to display it’s going to be much more difficult to accidentally learn.
Spoilers
ﾺﾇﾞﾒﾏﾓﾚￍ
The service now will display arbitrary html, and autogenerates formatted markdown links.
That’s very cool, thanks a lot! I think it has a chance to become the de facto standard solution to a very obscure problem, if it gets some momentum. :) I don’t think the bitwise-not is the best choice, though. Right now I don’t have any time to improve it, but I’ll try to make others interested, if you don’t mind.
Go ahead. Feel free to steal, modify, redistribute, etc. Also, I made a new version that enables passwords and maps printable ascii to printable ascii. You seem to have nerd-sniped me.
Pmor5mxgoszghb>$hlmd5~{t!23ryk2fmqqhfi4nou?3~|2vafoqgcwa|!r}s/wew|&uz,}m
mv~raf*$%Soyeke0u{|dj2psj*!}ccefda?7ff$fjri5{{r{r3|y/sj}%so|o{du!p{v}sgpt!tbp qmdrn|2gkkpdgxgsz}cnpha%grve} dn3cef|pegjd5mgcyh=37Ff$|jtr5x|e0gzer/~aevr!fesnygzpvaf$flrr5cr up{7lzevdeup~4wyu{3cgw$gjtspsdo~ez}p/qlewgbaif og3ghj2tevuvz~p,0vargp{jc%gszyzd0u|3cgw$fah{b}nw!d{ra2mp%adas4to!g{r/wj%ig5x|e0qrdx}v%uugezg>!3Ry/s`lrhzbul0mz}r/bvascoas4acbzz7> 3$ctnx,veyot3pj|avdrdq,}f0hg4d/|kp%rip~q yo3ghj2kvlah{mx ddkg9/2Pk%rsl,}t0nfg;/wmq&u}i4boy3|y/fla%jdsx4a~e?3xpfmkkgmyu8 div3gnawsjte5j}e|e=That’s very-very cool. And I even learned a new phrase.
It’s been packaged on *NIX systems forever. On Debian and Ubuntu, it’s in the package “bsdgames”.
Like most traditional unix utilities, it reads from stdin and writes to stdout, so if you have xclip or xsel installed you can copy the text in question, then run
xsel -ob | rot13 | xsel -ib
and then paste the rot13′ed (or un-rot13′ed) text.
You could even bind it to a key combo without too much trouble.
How does one happen to acquire this skill?
Presumably by practice. I am careful to always use rot13.com rather than decoding mentally, to prevent myself from accidentally picking up the skill.
People are differently good at linguistic skills. My experience in yeshiva demonstrated this to me. Aramaic is a language related to Hebrew, and in yeshiva it is very, very often read and never written or spoken, nor are new thoughts generated in it. Hebrew is used in Israel, the outside world for Americans learning in Israel, so it will be read frequently, and spoken and heard sometimes. English will be how Americans communicate with each other, even when learning things in Hebrew or Aramic. Yiddish is heard and spoken to various degrees in different places.
One guy at my yeshiva was, as a gimmick or parlor trick, able to speak fluently about mundane topics in (Babylonian Jewish) Aramaic without any paying any special attention to trying to learn to do it, in a way that seemed magical to me. This guy also learned to understand, read, speak, and write in Yiddish and Hebrew with apparently zero effort. In general, he wasn’t very smart. Some non-Americans developed perfect understanding of spoken English without being able to speak much at all. Some native Hebrew speakers were able to read Aramaic after just a bit of practice, others learned much more slowly than even average English speakers, as the Hebrew speakers were confounded by the similarities amid differences. And, of course, most people had their separate skills in a language partially correlated instead of entirely correlated or uncorrelated, and their Aramaic and Hebrew skills loosely correlated.
The stereotypical case is of an illiterate person who can’t read or write, making one think that those skills are inherently harder than listening or speaking. I don’t think that any of the four skills is inherently the hardest or easiest for all humans.
I expect people’s ability to learn rot13 to vary greatly.
A more lowbrow example:
The webcomic “Order of the Stick”. for a while, had a character who was unable to speak intelligibly as the result of a curse. This character’s speech bubbles were full of meaningless strings of letters. However, as I read it it became pretty clear that there was some kind of substitution going on. It was a simple substitution cipher, so it was possible with some effort to make sense of this character’s dialogue. The cipher would change every few strips, and I’m not aware of any clue or key given within the comic itself.
Figuring out how to read this had a little to do with knowing the typical frequency of letters in English, but was probably more down to context (predicting what the character might say) and the fact that the length and capitalization of the words remained intact.
I just checked an old episode there, and was very quickly able to decipher the unintelligible dialogue, but this was almost entirely down to knowing the context. I remember when I initially read it, I more or less memorized the ciphers without specific effort.
Predicting what a rot13ed text might say could be a factor, and in my experience it was not particularly difficult to assimilate similar ciphers once I was reasonably confident my decryptions were correct.
People using emacs to edit text boxes, for example when using It’s all text! or org-protocol can use M-x rot13-region (after the text-to-be-rot13′ed is marked/selected).
Interestingly, there’s also M-x toggle-rot13-mode, which, when enabled, translates the current window to rot13, including your input.
For non-ascii encoding, maybe base64 would be useful? M-x base64-encode-region and M-x base64-decode-region are your friends here. If people find substitution cyphers to easy tor read, the text could simply be reverted (M-x reverse-region). That should work well enough for most people...
Edit: quick hack for reversed base64:
Make an easy-to-get-to bookmark in your browser, and paste this into where you’d normally put the link to the web site:
javascript:inText=window.getSelection()+″;if(inText==″)%7Bvoid(inText=prompt(‘Phrase...‘,″))%7D;if(!inText)%7BoutText=‘No%20text%20selected’%7Delse%7BoutText=″;for(i=0;i%3CinText.length;i++)%7Bt=inText.charCodeAt(i);if((t%3E64&&t%3C78)%7C%7C(t%3E96&&t%3C110))%7Bt+=13%7Delse%7Bif((t%3E77&&t%3C91)%7C%7C(t%3E109&&t%3C123))%7Bt-=13%7D%7DoutText+=String.fromCharCode(t)%7D%7Dalert(outText)
Now, select the text you want to rot13 and click this bookmark.
I can’t remember where I got this from, it’s been in my browser for ages.
[Edit: someone added a different one below, so I guess you have a backup if either doesn’t work on your browser].
This is an improved version of that bookmarklet.
I’m personally much happier using a rot13 bookmarklet rather than having to use an external site to decode the spoiler text. If your alternative comes with a bookmarklet I can use to decode, I’m willing to use that; otherwise, I’d rather people stick with rot13 coding.
I agree that a bookmarklet is preferable to external applications. And in that vein, I’ve adapted this one so that it does in-place encoding/decoding both of normal text and text inside textboxes (like this: na rknzcyr).
(I’ve only tested it on newer versions of Firefox and Chrome)
Irel hfrshy!
Thanks!
(When I saw this in my inbox, I was very very confused, until I realised its context.)
If you’re going to be giving a link to another website anyway, then what’s the point of the encoding?
If the other website stores the content, like pastebin.com or sketerpot’s solution, then the content will be irreparably lost when the website goes offline. If the content is in the URL unencoded, then mouseover uncovers it.
Assuming I have my Markdown syntax correct, that can be avoided by providing alternate mouseover text.
Here is an example.
Edit: it seems that this is a partial solution… my browser still shows the URL when I mouse over the link, but it’s out of the way and easy to ignore.
Does anyone want to volunteer for hosting it?
Why would it need to be a reciprocal cipher? From what I understand, you go to the website and type it to encode. You click a link to decode.
There’s a significant advantage to it not being reciprocal if it’s encoding non-standard characters. If it’s reciprocal, it would have to be based on a set of all printable characters. If not, you could do whatever crazy stuff you want, then add the escape() command so what you end up with is printable.