Message Board

Bugs & Development

Older Posts ]   [ Newer Posts ]
 Problems with sample code for "invisible" Honey pot links
Author: M.Katsma   (23 Oct 07 3:53pm)
I signed up today, and started being an "active" member by placing a bunch of QuickLinks on pages hosted where I can't install a Honey pot. It was nice to see a number of link examples, but I found problems with them. Then, when I went and installed a Honey pot on one of my own domains, I found essentially the same collection of link samples, only this time linking to my own Honey Pot. The collection looks as follows - I'll number them for easy reference and discussion:

1. <a href=""><!-- hour --></a>
2. <a href=""><img src="hour.gif" height="1" width="1" border="0"></a>
3. <a href="" style="display: none;">hour</a>
4. <div style="display: none;"><a href="">hour</a></div>
5. <a href=""></a>
6. <!-- <a href="">hour</a> -->
7. <div style="position: absolute; top: -250px; left: -250px;"><a href="">hour</a></div>
8. <a href=""><span style="display: none;">hour</span></a>
9. <a href=""><div style="height: 0px; width: 0px;"></div></a>

The page on QuickLinks also states:
"You want your QuickLink to be invisible to normal users that browse your webpages, but visible to the malicious robots. To help you accomplish this, below are several suggestions for formatting your QuickLink that will be followed by most malicious bots, but will not be seen by human visitors to your site."

Unfortunately, not entirely true; here are my comments for each of the forms:

1. No problem here
2. TWO problems here: a) the code is invalid (an alt attribute is always required in an img tag!); b) for people with a visual impairment using a screen reader this will seem like a normal (but invalid) image link; this could be mostly solved by adding an *empty* alt attribute, but some older programs may still speak the link. Best solution is not to use an image link like this at all!
3. No problem
4. No problem in itself; but it would be useful to note that this form cannot be used in inline context: not within a paragraph (<p>...) or within a span (<span>) for instance.
5 & 6. No problem
7. Again an accessibility problem here: for people using a screen reader this will be a perfectly normal link, not "hidden" or 'invisible" in any way: there is no such thing as positioning in such a context, tags appear in the order of the text stream of the document. As with #2, the best solution is not not use a "positioned" link like this at all.
8. No problem
9. Invalid code: div is a block element, while a can have only inline content; you cannot wrap a link around a block: paragraph, div, list, etc.

So, in order to avoid "trapping" people using assistive technology like screen readers, it would be best to simply not include forms 4. and 7; if you must use 4. add 'alt=""' to the img tag to make it valid and have a fair chance it will be "hidden" for screen reader users as well.
Form 9. should not be used at all since it's simply invalid HTML.

To ease the pain of 'losing' three of the nine, here are two more suggestions (valid, and without accessibility problems):

a) <span style="display: none;"><a href="">hour</a></span>
b) <a href=""><span style="float: left; height: 0px; width: 0px;"></span></a>

a) is a variant of 4. but with the div element replaced by a span; this form can also be used in inline context.
b) is a corrected form of 9. - the div is replaced by a span, which is floated to make setting width and height effective.

 Re: Problems with sample code for "invisible" Honey pot links
Author: M.Prince   (23 Oct 07 6:29pm)
Thanks for your feedback. We definitely don't want to trap people with assistive technology. The good news is that simply visiting a honey pot does not label someone malicious, they need to subsequently send to an email address.

We'll look into revising the list of suggested linking formats to include those that you've suggested. Our goal is to ensure there are a number of different styles so that harvesters cannot easily figure out what is real and what is not. To that end, we strongly encourage anyone installing a honey pot or a QuickLink to come up with their own strategy to hide links.

Again, thanks for the feedback!

 Re: Problems with sample code for "invisible" Honey pot links
Author: M.Katsma   (24 Oct 07 1:39am)

> We definitely don't want to trap people with assistive technology. The good news is that simply visiting a honey pot does not label someone malicious, they need to subsequently send to an email address.

My worry is that once they end up on the honey pot page and find what fro them is some totally garbled page (that chopped up table code doesn't linearize and <font color=#FFFFFF> doesn't hide anything either!), they might be tempted to actually write to a likely-looking email address found on the page because they can't read the page! Obviously, the idea behind the design of a Honey Pot page is to make it look like a real "legal statement" to humans - but that strategy misfires for humans using assistive technology as well.

do not follow this link

Privacy Policy | Terms of Use | About Project Honey Pot | FAQ | Cloudflare Site Protection | Contact Us

Copyright © 2004–18, Unspam Technologies, Inc. All rights reserved.

contact | wiki | email