<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Coming soon&#8230; EmailShroud</title>
	<atom:link href="http://www.somethinkodd.com/oddthinking/2005/08/25/coming-soon-emailshroud/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.somethinkodd.com/oddthinking/2005/08/25/coming-soon-emailshroud/</link>
	<description>A blog for odd things and odd thoughts.</description>
	<lastBuildDate>Thu, 02 Sep 2010 05:01:01 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: OddThinking &#187; Happy Birthday OddThinking</title>
		<link>http://www.somethinkodd.com/oddthinking/2005/08/25/coming-soon-emailshroud/comment-page-1/#comment-3452</link>
		<dc:creator>OddThinking &#187; Happy Birthday OddThinking</dc:creator>
		<pubDate>Mon, 10 Apr 2006 05:38:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.somethinkodd.com/oddthinking/2005/08/25/coming-soon-emailshroud/#comment-3452</guid>
		<description>[...] First WordPress plugin: EmailShroud [...]</description>
		<content:encoded><![CDATA[<p>[...] First WordPress plugin: EmailShroud [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Julian</title>
		<link>http://www.somethinkodd.com/oddthinking/2005/08/25/coming-soon-emailshroud/comment-page-1/#comment-518</link>
		<dc:creator>Julian</dc:creator>
		<pubDate>Fri, 26 Aug 2005 08:01:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.somethinkodd.com/oddthinking/2005/08/25/coming-soon-emailshroud/#comment-518</guid>
		<description>&lt;!-- UnMarkedDown_2_01132522633--&gt;&lt;p&gt;Alan,&lt;/p&gt;

&lt;p&gt;You are right, and I had started to give this a lot of thought, until I thought: &quot;Forget it! You&#039;re dreaming!  Get the first version out, and then solve this problem in the unlikely case that it turns out to be terribly popular.&quot;&lt;/p&gt;

&lt;p&gt;In that initial period before I came to my senses, I realised that there are a number of solutions that can be used.&lt;/p&gt;

&lt;p&gt;One is to add customisation - in fact, the plug-in already has the ability to customise the NOSCRIPT part of the included HTML. They can have different obfuscations to their email address included here (e.g. adding &quot;NOSPAM&quot; or &quot;REMOVETHIS&quot; or replacing the @ sign with &quot;#AT#&quot; or &quot;@@@&quot; etc.)&lt;/p&gt;

&lt;p&gt;Another, is to make each release of the software slightly different, so the spammers will have to play catch up. As you suggest, a similar approach is to create a grab-bag of different solutions,  mixed randomly together.&lt;/p&gt;

&lt;p&gt;I currently favour a solution that requires the obfuscation to be decoded with a computationally-intensive algorithm. Having a user wait for a few seconds of seconds of computation to crack an email address would probably be acceptable to genuine readers, but not to spammers who have tens of thousands of pages to visit, especially if there were honeypot email addresses littered around each page, in places real users wouldn&#039;t notice or mouseover.&lt;/p&gt;

&lt;p&gt;If EmailShroud proves poopular enough for this to be a concern, I will look into how much of JavaScript would be required to implement such a solution. In the meantime, EmailShroud is a bit like a steering wheel lock; defeatable, but not worth the bother while there are other unprotected candidates to steal.&lt;/p&gt;

&lt;p&gt;It is important that a more secure solution be produced &lt;em&gt;before&lt;/em&gt; the spammers get their improved scripts sorted out. Once the system is cracked the first time, the email addresses harvested are permanently known, and are likely to be sold to others.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p><!-- UnMarkedDown_2_01132522633-->
<p>Alan,</p>
<p>You are right, and I had started to give this a lot of thought, until I thought: &#8220;Forget it! You&#8217;re dreaming!  Get the first version out, and then solve this problem in the unlikely case that it turns out to be terribly popular.&#8221;</p>
<p>In that initial period before I came to my senses, I realised that there are a number of solutions that can be used.</p>
<p>One is to add customisation &#8211; in fact, the plug-in already has the ability to customise the NOSCRIPT part of the included HTML. They can have different obfuscations to their email address included here (e.g. adding &#8220;NOSPAM&#8221; or &#8220;REMOVETHIS&#8221; or replacing the @ sign with &#8220;#AT#&#8221; or &#8220;@@@&#8221; etc.)</p>
<p>Another, is to make each release of the software slightly different, so the spammers will have to play catch up. As you suggest, a similar approach is to create a grab-bag of different solutions,  mixed randomly together.</p>
<p>I currently favour a solution that requires the obfuscation to be decoded with a computationally-intensive algorithm. Having a user wait for a few seconds of seconds of computation to crack an email address would probably be acceptable to genuine readers, but not to spammers who have tens of thousands of pages to visit, especially if there were honeypot email addresses littered around each page, in places real users wouldn&#8217;t notice or mouseover.</p>
<p>If EmailShroud proves poopular enough for this to be a concern, I will look into how much of JavaScript would be required to implement such a solution. In the meantime, EmailShroud is a bit like a steering wheel lock; defeatable, but not worth the bother while there are other unprotected candidates to steal.</p>
<p>It is important that a more secure solution be produced <em>before</em> the spammers get their improved scripts sorted out. Once the system is cracked the first time, the email addresses harvested are permanently known, and are likely to be sold to others.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alan Green</title>
		<link>http://www.somethinkodd.com/oddthinking/2005/08/25/coming-soon-emailshroud/comment-page-1/#comment-515</link>
		<dc:creator>Alan Green</dc:creator>
		<pubDate>Fri, 26 Aug 2005 01:32:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.somethinkodd.com/oddthinking/2005/08/25/coming-soon-emailshroud/#comment-515</guid>
		<description>&lt;!-- UnMarkedDown_2_01132522633--&gt;&lt;p&gt;Cheery thought for the day: this plugin will only be 100% effective so long as it is not widely used. If every WordPress user picks it up, it will be protecting enough high-quality addresses that it will be worth some email database vendor&#039;s time and effort to crack the protection. &lt;/p&gt;

&lt;p&gt;On the other hand, a small amount of protection goes a long way, as most harvesters would prefer to winnow the massive amounts of chaff laying around the &#039;net for easier pickings. It would also be possible for the plugin to use a variety of mechanisms and forms for shrouding, making it less cost effective for harvesters to crack.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p><!-- UnMarkedDown_2_01132522633-->
<p>Cheery thought for the day: this plugin will only be 100% effective so long as it is not widely used. If every WordPress user picks it up, it will be protecting enough high-quality addresses that it will be worth some email database vendor&#8217;s time and effort to crack the protection. </p>
<p>On the other hand, a small amount of protection goes a long way, as most harvesters would prefer to winnow the massive amounts of chaff laying around the &#8216;net for easier pickings. It would also be possible for the plugin to use a variety of mechanisms and forms for shrouding, making it less cost effective for harvesters to crack.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
