<?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"
	>
<channel>
	<title>Comments on: Browser-based mitigation of phishing attacks</title>
	<atom:link href="http://dready.org/blog/2007/01/22/browser-based-mitigation-of-phishing-attacks/feed/" rel="self" type="application/rss+xml" />
	<link>http://dready.org/blog/2007/01/22/browser-based-mitigation-of-phishing-attacks/</link>
	<description></description>
	<pubDate>Tue, 14 Oct 2008 03:14:24 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: Kim Cameron&#8217;s Identity Weblog &#187; Can browser-based plugins solve the phishing problem?</title>
		<link>http://dready.org/blog/2007/01/22/browser-based-mitigation-of-phishing-attacks/#comment-9010</link>
		<dc:creator>Kim Cameron&#8217;s Identity Weblog &#187; Can browser-based plugins solve the phishing problem?</dc:creator>
		<pubDate>Mon, 12 Feb 2007 05:35:12 +0000</pubDate>
		<guid isPermaLink="false">http://dready.org/blog/2007/01/22/browser-based-mitigation-of-phishing-attacks/#comment-9010</guid>
		<description>[...] Dready blog proposes writes about OpenID phising and proposes a browser plugin that introduces a delay in the dialog box before it can be dismissed. The OpenID phishing issue is a hard one to solve, particularly because it aims to: [...]</description>
		<content:encoded><![CDATA[<p>[...] Dready blog proposes writes about OpenID phising and proposes a browser plugin that introduces a delay in the dialog box before it can be dismissed. The OpenID phishing issue is a hard one to solve, particularly because it aims to: [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: wil</title>
		<link>http://dready.org/blog/2007/01/22/browser-based-mitigation-of-phishing-attacks/#comment-8863</link>
		<dc:creator>wil</dc:creator>
		<pubDate>Mon, 22 Jan 2007 00:40:47 +0000</pubDate>
		<guid isPermaLink="false">http://dready.org/blog/2007/01/22/browser-based-mitigation-of-phishing-attacks/#comment-8863</guid>
		<description>@Claus:

This is just how Firefox displays IDNs where the TLD is not on their whitelist (and ".com" is not.) For IDNs on the whitelist, this will render properly in Unicode.

I should have made this clear and show just an ASCII case, thanks for the clarification.</description>
		<content:encoded><![CDATA[<p>@Claus:</p>
<p>This is just how Firefox displays IDNs where the TLD is not on their whitelist (and &#8220;.com&#8221; is not.) For IDNs on the whitelist, this will render properly in Unicode.</p>
<p>I should have made this clear and show just an ASCII case, thanks for the clarification.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: 3247</title>
		<link>http://dready.org/blog/2007/01/22/browser-based-mitigation-of-phishing-attacks/#comment-8862</link>
		<dc:creator>3247</dc:creator>
		<pubDate>Sun, 21 Jan 2007 23:48:34 +0000</pubDate>
		<guid isPermaLink="false">http://dready.org/blog/2007/01/22/browser-based-mitigation-of-phishing-attacks/#comment-8862</guid>
		<description>Your example shows the domain name in ACE format (xn--pypal-4ve.com). This is only a good idea if the real domain is not an IDN.

For users of legitimate serves not using pure-ASCII domains, this will make any comparision impossible.</description>
		<content:encoded><![CDATA[<p>Your example shows the domain name in ACE format (xn--pypal-4ve.com). This is only a good idea if the real domain is not an IDN.</p>
<p>For users of legitimate serves not using pure-ASCII domains, this will make any comparision impossible.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: =marcin</title>
		<link>http://dready.org/blog/2007/01/22/browser-based-mitigation-of-phishing-attacks/#comment-8861</link>
		<dc:creator>=marcin</dc:creator>
		<pubDate>Sun, 21 Jan 2007 18:47:14 +0000</pubDate>
		<guid isPermaLink="false">http://dready.org/blog/2007/01/22/browser-based-mitigation-of-phishing-attacks/#comment-8861</guid>
		<description>I posted my remarks to list, but I'll repeat them here. In my opinion it is not the issue of effectiveness of warning.  While idea of "delay box" is good, the problem noticed here:

"phisher can replace the password input field with javascript / DHTML / flash to bypass the check"

is more vital. My idea is: if phisher wants to bypass the check, we should warn the user. How? By NOT changing browser UI. 

So my idea is: let's change browser UI in a significant, visible way on every page that contains password field. Let's warn users if password field looks suspicious. And let's NOT change UI if it's not a password field. User will notice the difference.</description>
		<content:encoded><![CDATA[<p>I posted my remarks to list, but I&#8217;ll repeat them here. In my opinion it is not the issue of effectiveness of warning.  While idea of &#8220;delay box&#8221; is good, the problem noticed here:</p>
<p>&#8220;phisher can replace the password input field with javascript / DHTML / flash to bypass the check&#8221;</p>
<p>is more vital. My idea is: if phisher wants to bypass the check, we should warn the user. How? By NOT changing browser UI. </p>
<p>So my idea is: let&#8217;s change browser UI in a significant, visible way on every page that contains password field. Let&#8217;s warn users if password field looks suspicious. And let&#8217;s NOT change UI if it&#8217;s not a password field. User will notice the difference.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
