 |
|
 |
What makes you think that the bots would not pick up on the 'emailName="test@test.com"' in the HTML and peel out the test@test.com address?
Gary G
|
|
|
|
 |
|
 |
The control is rendered on the server so that bot/user will never see the server tag: <cc1:EmailImage id="EmailImage1" runat="server" cssclass="emailname" emailName="test@test.com"></cc1:EmailImage> They will only see the rendered image.
So there is no e-mail address that can be stripped from the rendered html.
Ray
|
|
|
|
 |
|
 |
Thank you, Ray!
Yes, the html rendered would look something like:
<input type="image" name="Ib0020002001" id="Form1_IbIb0020002001" class="024" src="WebResource.axd?i=n7unGUTDPE30FE1NluKD7g2" önclick="javascript:WebForm_DoPostBackWithOptions(new WebForm_PostBackOptions("ctl00$Form1$ctl02$IbClickContact", "", true, "", "", false, false))"/>
so, there isn't much to harvest in terms of e-mail addresses if you don't follow the button.
But bots apparently follow links and are even able to fill in forms and submit them. Hence, you would still be vulnerable if the bots follow every input type="image" they find. If they aren't already out there, I am sure they eventually will come around.
Perhaps one could further backstop the control with bot detection code of sorts in code behind (I know this is hard to do, as they are spoofing the user-agent, but there are at least some lists out there of known bots).
Here is another thought: perhaps it would be possible to employ javascript to force human interaction (i.e. have the button image remain disabled until a mouseover event enables it, for example?)
I am no expert on the subject, so I invite anyone who can help shed some light on the subject to comment. Perhaps we can all learn something.
Here are a couple of interesting references on the topic:
Wikipedia definition[Wikipedia definition]
And here is one with hands-on experience:
how to block spambots ban spybots and tell unwanted robots to go to h...[^]
Jokva
|
|
|
|
 |
|
 |
Using images is a good idea - but it should also be mentioned that if your app is required to meet basic web accessibility guidelines (Which I know some governments enforce for their departments web sites) this is not a solution you can use, by putting the image in there with no alt text to describe what the image says you will fail on that one.
I think the JavaScript idea works reasonably well, but again there are accessibility issues with that as well.
But from what I have found, if someone wants a bot to rip email addresses off your page, they can generally find a way to do it. The W3C have a good article on these 'CAPTCHA' style form controls at http://www.w3.org/TR/turingtest/[^]
But then again if you don't need to care about accessibility (Well shame on you! ) then none of this matters and the control should provide at least some sort of protection of your email address.
---------------------------------------------------
Brian Farnhill
souls_end@hotmail.com
"I wish the real world would just stop hassling me ..."
|
|
|
|
 |
|
 |
Thanks, Brian!
Interesting points, and interesting article. I've so far remained reasonably uneducated on accessibility other than what basic xhtml validation requires.
Not to argue semantics, but wouldn't alt="click to get in touch with us" suffice to satisfy the standard, and also reasonably satisfy any accessibility criteria (i.e. the purpose being to make the content understood by people with disabilities)?
I mean, when the alternative is to perhaps have the user fill in a captcha protected form where you would have no alt tag on the captcha image whatsoever, this might actually be the better option, or no?
I should underline that the client wants the e-mail address exposed to real people visiting the site, and would therefore welcome any real person to use the e-mail addresses (for whatever purpose).
It must further be assumed that the client (site owner) is using alternative, forwarding addresses and tight spam filtering on these accounts. If it is out there, its out there.
That having been said (as you may tell from my English, I am not from, nor living in, the US), I find that there are surprisingly many gov't agencies around the World that willingly expose e-mail addresses on their sites. Due to Brian's input, I am now beginning to believe they do this to satisfy these accessibility criteria.
How they sort out the spam, I have no idea. I imagine they could benefit from such a control, too. Hence, to make the control meet all accessibility criteria is definitely on!
So, to incorporate some of Brian's concerns, here are some more suggestions (to whoever is writing the control):
(I think) it is possible to have the mailto: response add the subject line, hence the subject line could be used as a first line defense against other type spamming resulting from people manually collecting e-mail addresses.
Another trick I have picked up while reading about this is the possibility to add a "honey trap" in the control itself, i.e. to add an additional, hidden input field to the control which the postback checks for content (if there is data in it, you can be sure this is not a human). I suppose the honey trap control will have to be "masked" by a div control, as defining its visibility would be a dead give-away.
Hence, a (databindable) Alt property is hereby on the requirements list. So is a Subject property, and perhaps a HoneyTrapCaption
Jo
Jokva
|
|
|
|
 |
