<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Webroot Bulletin Regarding AV-Comparatives Results</title>
	<atom:link href="http://blog.webroot.com/2012/07/19/webroot-bulletin-regarding-av-comparatives-results/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.webroot.com/2012/07/19/webroot-bulletin-regarding-av-comparatives-results/</link>
	<description>WEBROOT - INSIGHTS INTO THREATS AND TRENDS FROM OUR INTERNET SECURITY EXPERTS</description>
	<lastBuildDate>Thu, 23 May 2013 07:00:37 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: JL</title>
		<link>http://blog.webroot.com/2012/07/19/webroot-bulletin-regarding-av-comparatives-results/#comment-63019</link>
		<dc:creator><![CDATA[JL]]></dc:creator>
		<pubDate>Mon, 23 Jul 2012 22:48:29 +0000</pubDate>
		<guid isPermaLink="false">http://blog.webroot.com/?p=7661#comment-63019</guid>
		<description><![CDATA[Thank you, Joe, for your generous offer and willingness to help above expectations.  At the time, Webroot researchers worked to troubleshoot but nothing was found.  Whether it was something that redirected DNS traffic or a simple http cookie with an imbedded iframe, never know for certain. Keep up the groundbreaking work; it&#039;s clear the product has improved over the past several months and may pave the way for the future of internet security.  And some feedback if you&#039;re willing. If Webroot built a dual layered product that offered cloud-based protection and client-based definitions engine, I&#039;d be interested even at a premium.  Don&#039;t mind the resource usage and system memory, traditional machines are built to accomodate those needs.]]></description>
		<content:encoded><![CDATA[<p>Thank you, Joe, for your generous offer and willingness to help above expectations.  At the time, Webroot researchers worked to troubleshoot but nothing was found.  Whether it was something that redirected DNS traffic or a simple http cookie with an imbedded iframe, never know for certain. Keep up the groundbreaking work; it&#8217;s clear the product has improved over the past several months and may pave the way for the future of internet security.  And some feedback if you&#8217;re willing. If Webroot built a dual layered product that offered cloud-based protection and client-based definitions engine, I&#8217;d be interested even at a premium.  Don&#8217;t mind the resource usage and system memory, traditional machines are built to accomodate those needs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: glhaldeman</title>
		<link>http://blog.webroot.com/2012/07/19/webroot-bulletin-regarding-av-comparatives-results/#comment-62388</link>
		<dc:creator><![CDATA[glhaldeman]]></dc:creator>
		<pubDate>Fri, 20 Jul 2012 18:55:34 +0000</pubDate>
		<guid isPermaLink="false">http://blog.webroot.com/?p=7661#comment-62388</guid>
		<description><![CDATA[The vast majority of threats are still blocked automatically - just in the case where we don&#039;t block a threat, we have the backup measures in place to continue protecting the system, unlike other security products which do nothing and allow threats to roam free. WSA applies a transparent sandbox which will limit the infections ability to affect the system and will automatically undo its changes even if they are complex and wide reaching. The generic information stealing trojan protection will prevent it from stealing user data or logging keystrokes. So, while our goal is to certainly block everything before it runs, you&#039;re still safe even if we miss it initially.

Hope that helps!

Regards,
-Joe Jaroch]]></description>
		<content:encoded><![CDATA[<p>The vast majority of threats are still blocked automatically &#8211; just in the case where we don&#8217;t block a threat, we have the backup measures in place to continue protecting the system, unlike other security products which do nothing and allow threats to roam free. WSA applies a transparent sandbox which will limit the infections ability to affect the system and will automatically undo its changes even if they are complex and wide reaching. The generic information stealing trojan protection will prevent it from stealing user data or logging keystrokes. So, while our goal is to certainly block everything before it runs, you&#8217;re still safe even if we miss it initially.</p>
<p>Hope that helps!</p>
<p>Regards,<br />
-Joe Jaroch</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: glhaldeman</title>
		<link>http://blog.webroot.com/2012/07/19/webroot-bulletin-regarding-av-comparatives-results/#comment-62387</link>
		<dc:creator><![CDATA[glhaldeman]]></dc:creator>
		<pubDate>Fri, 20 Jul 2012 18:54:49 +0000</pubDate>
		<guid isPermaLink="false">http://blog.webroot.com/?p=7661#comment-62387</guid>
		<description><![CDATA[It&#039;s hard to say at this point as redirection threats can take place at multiple levels, many of which don&#039;t require an active infection. We&#039;d be happy to help if you ever see something like this again, even if you aren&#039;t using a Webroot product. Just write into our support inbox and we&#039;ll help you diagnose the issue directly.

Regards,
- Joe Jaroch]]></description>
		<content:encoded><![CDATA[<p>It&#8217;s hard to say at this point as redirection threats can take place at multiple levels, many of which don&#8217;t require an active infection. We&#8217;d be happy to help if you ever see something like this again, even if you aren&#8217;t using a Webroot product. Just write into our support inbox and we&#8217;ll help you diagnose the issue directly.</p>
<p>Regards,<br />
- Joe Jaroch</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://blog.webroot.com/2012/07/19/webroot-bulletin-regarding-av-comparatives-results/#comment-62360</link>
		<dc:creator><![CDATA[Anonymous]]></dc:creator>
		<pubDate>Fri, 20 Jul 2012 16:12:03 +0000</pubDate>
		<guid isPermaLink="false">http://blog.webroot.com/?p=7661#comment-62360</guid>
		<description><![CDATA[So letting malicious code run and upload files is fine, as long as you revert all the changes in a few hours?]]></description>
		<content:encoded><![CDATA[<p>So letting malicious code run and upload files is fine, as long as you revert all the changes in a few hours?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: JL</title>
		<link>http://blog.webroot.com/2012/07/19/webroot-bulletin-regarding-av-comparatives-results/#comment-62352</link>
		<dc:creator><![CDATA[JL]]></dc:creator>
		<pubDate>Fri, 20 Jul 2012 15:34:34 +0000</pubDate>
		<guid isPermaLink="false">http://blog.webroot.com/?p=7661#comment-62352</guid>
		<description><![CDATA[Very informative piece, helps explain how WSA applies unique techniques to protect the client. While I no longer use Webroot, I am intrigued by your advanced products and continue to follow your development.  In light of your article, I am curious if you may have further information or clarification to a circumstance experienced on a client running WSA.  Having used Webroot for years, I uninstalled WSA on this client some months ago after I was getting redirected to fake AV download requests.  When the redirection recurred during separate randow browsing sessions, I did not notice any response from WSA in the browser protection or auto-protection.  WSA was monitoring select processes but no infection was blocked even after a couple weeks.  I installed a different security product on the client in addition to WSA.  Promptly this product&#039;s firewall blocked outbound malicious network traffic, which may have been a MD5 phoning out for the fake AV to intrude the system.  WSA scans and other scans still revealed no rogues. My question in light of reading your article, could it be that I was actually being protected by WSA even though I was repeatedly redirected to rogue AV website? It would be helpful if you can walk through an example.  I&#039;m not sure how to address the other firewall blocking outbound traffic, though.]]></description>
		<content:encoded><![CDATA[<p>Very informative piece, helps explain how WSA applies unique techniques to protect the client. While I no longer use Webroot, I am intrigued by your advanced products and continue to follow your development.  In light of your article, I am curious if you may have further information or clarification to a circumstance experienced on a client running WSA.  Having used Webroot for years, I uninstalled WSA on this client some months ago after I was getting redirected to fake AV download requests.  When the redirection recurred during separate randow browsing sessions, I did not notice any response from WSA in the browser protection or auto-protection.  WSA was monitoring select processes but no infection was blocked even after a couple weeks.  I installed a different security product on the client in addition to WSA.  Promptly this product&#8217;s firewall blocked outbound malicious network traffic, which may have been a MD5 phoning out for the fake AV to intrude the system.  WSA scans and other scans still revealed no rogues. My question in light of reading your article, could it be that I was actually being protected by WSA even though I was repeatedly redirected to rogue AV website? It would be helpful if you can walk through an example.  I&#8217;m not sure how to address the other firewall blocking outbound traffic, though.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
