Hikari Email & URL Obfuscator – Advanced Usage

By Hikari on Sunday, 21 Feb 2010, at 10:45:41 AM. Filed in | No comments

Hikari Email & URL Obfuscator is a Wordpress plugin that obfuscates emails and URLs, so that spam bots and search engine crawlers can't find them, while real users can.

I've already posted its main page with general info, now in this article I'm gonna present a tutorial teaching how to tweak it's custom parameters, to narrow a bit more its behavior. Stay tuned.

Index

What are these custom parameters after all??

I had created these custom parameters so that we can change the plugin's filter default behavior. With them, we can avoid a specific link from being obfuscated, or force it to be. With custom parameters we can also set how noscript obfuscation will happen, and force specific obfuscation solutions.

Custom parameters are set by special classes added inside class attribute, as many microformats do. Let's take that funny link exemple I've used before: <a href="mailto:no.spam@spam.com" title="c'mon mail me!" target="_blank" class="stylish-class">mail me</a>.

I had created special classes that, when present, change the obfuscation behavior. In the exemple, we can add parameters as follows: <a href="mailto:no.spam@spam.com" title="c'mon mail me!" target="_blank" class="hkmuob_obfuscate_content hkmuob_content_only stylish-class">mail me</a>.

Note we have 2 custom parameters there, hkmuob_obfuscate_content and hkmuob_content_only. Note they have the previx hkmuob, all of them has this prefix so that they don't conflict with other CSS classes. That's how we add parameters to our links, we can use as many as we want.

In the plugin's filter, each parameter presence will be verified, and if it is found its setting will be used. During parameters description I added exemples, see this page with JavaScript enabled and aldo disabled to better understand what each parameter does. Some of them will require you to look HTML source to see the difference.

One last note before start listing and explaining them: some parameters are concurrents, this means that their settings conflict with each other. In exemple, one parameter sets the link to not be obfuscated and other parameter sets it to be. In these cases, one parameter has precedence over the other, and the "loser one" will be ignored. These precedences are hardcoded, parameters order of appearance means nothing.

Ok, let's see these damn thingies

hkmuob_no_obfuscate

This parameter forces a link to not be obfuscated. When it is present, Hikari Email & URL Obfuscator's filter will just skip this particular link, leaving it alone in the HTML document, so that anything that loads it will clearly see its contents.

It is good for links to URLs you want search engines to find, as your friends sites, sponsored links, etc.

Exemple:

code you add: <a href="mailto:no.spam@spam.com" title="c'mon mail me!" target="_blank" class="hkmuob_no_obfuscate stylish-class">mail me</a>
result: mail me
Raw HTML that bots see: <a href="mailto:no.spam@spam.com" title="c'mon mail me!" target="_blank" class="hkmuob_no_obfuscate stylish-class" >mail me</a>

hkmuob_force_obfuscate

The opposite of the former one. hkmuob_force_obfuscate parameter forces a link to be obfuscated.

