<?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: The Untrusted Certificate Dialog</title>
	<atom:link href="http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/feed/" rel="self" type="application/rss+xml" />
	<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/</link>
	<description>Little n desigN</description>
	<pubDate>Fri, 25 Jul 2008 10:24:27 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: 34412-8160</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-358</link>
		<dc:creator>34412-8160</dc:creator>
		<pubDate>Thu, 12 Jul 2007 04:34:33 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-358</guid>
		<description>Bryan- I got a laugh out of your asessment, because this just happened to me and you're totally right- how the heck am I supposed to know what the "fingerprints" are or whether they look "ok"? (but for the record I did "carefully examine" them anyway).  But I agree with the others, that this is a necessary popup, it just needs to become a little more useful, or webmasters need to be a little less lazy (because I encountered it on the gmail login, and NOW for "*mozilla.org".. hehe, what the heck is this??).  IDK, maybe I'm running too old of a version of firefox or something?  don't know if its the browser or the websites...</description>
		<content:encoded><![CDATA[<p>Bryan- I got a laugh out of your asessment, because this just happened to me and you&#8217;re totally right- how the heck am I supposed to know what the &#8220;fingerprints&#8221; are or whether they look &#8220;ok&#8221;? (but for the record I did &#8220;carefully examine&#8221; them anyway).  But I agree with the others, that this is a necessary popup, it just needs to become a little more useful, or webmasters need to be a little less lazy (because I encountered it on the gmail login, and NOW for &#8220;*mozilla.org&#8221;.. hehe, what the heck is this??).  IDK, maybe I&#8217;m running too old of a version of firefox or something?  don&#8217;t know if its the browser or the websites&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-70</link>
		<dc:creator>Richard</dc:creator>
		<pubDate>Thu, 03 May 2007 22:12:21 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-70</guid>
		<description>Fixing the POSTDATA dialog is easy if you are the webmaster. Simple do a silent http redirect for every page that recieves postdata, then the actual postdata event does not show up in the browser history. A nice and convinient solution IMHO. I am not sure whether this "should" be solved in the browser actually.

Cheers
-Richard</description>
		<content:encoded><![CDATA[<p>Fixing the POSTDATA dialog is easy if you are the webmaster. Simple do a silent http redirect for every page that recieves postdata, then the actual postdata event does not show up in the browser history. A nice and convinient solution IMHO. I am not sure whether this &#8220;should&#8221; be solved in the browser actually.</p>
<p>Cheers<br />
-Richard</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Lamb</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-69</link>
		<dc:creator>Scott Lamb</dc:creator>
		<pubDate>Thu, 03 May 2007 21:18:23 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-69</guid>
		<description>Anonymous: unfortunately, you're wrong. Your bank's website is no more secure - and possibly less - for doing this. They should stick to tried and true methods.

Why more no secure? They are proving their identity by sending a shared secret (the picture) to an unauthenticated party. That provides no protection against a man-in-the-middle attack. If I can get you to load my fake webpage, I can also relay your username request to the bank so I can display the correct picture.

Why less secure? Unless they're smart enough to display a random picture on unknown username, this technique provides a simple way to test the existence of an account.</description>
		<content:encoded><![CDATA[<p>Anonymous: unfortunately, you&#8217;re wrong. Your bank&#8217;s website is no more secure - and possibly less - for doing this. They should stick to tried and true methods.</p>
<p>Why more no secure? They are proving their identity by sending a shared secret (the picture) to an unauthenticated party. That provides no protection against a man-in-the-middle attack. If I can get you to load my fake webpage, I can also relay your username request to the bank so I can display the correct picture.</p>
<p>Why less secure? Unless they&#8217;re smart enough to display a random picture on unknown username, this technique provides a simple way to test the existence of an account.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-67</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Thu, 03 May 2007 19:03:03 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-67</guid>
		<description>My bank has a two stage authentication process where after I enter my username, it then shows me a picture I chose specifically when I created the user.

Since it's a picture I chose and see every time I login, if I ever see a different picture I'll immediately realize something is up and be cautious about entering my login credentials.

I think that type of phishing prevention is much more useful than the browser cert warning.</description>
		<content:encoded><![CDATA[<p>My bank has a two stage authentication process where after I enter my username, it then shows me a picture I chose specifically when I created the user.</p>
<p>Since it&#8217;s a picture I chose and see every time I login, if I ever see a different picture I&#8217;ll immediately realize something is up and be cautious about entering my login credentials.</p>
<p>I think that type of phishing prevention is much more useful than the browser cert warning.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steven Garrity</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-65</link>
		<dc:creator>Steven Garrity</dc:creator>
		<pubDate>Thu, 03 May 2007 16:33:23 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-65</guid>
		<description>For comparison, here's a screenshot of the IE7 equivalent:

http://actsofvolition.com/images/screenshots/web/windows-cert-error.png</description>
		<content:encoded><![CDATA[<p>For comparison, here&#8217;s a screenshot of the IE7 equivalent:</p>
<p><a href="http://actsofvolition.com/images/screenshots/web/windows-cert-error.png" rel="nofollow">http://actsofvolition.com/images/screenshots/web/windows-cert-error.png</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Lamb</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-64</link>
		<dc:creator>Scott Lamb</dc:creator>
		<pubDate>Thu, 03 May 2007 16:12:45 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-64</guid>
		<description>James:

That text is not bad, minus the extraneous quotes around "certificate". ("Using this 'laser', I will...")

Bryan:

You've been unsuccessful because it's impossible - the issues are inseparable. The browser does not know the server administrator's intent. It is unable to distinguish between a "configuration problem" of inadvertently sending a valid certificate for another site and a "security problem" of deliberately sending a valid certificate for another site. I'm skeptical even of heuristics like "'example.com' and 'www.example.com' are basically the same".

What you're doing is like trying to come up with a smart lock that can distinguish between the "forgetfulness issue" of someone forgetting the key and the "security issue" of someone not having the key. You can't do it - all the lock sees is a "no key issue", and its policy is to refuse entry. Maybe the "forgetfulness issue" is more common in some situations, but the "security issue" would be common as hell if the lock's policy was to let people in anyway.

You are convincing me that there is more danger here than I'd realized. Aunt Tillie on her own would handle Safari's dialog box fine. But the real danger is that her "computer genius" nephew will tell her to ignore it - it's probably not important because he gets this security warning at his friend Joe's website and no one has ever stolen his credit card there.</description>
		<content:encoded><![CDATA[<p>James:</p>
<p>That text is not bad, minus the extraneous quotes around &#8220;certificate&#8221;. (&#8221;Using this &#8216;laser&#8217;, I will&#8230;&#8221;)</p>
<p>Bryan:</p>
<p>You&#8217;ve been unsuccessful because it&#8217;s impossible - the issues are inseparable. The browser does not know the server administrator&#8217;s intent. It is unable to distinguish between a &#8220;configuration problem&#8221; of inadvertently sending a valid certificate for another site and a &#8220;security problem&#8221; of deliberately sending a valid certificate for another site. I&#8217;m skeptical even of heuristics like &#8220;&#8216;example.com&#8217; and &#8216;www.example.com&#8217; are basically the same&#8221;.</p>
<p>What you&#8217;re doing is like trying to come up with a smart lock that can distinguish between the &#8220;forgetfulness issue&#8221; of someone forgetting the key and the &#8220;security issue&#8221; of someone not having the key. You can&#8217;t do it - all the lock sees is a &#8220;no key issue&#8221;, and its policy is to refuse entry. Maybe the &#8220;forgetfulness issue&#8221; is more common in some situations, but the &#8220;security issue&#8221; would be common as hell if the lock&#8217;s policy was to let people in anyway.</p>
<p>You are convincing me that there is more danger here than I&#8217;d realized. Aunt Tillie on her own would handle Safari&#8217;s dialog box fine. But the real danger is that her &#8220;computer genius&#8221; nephew will tell her to ignore it - it&#8217;s probably not important because he gets this security warning at his friend Joe&#8217;s website and no one has ever stolen his credit card there.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bryan Clark</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-62</link>
		<dc:creator>Bryan Clark</dc:creator>
		<pubDate>Thu, 03 May 2007 14:22:23 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-62</guid>
		<description>@scott:  I'be been trying to separate these two issues, but they keep getting clouded.  Intending to go to your bank and ending up somewhere else is phishing and phishing is a serious problem.  I don't think that this cert dialog is actually helping to curtail the phishing problem, I do think this dialog just becomes noise to people because it also appears when a site is simply misconfigured.  Essentially it is crying wolf to the person and they will eventually tend to just click through it.  And I completely agree that serious sites like banks and amazon won't screw up their certificates, so there's not much reason to block people from using sites with bad certs assuming you have a solution to the phishing problem.  I just went to core.fluendo.com and they have a bad cert, but it doesn't mean they are going to steal my identity.  Like Brian points out, most of the time it's a badly configured server, so to help our users we should try not to cry wolf about that.</description>
		<content:encoded><![CDATA[<p>@scott:  I&#8217;be been trying to separate these two issues, but they keep getting clouded.  Intending to go to your bank and ending up somewhere else is phishing and phishing is a serious problem.  I don&#8217;t think that this cert dialog is actually helping to curtail the phishing problem, I do think this dialog just becomes noise to people because it also appears when a site is simply misconfigured.  Essentially it is crying wolf to the person and they will eventually tend to just click through it.  And I completely agree that serious sites like banks and amazon won&#8217;t screw up their certificates, so there&#8217;s not much reason to block people from using sites with bad certs assuming you have a solution to the phishing problem.  I just went to core.fluendo.com and they have a bad cert, but it doesn&#8217;t mean they are going to steal my identity.  Like Brian points out, most of the time it&#8217;s a badly configured server, so to help our users we should try not to cry wolf about that.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-61</link>
		<dc:creator>James</dc:creator>
		<pubDate>Thu, 03 May 2007 14:17:09 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-61</guid>
		<description>OK -- how about:

This site is supposed to be trusted, but the site's "certificate" is [broken/out of date/not trusted/delete as appropriate].

This may mean you're connecting to someone *pretending* to be www.url.com

If you choose to visit it anyway, treat it with suspicion! Don't enter any personal information, such as credit card numbers!

 [ Visit it anyway ]  [ View certificate ]  [ Keep away! ]</description>
		<content:encoded><![CDATA[<p>OK &#8212; how about:</p>
<p>This site is supposed to be trusted, but the site&#8217;s &#8220;certificate&#8221; is [broken/out of date/not trusted/delete as appropriate].</p>
<p>This may mean you&#8217;re connecting to someone *pretending* to be <a href="http://www.url.com" rel="nofollow">http://www.url.com</a></p>
<p>If you choose to visit it anyway, treat it with suspicion! Don&#8217;t enter any personal information, such as credit card numbers!</p>
<p> [ Visit it anyway ]  [ View certificate ]  [ Keep away! ]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: fraggle</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-59</link>
		<dc:creator>fraggle</dc:creator>
		<pubDate>Thu, 03 May 2007 08:13:00 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-59</guid>
		<description>WALL OF TEXT</description>
		<content:encoded><![CDATA[<p>WALL OF TEXT</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian Nickel</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-58</link>
		<dc:creator>Brian Nickel</dc:creator>
		<pubDate>Thu, 03 May 2007 07:29:04 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-58</guid>
		<description>I have to disagree with Scott. Most of the time, I receive the error is from a badly configured server. Like https://www.foo.com and https://secure.foo.com showing the same site, but only secure.* has a certificate. The user DOES want to go to the site, but something is standing in the way. Something that says: "This site has invalid credentials for 'reason x'. This may be due to a badly set up website or a site pretending to be 'foo.com' for fraudulent purposes. You should not trust this website with personal information." [Go Back] [Continue]

- Brian

PS. [Go Back] or [Previous Page] may me more useful to the user than [Cancel]</description>
		<content:encoded><![CDATA[<p>I have to disagree with Scott. Most of the time, I receive the error is from a badly configured server. Like <a href="https://www.foo.com" rel="nofollow">https://www.foo.com</a> and <a href="https://secure.foo.com" rel="nofollow">https://secure.foo.com</a> showing the same site, but only secure.* has a certificate. The user DOES want to go to the site, but something is standing in the way. Something that says: &#8220;This site has invalid credentials for &#8216;reason x&#8217;. This may be due to a badly set up website or a site pretending to be &#8216;foo.com&#8217; for fraudulent purposes. You should not trust this website with personal information.&#8221; [Go Back] [Continue]</p>
<p>- Brian</p>
<p>PS. [Go Back] or [Previous Page] may me more useful to the user than [Cancel]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe Buck</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-57</link>
		<dc:creator>Joe Buck</dc:creator>
		<pubDate>Thu, 03 May 2007 05:19:51 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-57</guid>
		<description>The solution to the Firefox POSTDATA dialog is not to change the dialog.  The need to present it at all is a symptom of broken Firefox behavior.  I typically see it when I hit the "back" button, and what I want to see is the page I just saw before I clicked whatever I clicked.  I don't want Firefox to re-submit a form.  I want it to remember the last page and re-draw it, quickly.  If I'm stuck on dialup, I don't expect a long delay; I expect the browser to just remember the page.  After all, the damned program is sucking up 100Mb or more of storage and tons of disk cache.

If the broken Firefox behavior is fixed, then there's no need for figuring out how to re-word the dialog.

Similarly, one of the most common areas of breakage with certs is that the certificate covers www.foobar.com and I'm visiting foobar.com, or vice versa.  You say that the issue is that the site is misconfigured.  But the certification authorities charge more for a wildcard certificate, so people on a budget don't pay.  For close matches of this kind, the browser should, once again, shut up.</description>
		<content:encoded><![CDATA[<p>The solution to the Firefox POSTDATA dialog is not to change the dialog.  The need to present it at all is a symptom of broken Firefox behavior.  I typically see it when I hit the &#8220;back&#8221; button, and what I want to see is the page I just saw before I clicked whatever I clicked.  I don&#8217;t want Firefox to re-submit a form.  I want it to remember the last page and re-draw it, quickly.  If I&#8217;m stuck on dialup, I don&#8217;t expect a long delay; I expect the browser to just remember the page.  After all, the damned program is sucking up 100Mb or more of storage and tons of disk cache.</p>
<p>If the broken Firefox behavior is fixed, then there&#8217;s no need for figuring out how to re-word the dialog.</p>
<p>Similarly, one of the most common areas of breakage with certs is that the certificate covers <a href="http://www.foobar.com" rel="nofollow">http://www.foobar.com</a> and I&#8217;m visiting foobar.com, or vice versa.  You say that the issue is that the site is misconfigured.  But the certification authorities charge more for a wildcard certificate, so people on a budget don&#8217;t pay.  For close matches of this kind, the browser should, once again, shut up.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-55</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Thu, 03 May 2007 02:08:07 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-55</guid>
		<description>One way to make the POST-request-again dialog a little better might be something like:
---
"You went beyond this page earlier and then returned back to it using the browser history.  Now you're trying to go beyond it again. Do you want to return to where you were before or start fresh?"

                        [Start Fresh] [Return to where I was] 
---
([Start Fresh] would repeat the POST request and [Return to where I was] would pull the page one page forward in the history from the browser cache.</description>
		<content:encoded><![CDATA[<p>One way to make the POST-request-again dialog a little better might be something like:<br />
&#8212;<br />
&#8220;You went beyond this page earlier and then returned back to it using the browser history.  Now you&#8217;re trying to go beyond it again. Do you want to return to where you were before or start fresh?&#8221;</p>
<p>                        [Start Fresh] [Return to where I was]<br />
&#8212;<br />
([Start Fresh] would repeat the POST request and [Return to where I was] would pull the page one page forward in the history from the browser cache.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Lamb</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-54</link>
		<dc:creator>Scott Lamb</dc:creator>
		<pubDate>Thu, 03 May 2007 01:09:29 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-54</guid>
		<description>Actually, I take that back: it's not much much much more likely someone is trying to steal their money. It WOULD be much much more likely, except that the well-known existence of this dialog box discourages people from trying to forge amazon.com's credentials. If this dialog box did not exist or if it were redesigned by someone who missed its entire point, people frequently would steal money in this manner.</description>
		<content:encoded><![CDATA[<p>Actually, I take that back: it&#8217;s not much much much more likely someone is trying to steal their money. It WOULD be much much more likely, except that the well-known existence of this dialog box discourages people from trying to forge amazon.com&#8217;s credentials. If this dialog box did not exist or if it were redesigned by someone who missed its entire point, people frequently would steal money in this manner.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Lamb</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-53</link>
		<dc:creator>Scott Lamb</dc:creator>
		<pubDate>Thu, 03 May 2007 00:56:25 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-53</guid>
		<description>I think you're missing the point of the dialog. The user did *NOT* intend to view the website the dialog is warning about. The user intended to go to Big Bank's website, and this dialog box is breaking the bad news that isn't it. The browser is unable to satisfy the user's desire to go to Big Bank's website.

The cert validity can in some cases matter when viewing the page. I focused on sending information because that's the most common case, but users can take out-of-band actions based on information obtained from a trusted source. It is important that they know this is not a trusted source.

Everybody does not walk around this warning. The "Aunt Tillie" crowd does not often go to mailing list sites which use SSL for no particular reason. They primarily use SSL for online banking and resellers like amazon.com. If they get a security warning at one of those sites, it is much much much more likely someone is trying to steal their money than that amazon.com screwed up SSL or is using a homegrown CA.</description>
		<content:encoded><![CDATA[<p>I think you&#8217;re missing the point of the dialog. The user did *NOT* intend to view the website the dialog is warning about. The user intended to go to Big Bank&#8217;s website, and this dialog box is breaking the bad news that isn&#8217;t it. The browser is unable to satisfy the user&#8217;s desire to go to Big Bank&#8217;s website.</p>
<p>The cert validity can in some cases matter when viewing the page. I focused on sending information because that&#8217;s the most common case, but users can take out-of-band actions based on information obtained from a trusted source. It is important that they know this is not a trusted source.</p>
<p>Everybody does not walk around this warning. The &#8220;Aunt Tillie&#8221; crowd does not often go to mailing list sites which use SSL for no particular reason. They primarily use SSL for online banking and resellers like amazon.com. If they get a security warning at one of those sites, it is much much much more likely someone is trying to steal their money than that amazon.com screwed up SSL or is using a homegrown CA.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bryan Clark</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-52</link>
		<dc:creator>Bryan Clark</dc:creator>
		<pubDate>Thu, 03 May 2007 00:29:59 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-52</guid>
		<description>@kevin: I agree that when looking at the error message the browser should just be able to tell you what is wrong with it instead of you figuring it out from the cert.  Assuming the phishing problem can be handled I wouldn't suggest keeping the dialog around, I think it can be handled like a site error message.  Of course if you load a page with a form it might be a good time to warn people that things aren't secure. 

@scott: I think you're missing the real error with these dialogs.  The problem is that your user had the intention to view the web site the dialog is warning about.  They want to be there.  Again, putting aside the problems of phishing.  So it doesn't really matter what dialog you put in front of them, nobody reads the text.  These dialogs look like the hobos wearing signs that say "The End is Near", sure they get in your way on the sideway and sound scary if you took the time but everyone just walks around them.  And the SSL cert validity doesn't actually matter until someone sends information the site, while you're just viewing it there's nothing wrong with an expired cert.  When somebody submits information, then you might have an issue.</description>
		<content:encoded><![CDATA[<p>@kevin: I agree that when looking at the error message the browser should just be able to tell you what is wrong with it instead of you figuring it out from the cert.  Assuming the phishing problem can be handled I wouldn&#8217;t suggest keeping the dialog around, I think it can be handled like a site error message.  Of course if you load a page with a form it might be a good time to warn people that things aren&#8217;t secure. </p>
<p>@scott: I think you&#8217;re missing the real error with these dialogs.  The problem is that your user had the intention to view the web site the dialog is warning about.  They want to be there.  Again, putting aside the problems of phishing.  So it doesn&#8217;t really matter what dialog you put in front of them, nobody reads the text.  These dialogs look like the hobos wearing signs that say &#8220;The End is Near&#8221;, sure they get in your way on the sideway and sound scary if you took the time but everyone just walks around them.  And the SSL cert validity doesn&#8217;t actually matter until someone sends information the site, while you&#8217;re just viewing it there&#8217;s nothing wrong with an expired cert.  When somebody submits information, then you might have an issue.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Lamb</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-51</link>
		<dc:creator>Scott Lamb</dc:creator>
		<pubDate>Wed, 02 May 2007 23:50:31 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-51</guid>
		<description>Here is Safari's text for comparison. It gets right to the point, which is that you shouldn't supply confidential information.

Safari can't verify the identity of the website "www.slamb.org".

The certificate for the website was signed by an unknown certifying authority. You might be connecting to a website that is pretending to be "www.slamb.org" which could put your confidential information at risk. Would you like to connect to the website anyway?

[?] [Show Certificate] ... (gap here) ... [Cancel] [Continue]</description>
		<content:encoded><![CDATA[<p>Here is Safari&#8217;s text for comparison. It gets right to the point, which is that you shouldn&#8217;t supply confidential information.</p>
<p>Safari can&#8217;t verify the identity of the website &#8220;www.slamb.org&#8221;.</p>
<p>The certificate for the website was signed by an unknown certifying authority. You might be connecting to a website that is pretending to be &#8220;www.slamb.org&#8221; which could put your confidential information at risk. Would you like to connect to the website anyway?</p>
<p>[?] [Show Certificate] &#8230; (gap here) &#8230; [Cancel] [Continue]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Lamb</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-49</link>
		<dc:creator>Scott Lamb</dc:creator>
		<pubDate>Wed, 02 May 2007 22:50:10 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-49</guid>
		<description>I just realized your advogato post was syndicated from here. I don't know if you saw my two posts there, but your comments about "C" are horribly wrong!

http://www.advogato.org/person/slamb/diary.html?start=61
http://www.advogato.org/person/slamb/diary.html?start=60</description>
		<content:encoded><![CDATA[<p>I just realized your advogato post was syndicated from here. I don&#8217;t know if you saw my two posts there, but your comments about &#8220;C&#8221; are horribly wrong!</p>
<p><a href="http://www.advogato.org/person/slamb/diary.html?start=61" rel="nofollow">http://www.advogato.org/person/slamb/diary.html?start=61</a><br />
<a href="http://www.advogato.org/person/slamb/diary.html?start=60" rel="nofollow">http://www.advogato.org/person/slamb/diary.html?start=60</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bryan Clark</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-47</link>
		<dc:creator>Bryan Clark</dc:creator>
		<pubDate>Wed, 02 May 2007 20:04:21 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-47</guid>
		<description>@martijn: Well it's difficult to remove.  Because until you tackle the phishing problem that guilt/legal issue is going to stick around.  But if we assumed we had a solution for that I wouldn't use a dialog at all.  The invalid cert would be treated like a javascript error, similar notification principle as they are both only interesting to people who understand the tech.</description>
		<content:encoded><![CDATA[<p>@martijn: Well it&#8217;s difficult to remove.  Because until you tackle the phishing problem that guilt/legal issue is going to stick around.  But if we assumed we had a solution for that I wouldn&#8217;t use a dialog at all.  The invalid cert would be treated like a javascript error, similar notification principle as they are both only interesting to people who understand the tech.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: GUEST</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-46</link>
		<dc:creator>GUEST</dc:creator>
		<pubDate>Wed, 02 May 2007 18:40:26 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-46</guid>
		<description>IMHO Opera has rather useful dialogs.</description>
		<content:encoded><![CDATA[<p>IMHO Opera has rather useful dialogs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian Nickel</title>
		<link>http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-45</link>
		<dc:creator>Brian Nickel</dc:creator>
		<pubDate>Wed, 02 May 2007 18:30:44 +0000</pubDate>
		<guid isPermaLink="false">http://clarkbw.net/blog/2007/05/02/the-untrusted-certificate-dialog/#comment-45</guid>
		<description>A decent POSTDATA dialog would require a smarter browser. Upon submitting the page, the browser would store some interesting information, like a field was named "pass" or "comments", a 15MB file was sent, a "image/png" was sent, etc. The address could be useful too, like "login.php"

The dialog could then say something like, "You originally sent data (via POSTDATA) to view this page, to view it again would require you to resend the data. ..."

* "It appears you submitted your login information. It would probably be harmless to continue."
* "It appears you submitted a 15MB media file called 'animals-wearing-hats-with-a-wide-angle-lense.ogg'. You probably do not want to post this again."
* "It appears you posted a comment on a blog or forum. You probably do not want to post it again."

If the page is being navigated to, an additional button, "Return to previous page" could be helpful.</description>
		<content:encoded><![CDATA[<p>A decent POSTDATA dialog would require a smarter browser. Upon submitting the page, the browser would store some interesting information, like a field was named &#8220;pass&#8221; or &#8220;comments&#8221;, a 15MB file was sent, a &#8220;image/png&#8221; was sent, etc. The address could be useful too, like &#8220;login.php&#8221;</p>
<p>The dialog could then say something like, &#8220;You originally sent data (via POSTDATA) to view this page, to view it again would require you to resend the data. &#8230;&#8221;</p>
<p>* &#8220;It appears you submitted your login information. It would probably be harmless to continue.&#8221;<br />
* &#8220;It appears you submitted a 15MB media file called &#8216;animals-wearing-hats-with-a-wide-angle-lense.ogg&#8217;. You probably do not want to post this again.&#8221;<br />
* &#8220;It appears you posted a comment on a blog or forum. You probably do not want to post it again.&#8221;</p>
<p>If the page is being navigated to, an additional button, &#8220;Return to previous page&#8221; could be helpful.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 1.844 seconds -->
