Hiding email addresses

Any email address exposed on the Web is likely to be harvested using a webcrawler and then beat up by spammers. (Congress made harvesting illegal in the CanSPAM law, which only demonstrates their loose grip on reality.) This creates a nasty tradeoff between accessibility and security. Having gotten much better (I think) at hiding from harvesters while remaining accessible, I have some suggestions to offer.

The first step is to use “throwaway” addresses (ones you can change easily) for email links. Most ISPs will allow multiple addresses; I keep two just for use on Web pages. That allows time for transitions: the one I’m abandoning remains available during the changeover, and maybe a while thereafter. If your ISP requires one of your addresses to be permanent, don’t use it for email links, and make sure it’s not listed in some online directory.

If you try the link at the top of this page, you’ll see my typical throwaway address. I use a combination of my initials (which happen to be an uncommon permutation), the date I create the address (just to keep track), and a random string of consonants (created with my random string generator), with some punctuation. I make the addresses long and junky so frequent changes won’t cut into the supply of nice-looking, simple addresses other subscribers might want to use.

Important note: If you do this very much, you will need to keep a list of places you use each address. Otherwise, you might make the mistake I did, and leave a link pointed to a bad address for a while.

The second step is to use a link encoding (commonly called an “obfuscation”) that reduces the likelihood of its being harvested by spammers. A lot of schemes exist, and many of them severely restrict the usefulness or accessibility of the link. (There’s a list of these, with notes, below.) I use a method I learned from Robert Graham*, because it is believed to be supported by all browsers.

^* Mr. Graham’s online description seems to have disappeared. I have found other sites that refer to this technique, but none of their links work any more.

Again, the link at the top of this page is an example. I have a link obfuscator available to help create links like this, if you care to try it. It requires JavaScript 1.2 to create links, but they can be used without script support.

Very important note: Do not try this encoding with an address that you aren’t willing to throw away. First, it will eventually get spammed. (I usually get Nigeria letters first; I think the senders are so low-tech they actually browse through and click links.) Second, it helps if spammers don’t expect it’s worthwhile harvesting addresses coded this way, because they’ll be abandoned as soon as the spam starts.

Several other schemes for hiding an email address are widely promoted. Here are some I’ve found, with reasons for using or rejecting them:

• Graphic addresses (not accessible) — The address is displayed as a graphic, so there’s no text for a crawler to find. Of course, it can’t be a link, because the crawler is looking for references as well as displayed text. The user has to read it off the screen and type it into the email; that’s not possible through a screen reader, because the letters are bit-patterns rather than character codes.
• Junk insertion (not effective) — If it’s obvious what to tweak to get a working address, then spammers can spot it, too. If it’s not obvious, then it’s no use publishing the address on a Web page.
• Junk insertion with style="display:none" (not very accessible or very effective) — Somebody passed this idea on to me, and I tried it. The address could be read off the screen, so it’s a little more useful than a graphic address, but attempts to cut and paste picked up the undisplayed junk. The most popular screen reader, Jaws, reportedly reads only the good part, but you’re still stuck typing the address back in.
• Scrambled addresses with scripted interpreters — I have used these where no “throwaway” address was an option. They require a script-enabled browser, which not only presents a barrier to users of assistive technology, but also has become more risky for Microsoft users because of their tendency to bypass standard security measures.

  Mine replaced the hyperlink reference if the script ran; the default (unreplaced) reference offered an accessible (form-based) alternative, although it was not quite as convenient as a mailto: link.

• Form-based email — If your Web server offers it, or supports the technology to build it yourself, this is a good possibility. Users type in their message on a Web page and never see the email address. The implementation should allow for <label> tags, which are a common technique for making forms more accessible.