By default, internal links are not obfuscated, this includes relative links (without http:// ), and links that have your site URL ( get_bloginfo("url") ) on them. If, for any reason, you want an internal link to be obfuscated (or you find a link that should be and for some strange reason is not being), or just wanna assure a link is, use this parameter and it will be done.

hkmuob_force_obfuscate has precedence over hkmuob_no_obfuscate.

Exemple:

code you add: <a href="mailto:no.spam@spam.com" title="c'mon mail me!" target="_blank" class="hkmuob_no_obfuscate hkmuob_force_obfuscate stylish-class">mail me</a>
result: mail me (no NULL.spam null@null spam NULL.com)
Raw HTML that bots see: mail me (no NULL.spam null@null spam NULL.com)

hkmuob_obfuscate_content

By default only href content and all other attributes are obfuscated, link content isn't. Link content is the text that is shown in the browser: <a href="mailto:no.spam@spam.com" extra attributes>link content</a>.

The content can't be obfuscated by default because we can add a lot of stuff in it, primarily adding images, or any other HTML elements. If there are other elements tags inside the link and its content is obfuscated, these tags will be broken and strange behavior will happen.

In my tests, JavaScript perfectly decodes anything I've tested and presents it accordingly, but CSS obfuscation doesn't. if CSS reversion is used (currently disabled due to HTML validation issues), tags inside a link are not accordingly reverted back and instead of marking up they are presented as plain text. And if there is an email/URL inside a tag attribute (if you use a URL or email inside a tooltip title for exemple), new s are added and these tags are broken, making a mess in the HTML document and making it invalid.

BUT, if you don't use other HTML elements inside the link AND include in it URLs or emails that you want obfuscated (exemple: <a class="hkmuob_obfuscate_content" href="mailto:no.spam@spam.com">mail me: no.spam@spam.com</a>), you must use this parameter so that they are also obfuscated.

Exemple:

code you add: <a href="mailto:no.spam@spam.com" title="c'mon mail me!" target="_blank" class="hkmuob_obfuscate_content stylish-class">mail me @ no.spam@spam.com</a>
result: mail me null@null no NULL.spam null@null spam NULL.com (no NULL.spam null@null spam NULL.com)
Raw HTML that bots see: mail me null@null no NULL.spam null@null spam NULL.com (no NULL.spam null@null spam NULL.com)

hkmuob_content_only

This one is for noscript (CSS) usage only, it has no influence in JavaScript version.

It is meant to fix layout problems when JavaScript is not present. let's say you have a small structure being shown in your sidebar, and it has a link in it with a "click me" content and a normal-sized URL. Since noscript default obfuscation changes the "content" text to "content (link)", its occupied space becomes larger, maybe very larger. In this exemple it would be "click me (http://subdomain.domain.com/year/month/day/my-neat-article-with-a-large-title)". Imagine that in a 200px width sidebar!

Using class="hkmuob_content_only" in the link, it will go back to original "click me" text and your layout will be safe. Of course, the URL won't be present and visitor won't have access to it unless it enables JavaScript, and also the text will have wrong meaning since it's not a link anymore and it can't be clicked. That's why the next custom parameter was created.

It is also useful when link's content is an image, and you want it shown but don't want the " (url)" part, also to not break layout.

Exemple:

code you add: <a href="mailto:no.spam@spam.com" title="c'mon mail me!" target="_blank" class="hkmuob_content_only stylish-class">mail me</a>
result: mail me
Raw HTML that bots see: mail me

hkmuob_invisible_for_noscript

If link content has email/URL that must be obfuscated, but it can't be obfuscated in noscript version (because it has an image or any other HTML tag in it, for exemple), or if the content is useless without its URL/email, then unfortunately the link has no reason to be present at all.

If you don't want the link to be shown when JavaScript is not availble, use this parameter and it will be totally invisible. But will behave normally when JavaScript is used!

It has precedence over content_only and url_only.

Exemple:

code you add: <a href="mailto:no.spam@spam.com" title="c'mon mail me!" target="_blank" class="hkmuob_invisible_for_noscript stylish-class">mail me</a>
result:
Raw HTML that bots see:

hkmuob_url_only

Same idea as hkmuob_content_only, but its opposite. If for noscript you don't want content being shown (if it must be obfuscated but can't in noscript version, or lack of space, or lack of meaning, or you just want it gone), this parameter will do it. Obfuscated email/URL will be there alone.

This is also useful when href and content are the same, and you don't want it showing "email (email)" or "URL (URL)". Once is enough, isn't it?

As before, this parameter has no effect in JavaScript version. and if both hkmuob_content_only and hkmuob_url_only are present, they eliminate each other and both URL and content are shown, as if these custom parameters weren't used at all.

Exemple:

code you add: <a href="mailto:no.spam@spam.com" title="c'mon mail me!" target="_blank" class="hkmuob_url_only stylish-class">mail me</a>
result: no NULL.spam null@null spam NULL.com
Raw HTML that bots see: no NULL.spam null@null spam NULL.com

hkmuob_rot13

Following 4 parameters are used to force a specific obfuscation solution. When none of them are used, Hikari Email & URL Obfuscator plugin choose 2 randomly. But when any parameter is present, random code is skipped and forced solution is used. As I've said, if 2 noscript or 2 JavaScript solutions are present at the same time, the one with precedence will be used.

But only force any of them if you really have something against the other one, otherwise just leave randomization take place.

ROT13 is a very old and known encoding algorithm, it's used by JavaScript when JS is available.

