<?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: Firefox Blocklisting: the quest for Safe and Happy</title>
	<atom:link href="http://blog.mozilla.org/webdev/2010/06/08/firefox-blocklisting-the-quest-for-safe-and-happy/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.mozilla.org/webdev/2010/06/08/firefox-blocklisting-the-quest-for-safe-and-happy/</link>
	<description>Engineering the web</description>
	<lastBuildDate>Fri, 17 May 2013 21:43:21 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Ken Saunders</title>
		<link>http://blog.mozilla.org/webdev/2010/06/08/firefox-blocklisting-the-quest-for-safe-and-happy/comment-page-1/#comment-212314</link>
		<dc:creator>Ken Saunders</dc:creator>
		<pubDate>Wed, 09 Jun 2010 21:16:19 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.org/webdev/?p=1050#comment-212314</guid>
		<description><![CDATA[My understanding is that security is Mozilla&#039;s top priority and I count on that so I have no problems at all with Mozilla disabling anything that could compromise my data. 
Does anyone remember losing everything when they used IE? For me it was more than once. If Microsoft did (or would do) what Mozilla does, then millions (perhaps billions) of dollars and thousands of hours would have been saved.

Now I&#039;m as much of an advocate for personal choice and control as the next person, but I think that Mozilla taking a &quot;Not on my watch&quot; attitude/approach is totally acceptable. I&#039;d rather a few users be pissed off than false statements being spread like &quot;My identity was stolen thanks to Firefox&quot;, or, &quot;My system was hacked and taken over because I used Firefox&quot;.

First and foremost though, and like Mike said, awareness should be the first step.
How often do users even bother to view the Plugins pane in the Add-ons Manager anyway?
If there is a vulnerable plugin, there should be a clear and strong alert that requires user interaction to close/disable the alert or to get info on what to do about it.
In the Plugins pane, stronger visualizations should be used too.
The green check mark is cool, but there should be icons and colors used for Vulnerable plugins too (like a red triangle with an exclamation mark), and they would be more noticeable and add more of a sense of urgency if they were under the Plugin&#039;s title.

I think that users identify needed or required actions with icons more than they do button colors, but both wouldn&#039;t be a bad idea.

In any event, thanks to Mozilla for looking out for us all.]]></description>
		<content:encoded><![CDATA[<p>My understanding is that security is Mozilla&#8217;s top priority and I count on that so I have no problems at all with Mozilla disabling anything that could compromise my data.<br />
Does anyone remember losing everything when they used IE? For me it was more than once. If Microsoft did (or would do) what Mozilla does, then millions (perhaps billions) of dollars and thousands of hours would have been saved.</p>
<p>Now I&#8217;m as much of an advocate for personal choice and control as the next person, but I think that Mozilla taking a &#8220;Not on my watch&#8221; attitude/approach is totally acceptable. I&#8217;d rather a few users be pissed off than false statements being spread like &#8220;My identity was stolen thanks to Firefox&#8221;, or, &#8220;My system was hacked and taken over because I used Firefox&#8221;.</p>
<p>First and foremost though, and like Mike said, awareness should be the first step.<br />
How often do users even bother to view the Plugins pane in the Add-ons Manager anyway?<br />
If there is a vulnerable plugin, there should be a clear and strong alert that requires user interaction to close/disable the alert or to get info on what to do about it.<br />
In the Plugins pane, stronger visualizations should be used too.<br />
The green check mark is cool, but there should be icons and colors used for Vulnerable plugins too (like a red triangle with an exclamation mark), and they would be more noticeable and add more of a sense of urgency if they were under the Plugin&#8217;s title.</p>
<p>I think that users identify needed or required actions with icons more than they do button colors, but both wouldn&#8217;t be a bad idea.</p>
<p>In any event, thanks to Mozilla for looking out for us all.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Tenser</title>
		<link>http://blog.mozilla.org/webdev/2010/06/08/firefox-blocklisting-the-quest-for-safe-and-happy/comment-page-1/#comment-212301</link>
		<dc:creator>David Tenser</dc:creator>
		<pubDate>Wed, 09 Jun 2010 12:53:03 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.org/webdev/?p=1050#comment-212301</guid>
		<description><![CDATA[This reminds me of the book Nudge, which is arguing that it&#039;s better to positively encourage people to make a change than to force the change upon them. The example here would be to tell the user what&#039;s going on and offer a choice, rather than force-block a plugin.  

For example, if there is a vulnerability in the version of QuickTime the user is running, instead of just blocking it, we could 1) inform about the vulnerability and what this means, and 2) allow the user to choose if he/she wants to remain vulnerable or disable the current plugin. In other words, put the user in control, but nudge him/her to do the right thing.

Of course, whenever possible, we should just upgrade the plugin, but the above example assumes there&#039;s no secure version out yet.

Thanks for a very well-written blog post!]]></description>
		<content:encoded><![CDATA[<p>This reminds me of the book Nudge, which is arguing that it&#8217;s better to positively encourage people to make a change than to force the change upon them. The example here would be to tell the user what&#8217;s going on and offer a choice, rather than force-block a plugin.  </p>
<p>For example, if there is a vulnerability in the version of QuickTime the user is running, instead of just blocking it, we could 1) inform about the vulnerability and what this means, and 2) allow the user to choose if he/she wants to remain vulnerable or disable the current plugin. In other words, put the user in control, but nudge him/her to do the right thing.</p>
<p>Of course, whenever possible, we should just upgrade the plugin, but the above example assumes there&#8217;s no secure version out yet.</p>
<p>Thanks for a very well-written blog post!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Lefevre</title>
		<link>http://blog.mozilla.org/webdev/2010/06/08/firefox-blocklisting-the-quest-for-safe-and-happy/comment-page-1/#comment-212300</link>
		<dc:creator>Michael Lefevre</dc:creator>
		<pubDate>Wed, 09 Jun 2010 11:43:20 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.org/webdev/?p=1050#comment-212300</guid>
		<description><![CDATA[&quot;For many users, it wasn’t clear what to do once their plugin or add-on was blocklisted.&quot;

I&#039;m sure all these other projects are great (I must admit I haven&#039;t read the details yet), but I don&#039;t see any of them addressing this issue, in the event that a plugin is blocklisted (which you acknowledge will continue to happen).

With the Java blocklisting, I don&#039;t think the problem was that the information about what to do did not exist, the problem was that Firefox UI links to a blocklist page with no context, which in turn sends people directly into bugzilla.

It may be that you just didn&#039;t mention it, but it would seem that simple changes to the current UI (or even just changes to the web page it currently points to) could make a huge improvement to the experience.

(Also, I&#039;m getting a 403 error on the Plugin update service link)]]></description>
		<content:encoded><![CDATA[<p>&#8220;For many users, it wasn’t clear what to do once their plugin or add-on was blocklisted.&#8221;</p>
<p>I&#8217;m sure all these other projects are great (I must admit I haven&#8217;t read the details yet), but I don&#8217;t see any of them addressing this issue, in the event that a plugin is blocklisted (which you acknowledge will continue to happen).</p>
<p>With the Java blocklisting, I don&#8217;t think the problem was that the information about what to do did not exist, the problem was that Firefox UI links to a blocklist page with no context, which in turn sends people directly into bugzilla.</p>
<p>It may be that you just didn&#8217;t mention it, but it would seem that simple changes to the current UI (or even just changes to the web page it currently points to) could make a huge improvement to the experience.</p>
<p>(Also, I&#8217;m getting a 403 error on the Plugin update service link)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Fred Wenzel</title>
		<link>http://blog.mozilla.org/webdev/2010/06/08/firefox-blocklisting-the-quest-for-safe-and-happy/comment-page-1/#comment-212286</link>
		<dc:creator>Fred Wenzel</dc:creator>
		<pubDate>Wed, 09 Jun 2010 06:28:05 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.org/webdev/?p=1050#comment-212286</guid>
		<description><![CDATA[I love the idea of a plugin update service, because often, people wouldn&#039;t even need to be so upset about a blocklisted version: They&#039;d just need to update to the latest version of that particular plugin. Making that easier would perhaps even remove any disruption to the user whatsoever: If you don&#039;t have a vulnerable plugin version, you won&#039;t notice it being blocklisted.]]></description>
		<content:encoded><![CDATA[<p>I love the idea of a plugin update service, because often, people wouldn&#8217;t even need to be so upset about a blocklisted version: They&#8217;d just need to update to the latest version of that particular plugin. Making that easier would perhaps even remove any disruption to the user whatsoever: If you don&#8217;t have a vulnerable plugin version, you won&#8217;t notice it being blocklisted.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan</title>
		<link>http://blog.mozilla.org/webdev/2010/06/08/firefox-blocklisting-the-quest-for-safe-and-happy/comment-page-1/#comment-212280</link>
		<dc:creator>Dan</dc:creator>
		<pubDate>Wed, 09 Jun 2010 01:14:58 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mozilla.org/webdev/?p=1050#comment-212280</guid>
		<description><![CDATA[And the dialog that pops up needs improving. The Cancel button is unclear - does it cancel the blocking or just cancel the restart?]]></description>
		<content:encoded><![CDATA[<p>And the dialog that pops up needs improving. The Cancel button is unclear &#8211; does it cancel the blocking or just cancel the restart?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
