obfuscatr

Frequently Asked Questions

  1. What is this?

    Obfuscatr encodes the text you enter using several different common and useful methods.

  2. Why would I want to do that?

    The primary reason it was written is to protect your personal information from bots that crawl the web. For example, you may want to have a "mailto" link on your page, but might be concerned that spammers would harvest it and send you junk at that address.

    Using one of the two mailto encodings that Obfuscatr outputs will allow you to protect your address to some extent, because bots are usually unsophisticated and therefore unable to decode the hex/entity characters or javascript. Normal users will still see the link normally, however.

  3. What are the different encodings?

    • URL Encode

      This encoding is suitable for use in a URL (the address bar). To allow for spaces and other unusual characters, the characters in a URL may be represented by a '%' (percent sign) followed by the ASCII key code in hex. The URL encoding represents all characters you enter in this manner.

      Note: Internet Explorer does not handle '%40' (@) characters correctly in mailto links. The mailto encodings take care of this for you, but the plain URL encode will encode all characters that you give it, including the '@' symbol.

    • XHTML Entity Encode

      Each (X)HTML character can be represented as an entity. If there is no special name given to a character, it can at least be represented by its numerical character reference. Obfuscatr encodes each character into one of these NCRs, which are slightly more difficult to discern for bots that aren't expecting them.

    • XHTML Mailto Encode

      The XHTML Mailto Encode uses a combination of URL encoding and XHTML entity encoding to create a relatively safe representation of an email address in a "mailto" link. By default, the link text is the same as the email address, i.e. the text you submit to Obfuscatr.

      The email address in the URL is URL encoded, sans the '@' character, which is handled incorrectly by Internet Explorer. The link text is XHTML entity encoded – since it is the same as the email address by default, it needs to be protected too.

      If you wish to change the link text to something other than the email address, just submit the new text to Obfuscatr, and copy and paste the XHTML entity encoded version of it in between the <a> and </a> tags in the original mailto encoding.

    • Javascript Mailto Encode

      The javascript mailto encoding is the most "secure," in that it is the most difficult for a user agent to decode. As long as javascript is enabled, your real users should not have a problem seeing it. If javascript isn't enabled, though, your users will see nothing in its place. Make sure you know your users before choosing this method over the XHTML mailto encoding.

      First, the text you enter has each pair of two characters transposed. Inside the string that is unescaped and evaluated, there is a function which can transpose the characters again, returning your text to normal. A call to appendChild() is used to inject the link into a span element. At no point does your text appear unencoded in the document. It will not even appear in the source unless a tool (for example, the Web Developer Extension for Firefox) is used to retrieve the generated source.

  4. Can't server-side languages already do this?

    Yep. If you're using a server side language, it might be easier to just use your language's built-in features instead. For examples, see the Smarty mailto function, or the Rails mail_to function.

    Obfuscatr does have some advantages over those methods, though. For one, it will URL or entity encode any text, not just email addresses. You might find it useful to conceal something other than an email address.

    Second, it conceals the link text in your mailto link in addition to the email address. If the link text is the email address, you will obviously want to keep it hidden as well.

    If you are concerned about standards, you will be happy to know that Obfuscatr is the only javascript encoder that creates valid XHTML 1.1 output, even when the page is served as xhtml+xml. It does this by enclosing the script in a CDATA section in a manner that is backwards-compatible. It also avoids calls to document.write, which are no longer allowed, by inserting the unencoded XHTML into a pre-existing span element.

    Finally, the javascript encoding that Obfuscatr uses is much harder to decode than the one used by most web frameworks. The Smarty and Rails implementations above simply escape the text and then use document.write() to inject it into the page. All a bot would have to do to retrieve the email address is decode the escaped string. Doing so is no more difficult than decoding the hex values in a URL encoding (used in the XHTML mailto encode). Thus, the javascript encoding they use is no more secure than the hex encoding. Obfuscatr actually obfuscates the email address (along with the function to de-obfuscate it) before escaping it. Because of this, any bot that wanted to retrieve the email address would not only need to be able to decode the hex string, but also execute the javascript contained within it and parse the result.