But don't think that, just because it is very known, it is inneficient. In tradicional obfuscation softwares, spambots still need to search for and identify the data, find out it's encoded and ROT13 is the encoding algorithm, and run a ROT13 decoding routine to get the correct email. 1^st task is hard to be done (because it would force them to scan for a ROT13-like code inside all JavaScript stuff they find, while most of them are UI features and banners) and 2^nd task takes more processing time than they are willing to spend. So they just give up on emails obfuscated by JavaScript.

And if it's already hard to crack in traditional obfuscation softwares, with Hikari Email & URL Obfuscator plugin it's even harder, because the plugin separates the decoding code from the data to be decoded, making it even harder to find out, and also mixing ROT13 and cc8b together, making it EVEN harder .

Exemple:

code you add: <a href="mailto:no.spam@spam.com" title="c'mon mail me!" target="_blank" class="hkmuob_rot13 stylish-class">mail me</a>
result: mail me (no NULL.spam null@null spam NULL.com)
Raw HTML that bots see: mail me (no NULL.spam null@null spam NULL.com)

hkmuob_cc8b

Cc8b is another encoding method, and here it is used as a JavaScript alternative to ROT13. If for any reason you wanna avoid ROT13, force cc8b to go.

It is heavier to process and harder to find out and crack than ROT13, and also very unknown (at least I searched for it in Google and found almost nothing), and because of that it has precedence.

Exemple:

code you add: <a href="mailto:no.spam@spam.com" title="c'mon mail me!" target="_blank" class="hkmuob_rot13 hkmuob_cc8b stylish-class">mail me</a>
result: mail me (no NULL.spam null@null spam NULL.com)
Raw HTML that bots see: mail me (no NULL.spam null@null spam NULL.com)

hkmuob_display_none

That's a CSS property, more precisely display: none;. When a HTML element is set to display as none, it remains present in HTML document markup, but it is not rendered by browsers and any user-agents that support CSS.

What this solution does is add gibberish and spaces inside email and URL strings, so that anything that reads them in HTML document level will not indentify that there is an email/URL there. But when the browser renders our page, this gibberish is not rendered and real users see only the original text, indentifying what's there.

hkmuob_display_none has precedence over hkmuob_reversion.

Exemple:

code you add: <a href="mailto:no.spam@spam.com" title="c'mon mail me!" target="_blank" class="hkmuob_display_none stylish-class">mail me</a>
result: mail me (no NULL.spam null@null spam NULL.com)
Raw HTML that bots see: mail me (no NULL.spam null@null spam NULL.com)

hkmuob_reversion

CSS reversion uses its ability to present RTL text. Some languages as japanese are written from right to left, while european languages are from left to right. Since text tagged as RTL are reverted when browsers render them, if we take a LTR text and revert it using PHP, it will have no meaning in HTML document and its content will be unreadable, but then browser reverts it back and real users can see original content.

But CSS reversion is curently disabled, because when some HTML codes (exemple:   or &) are reverted by PHP, they may generate HTML invalid codes. I don't think obfuscation justify having an invalid HTML document, so I disabled it until I find a solution, which I believe doesn't exist. For now, display_none is always used, even if hkmuob_reversion parameter is present.

Exemple:

