I've been thinking on and off about the solution to the problem that has existed up 'til now: Any "verificaton screen" of any "real authority" (SSL certificate issuers, my bank, Paypal, ANYONE) can simply be precisely reproduced by a criminal and fed to me while I'm led down a path that separates me from my money.

No matter what new layer of additional trust authorities you create - a criminal can copy the bits and make a series of screens and programs that mimic exactly the sequence including the new additional "trustable" markings. I'm referring to a few of the efforts presently in use such as toolbars that tell you the site you are on is real, or the new  golden background for the address bar in Firefox when I'm on an SSL site with a good certificate. And of course the old "trust seals" and behind them, the trust seal verification screens.

The solution came to me last year as I was working on implementation of the VARA (Verified And Recipient Authorized) email concept. What is the one thing a fraud cannot copy?

Element 1. Something personal to the individual user.
Examples: a personal photo or a personal sound recording of their pet, child, loved one or self. Selected by the user, not by the software maker or application server, not by the third party trust authority. The name MUST be unique. The location on the hard drive MUST be unique. The method the application has for storing and pointing to the location and name MUST be secure.

Element 2. Cue expectation training.
As in Pavlov's dog salivating at the sound of a bell, I can easily be trained to expect the personal photo and/or recording to accompany the viewing of a trustable email, document, or website. If that is missing - I would feel unease, something is wrong.

Element 3. Reliable triggering of the cue
First we have insertion of the "You can trust this" token by the trusted source. In one typical scenario used in email headers, we don't pass the fake tokens through this point which are put in by frauds because all tokens are removed before we do the trust test.

Next we have recognition and discernment of the "You can trust this" token by the application, such as a web browser or an email client.

And finally, the application displays the personal photo or plays the personal sound to the user along with the trustable content.

Why would this work? Didn't I just say that a criminal can duplicate anything a trust authority or mechanism can do? No. Actually I think that security and trust mechanisms CAN BE reliable. The problem is just the layer of the screen you are looking at and the pixels on it, which can be copied by anyone anywhere.

(If you have a Windows PC, press Alt-PrintScreen. You'll think nothing happened. Now open a new word processor or photo editing screen and pull down menu Edit, click Paste. See? It's an exact pixel for pixel copy of your screen. But you knew that.)

So what I'm saying is - the trust mechanisms are and can be reliable - we just need to add a layer that the USER himself selects which is personal to him - and bond the visual / audible cue to him that THIS - not some trust seal, logo, or corporate color scheme - means trustability.

Of course it may need be a unique photo or sound for each different trust need. My bank, Paypal, a VARA address. Or unique for my Firefox browser vs my email client. Webmail systems such as one of my favorite bigco webmails - Gmail by Google, have nearly complete control over their user's interface and may be able to implement this in webmail.

Originally I thought of a color selected by the user - however I don't think that is as good as something more personal. Human nature will direct the middle of the bell curve group to pick primary colors or one of few enough variations that frauds could try them all or hit a useful percentage with any one color try. Also I am not sure that most humans would notice a subtle mismatch in color, as well as of course recognition / cue issues with variations in monitors.

I'll detail and explore an example of putting this theory to work in tandem with VARA for email in a separate article.