Stephen’s Statements A little bit of everything from Stephen Duncan Jr, a Software Developer in Portland, Oregon

So, we know what the problem is, I think. But that doesn't quite get us to what criteria we'll use to judge possible solutions.

Obviously, the first criteria is that it needs to make it possible to identify spoofing in the situations listed in the problem description. But, does it just need to possible by a computer literate user who's paying attention? Or does it need to be so obvious that anybody will notice? Does the solution need to have limited impact on the UI of current non-spoofed pages? When it comes to spoofing to get around the browser's existing anti-page-spoofing, are we only limiting our concern to "secure sites" (https://)?

Here's what I'm going to use:

1. It needs to address the listed problems.
2. It needs to make it possible for a fairly computer literate user to identify.
3. It should address non-secure sites as well.
4. A compromise between making things more obvious for all users and keeping the UI clean needs to be made.

Regarding #3: This really goes above and beyond the current problem, as it's an attempt to add web-site spoofing protection to non-secure sites. But the use of certificates to authenticate a site's identity is a joke on the modern internet. Many sites I do trust don't have the money for a proper certificate for every domain name that points to that content. A real site that had the web server hacked is just as untrustworthy as someone putting up a fake version. So, I'd rather we simply assume that the domain name is valid, and prevent spoofing from there. Certainly, secure sites should continue to receive the extra UI they do now, but all sites should be included in anti-phishing schemes.