code you add: <a href="mailto:no.spam@spam.com" title="c'mon mail me!" target="_blank" class="hkmuob_reversion stylish-class">mail me</a>
result: mail me (no NULL.spam null@null spam NULL.com)
Raw HTML that bots see (if reversion isn't disabled): mail me (moc.maps@maps.on)

JavaScript x CSS

CSS solutions, unlike JavaScript ones, are not perfect, but they are usable.

CSS solutions are always used, they are the text that is originally present in HTML document, and is read by spammer and search engine softwares we wanna avoid. When JavaScript is used, it finds this original text and replaces it with a <a></a> code, in the same style of all links we are used to see.

With CSS we can't present a real and obfuscated link, so instead of it we use a plain text with the original link email/URL and its content.

But CSS disadvantage doesn't stay only in the lack of a clickable link. When a user sees these texts, with email/URL in them, of course they'll want to use it, and since they can't click, they'll have to Copy the email/URL to Paste it somewhere.

But, due to obfuscation, that's not possible. For visibility matters, they see original email/URL, but obfuscation is still there, and when they Copy the email/URL, what goes to clipboard is what's "behind the scenes", in the HTML document.

Because of this, previous exemples show our linked email as mail me (no.spam@spam.com), but when they copy it, what they get is mail me (no NULL.spam null@null spam NULL.com). of course, based on what they see, they can get this strange string and fix it, but it's annoying. And also, since this obfuscated string is larger than original link content, it may break layouts that don't have enough available space, this forces us to always test our texts (posts, pages, comments and mostly widgets) with and also without JavaScript.

It's annoying, but is still better than not delivering links to noscript users, or using those damn even more annoying you need javascript enabled to see this email!!! messages.

But also remember that less than 5% of web users don't have JavaScript available, so this lack of functionality is in practice only seen by a small percentage of our visitors. Most of them, who has JavaScript on, will see original link and not even guess it's obfuscated!

Manually filtering other links

As I've said everywhere, Hikari Email & URL Obfuscator plugin automatically filters 3 Wordpress content resurces: posts & pages, comments & comments authors, and text widgets.

But there are other places that may need obfuscated links, as theme texts, plugins resources and other widget types (please don't use it to obfuscate authors' copyright links if you are receiving their software for free!).

If you have direct access to a string that must be filtered for links that should be obfuscated, you can call the plugin's method directly, and pass this string as a parameter:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<?php

// first we repare our content with anything we want, and store it in a variable
$footerContent = "I'm a neat content with links inside." .
' <a href="mailto:no.spam@spam.com" title="c\'mon mail me!" target="_blank" class="stylish-class">mail me</a>';

// if the class exists, then the plugin is availabe and we can use it to obfuscate any content
// if not, then we just echo the original content without obfuscating
if(class_exists('HkMuob')){

// class is available, let's get its global variable
global $hkMuob;

// now we ask the plugin to filter our content and add any found link to plugin's internal queue
$footerContent = $hkMuob->filter($footerContent);

// now $footerContent has the same content as before, but with obfuscated links
}

// whether or not we were able to obfuscate our links, let's print our neat content
echo $footerContent;

?>

Another option, and the recommended one, is use Wordpress hook system, adding it as a filter. Let's say you have a filter in your plugin/theme:

1
2
3
4
5

<?php

$content = apply_filters('prefix_content', $content);

?>

(Pay attention to the importance of using prefix in your code)

If you have a filter hook available or you can create one, it is preferable to obfuscate it using:

1
2
3
4
5
6
7
8
9
10
11

<?php

if(class_exists('HkMuob')){

global $hkMuob;

add_filter('prefix_content',array($hkMuob,'filter'));

}

?>

With this simple code you will have your content being filtered as a magic

If you are the author of a theme or a plugin and wanna add support to email and URL obfuscation, please contact me so that we can define together who will have the filter code, where it's best to include it and what's the ideal hook priority. I've already faced incompatibility with 2 plugins I use and had to adapt my code to support them, so it's good to have deep control to avoid bugs.

If you are a plugin/theme user and wanna add obfuscation to a filter, also contact me and maybe I can include it in main distribution

Conclusion

For now, that's it. Hikari Email & URL Obfuscator plugin is still somehow simple, it's been 2 weeks I'm developing it. There are a lot of features I wanna implement, and some of them are essencial and top priority.

With this starting article it becomes possible for users to start tuning their links. Unobstructive JavaScript is a burden because it forces us developers to test everything twice, for when JavaScript is being used and when it's not available. But this is the standard today and quality must be in top of our importance and priority list.

This post will be updated when new features arrive. Soon I'm gonna publish an article only with usage exemples, extending exemples presented here.

I've already seen a few sites using my plugin and I'm very happy with it. I'd like some feedback, saying what must be improved and what's most needed. If people help me test it I'll have more time developing and the software quality will improve faster.

Popularity: 12%

This article was posted on Sunday, 21 Feb 2010, at 10:45:41 AM, 14 years, 7 months ago; and is filed under

It has accumulated a total of 32,257 views. You can follow any comments to this article through the Comments RSS 2.0 Feed. You can leave a comment, or trackback from your own site.

Trackback URI | Comments RSS |

Comentando vc contribui e participa na criação do conteúdo do site.
Contribua. Commente. :)

(Os comentários abaixo representam a opinião dos visitantes, o autor do site não se responsabiliza por quaisquer consequências e/ou danos que eles venham a provocar.)

Hikari WebSite

Hikari no Tsubasa

Hikari Email & URL Obfuscator – Advanced Usage

Index