|
 |
Sorry, but Brian's post got me thinking, so let me just get this off my chest while it is still fresh in my mind.
How about hooking the control to a SpamBot WebService? Assuming the honey trap would really work, one could set up a simple web service that uses the control input to harvest spam bot IP addresses. If a requesting client lands in the honey trap, the control could be set up to add the IP address to the usual suspects list.
Likewise, the subscribing control could check if the client IP address is listed before responding. If a match is picked up, the spam bot is simply redirected to a page containing a long list of non-existing e-mail addresses (spam the bot!).
Make the control free of charge, but charge for the web service. All you need is a few thousand subscribers, and your're in business!
Jo
Jokva
|
|
|
|
 |
|
 |
Theres definately some interesting ideas there (I like the sounds of the Honey trap, I havent heard of doing it like that before so it would be interesting to see it in practice).
I actually work for an Australian government department, so we're always on the ball for accessibility stuff. We use an email form though rather than exposing important email addresses, and for the emails that are exposed we rely on our anti-spam software that takes effect at the mail server.
As for the alt tag on the image, I suppose it could be interpreted that having "Contact us" on it could be passable, but really the alt tag is supposed to be used to describe the image, so in theory the most correct interpretation would be to describe the email address stored in the image. Again like you said its semantics and it would depend on how big of a priority accessibility is for your site.
So i guess the best way to look at this is to prioritise how much spam your might find yourself getting as well, and if that is a big enough issue as to just put up with the accessibility issues that using the image instead of text would cause. Like I said, I work for the Australian government, so we don't get a choice, so between good spam filtering and email forms for the really important people, we get by without breaking those rules.
But the bootom line is that hiding email addresses from bots is really a fairly tricky thing to do successfully and to meet those guidelines
---------------------------------------------------
Brian Farnhill
souls_end@hotmail.com
"I wish the real world would just stop hassling me ..."
|
|
|
|
 |
|
 |
Thanks again, Brian!
Signing your forum posts with full name and e-mail address, I suppose your slogan "I wish the real world would just stop hassling me ..." could be extended with "...moreover, I wish the virtual world would stop spamming me!" : )
One more thing on accessibility: You mentioned that locking the control using javascript also has implications. By that, I am assuming you are referring to disabled not making use of a regular mouse pointer, or...? Not certain I follow you (know too little about the web and disabilities), so please elaborate.
I have never tried a honey trap myself. I suppose one way the bot could bypass it is to only fill in fields that meet a pattern of client side validation required (however they would do that) and then simply skipping those fields that are not required? Hence, maybe a "fake validation" (required, but accepts null?) could counter that. Provided that it is added as just another form field/label and simply masked with an absolute positioned div, or rendered behind another control in the form, there should be no reason why the bot wouldn't fall for it. Why don't you add one to your e-mail form and let us know what happens?
Cheers!
Jokva
|
|
|
|
 |
|
 |
Yea, the email address I sign these posts with is not my primary personal one, its one that I just use for forums and other websites, so people can spam that one as much as they like! :-P
(For the record the real reason behind the second line though is that Im just a massive Matchbox 20 fan!)
Anyways, the reason JavaScript could be a problem, is that to meet accessibility standards you are required to allow access to exactly the same data with javascript turned off as you can when javascript is turned on in a users browser. So if you were using some sort of javascript to hide the email address or dynamicly display it, you would be required to have a way that it can still be displayed with JavaScript disabled. The second reason you srot of touched on, and that the onClick and onMouseOver events that most HTML elements have are useless if a user is not using a pointer device (like a mouse).
As for the Honey Trap, Im not totally convinced that if someone wanted to fool it badly enough and fake a real person request, that they could. I don't have the luxory of being able to try it on our form though, I need to convince 76 Senators that its a good idea ... not likely to happen any time soon!
I sorta touched on this before - it all comes down to risk management, and how much of a risk you think publishing your email addresses is to your clients. If the risk is really that great, use an email form and hide them all together, if accessability is not that big of an issue, then go with an image control like this, but if you don't mind having your emails publishedd and/or think your spam filter can knock out most of the spam (well if thats the case yiu probably wouldnt have read this far down the article) then just publish the emails.
---------------------------------------------------
Brian Farnhill
souls_end@hotmail.com
"I wish the real world would just stop hassling me ..."
|
|
|
|
 |
|