When you sign up for an online service, you’re given a private, randomly generated RSS feed. The URL is a jumble, password protected and seamlessly encrypted. You also have a private space to reply back with responses and your own private RSS feed.

Where I get a little iffy is on the second part of that, maybe I read it wrong but it appears to be suggesting that you publish an RSS feed for the online service to read. I don’t particularly think that would fly, and due to the nature of most communications by an online service anyway, they would generally just provide a link to the setting or location in your account that they want to draw your attention to.

Nonetheless, I think the first part is a great idea. Take Flickr, for example, I would be quite happy simply to have an RSS feed of the information commonly provided in “Flickr Mail” and, for that matter, one that contains all the content of the “Recent Activity” page rather than just the comments.

I think Signal vs. Noise touched on this recently too, with their post Message Overload, saying that the messaging services within online apps should be done away with and replaced with by putting the messages directly into the normal email flow. I would argue, instead, that they should be placed in the feed flow. Throw together an interface to let a user select all the types of things she would like to be notified of and aggregate them into a feed along the lines of what Will is talking about.

I would love to see Sxip include this sort of functionality in the Homesite code, because once they start taking off they will become the new targets for phishing attempts. As an aside, here is another post I wrote regarding a method to counter phishing and one where I explain a bit of how Sxip helps prevent phishing.

Tags: [tag:phishing], [tag:security], [tag:rss]

Kim Cameron has released his Sixth Law of Identity, this one relating to the human component of an identity system, most specifically phishing attacks.

Phishing is generally the practice of tricking a user into entering her authentication credentials into a site that is a duplicate of one that she trusts for the purpose of harvesting their authentication credentials, usually done by mass-emailing tricky URLs to the duplicate site stating that she needs to update some data, and has been a rapidly growing trend in recent times.

Why do you care? Well, if you are a frequent user of the internet (and you would have to be to be reading this, I’m not linked to enough for somebody to ’stumble’ onto my site) phishing has probably been attempted on you, and with any luck you have avoided it. Not everybody is so lucky.

In his post, Kim brings up a very interesting aspect to a digital identity system:

“… we have done a pretty good job of cryptographically securing the channel between web servers and browsers – a channel that might extend for thousands of miles.  But we haven’t done a very good job at all of setting up the two or three foot channel between the browser and the human who uses it.  And this is the channel that is attacked by phishers.”

After reading this Zak and I immediately went to thinking about how to address this problem, first with SXIP, and then in general. The problem, as Kim lays it out, is centered around the user not having enough meaningful information to interact with in conventional systems. We narrowed the focus a bit further, to addressing the question, “how does a user know that the site she is visiting is the one she intended on visiting?”

So, how does a user know that she is visiting the actual site she intended, rather than a duplicate? Taking Kim’s warnings, we immediately ruled out any kind of multi-level authentication as described in my previous post related to this subject or anything that seemed like a fix regarding a current flaw that has been exploited, and instead went towards a conceptual idea that would be easily understood by the user. Here’s what we came up with…

Love at First Sight

You can be sure that a site is the one you were trying to reach if that site can tell you something about yourself before you log in. It doesn’t have to be anything important, in fact it shouldn’t be, just something that only the site would know.

When a user arrives at the site and is asked to authenticate, above the username and password input fields would sit a little piece of text that she had entered when registering, something like “your have a blue house.” The site knows which text to display based on cookie in her browser with something in it like “judy went home,” just a random bit of memorable text keyed to the bit of information she entered at registration, it could even be a phrase she had chosen.

If the site does not receive the user’s verification phrase in the cookie, it would produce a extra text box prompting the user to enter her phrase if she would like to validate that the site is indeed who it says it is. In this way, whenever the user visits a site they would have to authenticate with, such as a Homesite, if the site cannot immediately verify itself to her, she will become suspicious and can choose to enter her phrase. The proper site would give the proper response, the phishing site would not.

This concept can be conveyed in symbolic terms for the user through the imagery of telling a blind date to wear a red carnation or, for us geeks who are far too busy averting evil villains’ world domination plans to go on dates, that seen in Golden-Eye where the man picking up James Bond has to show him the tattoo.

The way that a phishing site will try to subvert this is with cross-site scripting (XSS), but I believe that by using the proper techniques any XSS attack against this system can likely be foiled to the point of harmlessness, although I am not the authority on this and invite those who may be to bring up holes and, hopefully, solutions. Also, if anybody else has seen a system related to this concept, I’d love to hear from you.

Tags: digital identity, [tag:phishing]