Curiosity is bliss

More TypeKey thoughts

Ben Hyde is raising two concerns with TypeKey in his series on authentication: the privacy implications of attributing users global and unique IDs and the lack of federation (the system is centralized).

Privacy
Personally, I'm ready to accept this risk in exchange for a good single sign-on, at least when it comes to community sites. But I understand that some privacy "freaks" may not be as comfortable.

The fix that Ben suggests for the privacy concern is to use IDs that are local to each site. This way it is not as easy to track a user from sites to sites.

The problem with this approach is that it seems to restrict the possibilities to reach TypeKey's goal, which is reduce comment spam. A lot of power is lost if each site has to build his own list of known spammers and can't cross-reference it with that of other sites.

Cross-referencing and privacy
I had this gut feeling that the two objectives (ensuring users' privacy and fighting spam) were difficult to reconcile, because I assumed that a distributed reputation system required a unique ID across all participating sites.
Then, I read some of Norman Hardy's articles about identity, where he underlines that you don't really need to know who somebody is as much as you need evidence to his character.
Since TypeKey has to be able to map these local IDs to a global one, why not have TypeKey do the cross-referencing?
Here is a proposed solution.

Let's assume that each TypeKey-enabled site maintains a list of local IDs for the users that it trusts and one for the users that it mistrusts (because they commented junk/spam in the past).
If TypeKey can get this data from each site, then for each user, it could build a list of sites that trust him or mistrust him.
Whenever a user logs onto a site, these two lists would be passed along so that the site can make an informed decision, based on other sites that it trusts.

There are two technical problems that need to be solved in this approach: how does TypeKey securely get the lists of local IDs from each site and how does it communicate the list of sites that vouched for or against a user?

Passing lists of trusted and banned users to TypeKey
I could think of at least three ways that the two lists built by each site (trusted users and mistrusted users) could be gathered by TypeKey:

1. publish a list of local IDs at a known location on the site and have TypeKey fetch it regularly,
2. have the owner of a site log into TypeKey and provide TypeKey with these lists,
3. use PKI to allow sites to authenticate with the TypeKey servers and communicate these lists to them.

Build the list of sites that trust or banned a given user
When a user logs in, we'd need TypeKey to securely provide a list of sites that vouched for him and a list of those that banned him. An actual list of the site tokens is too big. The solution is to use a bloom filter instead of the list, as it is much more efficient storage-wise.
LOAF is a very interesting system that uses Bloom filters to share your contact list without revealing any of your contacts' email address.

Here is the original paper "Space/time trade-offs in hash coding with allowable errors" from Burton Bloom.
You can also read O'Reilly Networks' "Using Bloom filters" article.

Another explanation (from Steven M. Bellovin):

The size of the filters has to be adjusted so that the rate of false positives is acceptable.

One thing about Bloom filters is that you can add new entries, but you can't remove old ones. But it is possible that you change your mind about somebody you trusted, but that you now want to ban.

You could deal with this in two ways: TypeKey could re-generate the filters frequently based on the lists that they store or they could choose to only store the filters but have them expire every couple of weeks.
The second solution seems far better in terms of storage, for TypeKey, but then filters need to be cycled in some way. For example, a filter could last for two weeks and then a new one is rebuild from scratch. This means TypeKey needs to store twice the number of filters (the current and the next generation).

The time that it takes for a change to propagate (when you change your mind about somebody) can also be improved by using more "exception" filters, used to "remove" somebody from a previous filter...

Notice that Bloom filters could be used with the current implementation of TypeKey (using global IDs) for a site to efficiently share the list of users that it vouches for and that of users that it banned. You would fetch these lists from the blogs you trust and incorporate them into your moderation system.
Another option is to use the users' public keys in the filter instead of TypeKey IDs, to enable a distributed (TypeKey-less) reputation system.


Federation
Federation is the tech term for replacing a single authentication provider with a number of them.
One of the best examples of real-life federation is the ATM card system. More than one bank issue these cards, but they trust each other so that you can use your card from any ATM.
Another example, email, can be considered a not-too-secure federated authentication system (your ID is your email address). But central authentication systems like Passport or TypeKey are exactly the opposite, as they only allow one provider, and most site that use them are exclusive, as they only support one or the other, not both.

Kerberos is an authentication system that supports some federation, in the form of Kerberos realms. With Kerberos, if Yahoo and AOL trust each other, you could get authenticated by AOL and then go shop at Yahoo without needing a Yahoo ID.
The Liberty protocol (from Liberty Alliance) tries to achieve that as well. I'm not very familiar with the details, but O'Reilly Network has an overview.

Who do you trust?
Ben seems to think that a federated system is definitely better than a centralized one. I think there are obvious advantages like allowing interop, competition and enhanced network effect, but also the difficulties with federation go beyond the simple challenge of sending the user to the appropriate authentication provider when he needs to sign in.

The real problem is with the service that is going to consume the identity assertion. Which identities/providers/realms should it trust?
You wouldn't let any "bank" join the VISA network, would you?
Or if you are Paypal, would you choose to support users accounts provided by Passport, TypeKey or both? What is the risk you are taking by integrating TypeKey into your business? If TypeKey is found to have a security hole, how confident are you that it'll be handled to your satisfaction?

But we can assume that building a business is not the goal here, only to offer single sign-on to community sites and help fight comment spam...

Still, spammers could start creating hundreds of authentication services, or hacking into some competitors (that aren't as well administered/secured as TypeKey might be) to create spam accounts or hijack legit accounts. As a consumer of identity assertions you still care about the issuer of these.

Each user as his own identity provider
That's why authentication systems that aren't based on a provider are easier to manage. You don't care that a third-party authenticates me, you only care that I am the owner of a public key (or a public url) and that I can prove it. That described some of these in this post about authentication by url (which also mentions authentication by PGP public key).

With this kind of approach, each user is responsible for his own identity and sites don't assume any level of trust with a user just because a third-party said so... This is effectively separating the problem of authentication and the problem of trust/reputation.
Other forms of assertions could be created to handle the reputation part, going back to Norman Hardy's idea that "Certificates should relate to Character, not identity."


Threats analysis
As a follow-up on my deconstruction of the TypeKey protocol Tomas suggested to do a threat modeling.
I'm still waiting on a more official documentation of the protocol to do that, but here are the risks I could think of so far (in random order):

• TypeKey DB gets hacked (steal passwords),
• spoof the TypeKey login page,
• Script injection flaw in the domain that holds the cookies,
• client level theft of cookies/creds,
• client level re-use of cookies (you forgot to logout or logout doesn't work),
• theft of the crypto keys used to sign the identity assertions,
• denial of service on the authentication service,
• scripted registrations,
• user gets silently authenticated without his knowing.

Related:
Self-certifying identities.

Updated (2008/04/18):
Some more pointers:
A great introduction to Bloom filters, with an approachable analysis of the size and false positive trade-offs, as well as overviews of many practical applications. (via)
A quick overview of many variants of Bloom filters (video).

TypeKey is live (beta)

I ran into a site that is running MovableType 3.0 (beta1) with TypeKey support.

There is no public protocol doc yet (afaik), but here's a quick analysis attempt.

Let's start with some shameless plugs to my previous posts on web authentication, for some background on existing solutions. "Microsoft Passport 101" (a detailled explanation of Microsoft's protocol) and "Comment authentication" (an investigation on alternative protocols).
Now, let's dive into the details of TypeKey (which seems similar in design to Passport, but with less features/options and is more open).

Authentication request:
Whenever you register an account, you can also enlist your blog. In that case a blog token is provided to you, for the blog urls you declare. It looks like "LjRd2DpifL51sB0iFeYT".
This token is passed in the authentication request (as the t parameter) along with return url (_return). The return url is checked against the blog urls you enlisted for.

So a login url follows this format (notice that the url is static for a given blog): https://www.typekey.com/t/typekey/login?t=<blog token>&_return=<return url>

Successful authentication:
The return request contains the time (epoch format) of the authentication (ts parameter), the TypeKey login name (name), some kind of hash of the email (email), the display name (nick) and a secure signature (sig).

So, after you authenticate with TypeKey, you are returned to a url like: <return url>&ts=<timestamp>&email=<hashed email>&name=<name>&nick=<display name>&sig=<crypto signature>

Real parameters would look like:
<Return Url>&ts=1082595857
&email=a4426c6a28b21941e3de8b14541e10e5aabb24e8
&name=dumky
&nick=Julien%20Couvreur%20%28Dumky%29
&sig=vuXeBVRJG2cR4xl81+HoeJMbKYs=:DBASoTXIQtlxs07jRblTLRk=

A SHA-1 hash is used for the email (like FOAF). I confirmed it by computing the SHA-1 hash for mailto:dumky at ifrance.com, and then also found out the url for my TypeKey FOAF file.
I'm not sure how the query string is signed yet, probably a PGP type signature. The blog token is probably involved, so that signatures can't be re-used from sites to sites.

Variation:
If need_email=1 is part of the auth request, a consent checkbox is shown in the login prompt. In that case, a cleartext version of the email is returned instead of just a hash.
Idly.org uses this option.

Cookies:
Also, the TypeKey site will set a cookie that looks like:
Tp_commenter0 = b75783e8ef6b9433e014aed547fa028d

Since the TypeKey authentication occurs over SSL, I'm not sure why they didn't use a secure cookie.
Also, this cookie is set in the same domain all the UI is displayed (for account management), which might be a risk in terms of script injection.
For example, the Profile currently is vulnerable to a script injection (I notified the SixApart team as I did with similar problems with MovableType <2.64 and used my profile page as a demo), but lukily it resides in a separate domain profile.typekey.com instead of www.typekey.com.

Back onto the blog site two cookies are set, that look like:
Tp_commenter = PyL52XkB98cxSo2sE%3D%3AUvzQdLVyw38%20qJBIjKz4lj1HkDY%3D
Commenter_name = Julien%20Couvreur%20%28Dumky%29

Logout:
If you hit the mt-comments.cgi on the blog site, with logout=1, you'll get logged out of the blog and bounced on the TypeKey logout url (https://www.typekey.com/t/typekey/logout?&_return=<return url>).
I'm not sure how the sign-out works when you logged into multiple sites, it might just not be supported.

Links:
TypeKey's FAQ.

Update: I implemented a TypeKey authentication provider for ASP.Net, based on the newly published official documentation of the TypeKey protocol.

Microsoft Passport 101

...a simple explanation of the Passport web authentication protocol...

Introduction:
Passport is a single sign-on system developed by Microsoft. It allows websites who participate to unload some of the account management burden onto a shared and specialized authentication service hosted by Microsoft.
It is probably the largest dedicated authentication service on the web, as it is used by millions of Hotmail and MSN Messenger users.

It maintains a centralized list of accounts (usernames and passwords). When a Passport-enabled website needs to authenticate a user, it delegates this task to Passport, which in return provides an assertion about the identity of the user that is signed in.
The website only needs to understand these assertions or authentication proofs, but doesn't need to handle the authentication itself.
For the user, only one password is needed for a group of sites, which simplifies managing his account and improves his authentication experience.

We'll go into the details of how this is achieved.

Assumptions:
Some prior knowledge is required to understand this description of the protocol.

• HTTP redirect: a server can reply to a browser request that it should make another request to different location.
• HTTP cookies: they are domain specific, can either expire at a given time or last for the duration of the browsing session, and may be restricted to https connections.
• Cryptography: a message can be exchanged by two parties securely (can't be modified, tampered, peeked into,..) if they both know what algorithm to use and if they share a secret (symmetric) key, that is required for the encryption and the decryption.

Ticket and cookies:
Passport authentication is centered around an account identifier, the Passport Unique ID (PUID). This number is guaranteed to be unique amongst accounts and remain the same throughout the life of a given account.

Whenever a user logs into his account, Passport needs to provide a proof back to the site that requested the authentication. This proof is called a ticket. It most importantly contains the PUID and the timestamp of the last sign-in.
In order for this proof to have any value, some cryptography is used (to ensure only Passport can issue such tickets). When a site (say Site1) becomes part of the Passport network, it gets a crypto key that only it and Passport know. So a ticket for Site1 can be encrypted with that key, in order to ensure nobody else could have generated it.
Using a signature instead of encryption would be possible to proove a ticket (or other) was generated by Passport, but if any information considered private is included, then encryption is needed.

Whenever a site receives a ticket, it can decrypt it with its key, check that the authentication occurred within a certain time and then read the PUID.
But a new ticket shouldn't be issued for each page that the site wants to display. So it can be cached using a cookie on the user's browser. This way, only when the site needed a fresher ticket, does it request one from Passport.

Cookies are domain specific, so a user can have tickets saved as cookies for Site1 and Site2 at the same time. But we'll see that also brings a constraint, because Passport can't issue tickets directly as cookies in Site1 domain.
Passport also keeps cookies in its own domain, to allow a user to authenticate silently into Site2 if he logged into Site1 already (single sign-on).

For example, here are three of the cookies that get set in the Passport domain when a user logs in:

• Ticket (MSPAuth): Encrypted with .NET Passport key. Contains the .NET Passport timestamps (last refresh and last manual sign-in), saved-password flag, key version verification, and any flags set by network servers.
• Ticket-Granting (MSPSec): Sent using HTTPS protocol for all browsers that allow HTTPS cookie writes. Contains the SSL-encoded .NET Passport Unique ID (PUID) and password, used for silent sign-in.
• Visited Sites (MSPVis): Used by the Login server to compile the list of sites that must be signed out from when the user clicks any sign-out link. Each new .NET Passport participating site visited has its Site ID written to this cookie. No encryption.

Flows and options:
We'll start by looking at the flows for three core scenarios, starting with a simplified model. But we'll progressively enrich the description by mentioning more information that is stored in the cookies, as well as additional cookies and querystring parameters.

First login:
Here is the flow for the initial authentication to Site1:

Here is how you can read this diagram:

The user navigates to Site1, but now needs to get authenticated.
He is sent or redirected to the authentication servers. Because the user wasn't logged in, no cookies are present in the Passport domain. So the user is presented with a login prompt.

The form is submitted after the user types his username and password. These are checked against the account information that Passport stores. If they are successfully verified, two tickets are generated, containing the PUID for this account and the time of the authentication.
One is saved as a cookie (MSPAuth) in the Passport domain and is encrypted with Passport's key.
The other is encrypted with Site1's key. It has to be initially transferred to Site1 via the querystring, because Passport servers don't have access to the Site1 domain. Site1 servers can then save it as a cookie (also MSPAuth) in the Site1 domain so that the user stays authenticated in subsequent requests. The server code can choose whether to trust this ticket based on the freshness of the timestamp.

Single sign-on:
Now that the user is logged into Site1, Passport's single sign-on feature allows him to get authenticated with Site2 without having to re-type his password.

When the user navigates to Site2, no ticket is stored in the Site2 domain, so he is not logged in.
The site can require the user to be authenticated, in which case it will redirect him to Passport. Or if logging in is optional, it will just display a sign-in image with a link and letting the user click on it.
When he is sent to Passport to get authenticated, the cookies in the Passport domain are used to generate a ticket for Site2. A redirect transfers it to Site2 via the querystring.

Passport Manager:
The Passport Manager COM object makes it easier for participating sites to implement their side of the Passport authentication. It helps manage crypto keys, read encrypted tickets, store them as cookies, generate login requests and display the sign-in image.
Its SDK documents additional parameters, like the return url or the time window during which a user is asked to have last authenticated.

Return URL:
Whenever an authentication is requested from Passport, the initiating site can choose where the user should be sent back, using the Return URL parameter (RU). When the site registers into the Passport network, it specifies his Root URL, against which any Return URLs will be validated to control were tickets are sent.
If no Return URL is specified, a Default Return URL configured for that site will be used instead.

Time window:
When Site2 sends the user to get authenticated, the sign-in request contains a TimeWindow querystring attribute.
If the cookies in the Passport domain state that the user hasn't authenticated within this time window, the user will be shown a login prompt instead of getting silently logged in.

Force login:
A ticket doesn't just contain the time that the user last was authenticated by typing his password. It also contains the time it was last refreshed.
Whenever a ticket for Site2 is generated using the Passport ticket, this timestamp gets updated.

As part of the authentication request, Site2 can request that the time window constraint be applied to either timestamp (last refresh and last manual sign-in), using the ForceLogin parameter.

Secure sign-in:
For additional security, a site can request that the authentication and tickets should occur over a secure channel, to limit the packet-sniffing risk.
In that case, the Return URL is required to be an SSL URL.

Also, a secure cookie (MSPSec) is set in both the Passport and the site domain. The browser makes sure this cookie is never exchanged over a non-secure link. Passport Manager can then check the presence and content of this cookie to confirm that the ticket wasn't stolen by sniffing the network.

Automatic sign-in:
We've seen that a site ticket can be re-generated as long as you have a Passport ticket within the time window that the site is requesting. There is another ticket in this chain of trust, the ticket-granting ticket (MSPSec).

It is stored as a secure cookie in the Passport domain and contains the information needed to silently log the user in over a long period of time.
This cookie is set permanently, when the user opts to automatically get logged-in on a specific machine, until the user signs out.

Visited sites and sign-out:
As the user logs into multiple sites, Passport keeps track of the list of visited sites in a cookie, MSPVis.
Each site participating in the network needs to declare a url for signing users out.

Whenever a user needs to be logged out of Passport, a page is built, referencing the logout url for each site that was visited by the user. This allows Passport to clear the cookies in all those domains.
If all logout urls loaded properly, the logout page refreshes itself to the Return URL.

SDK:
All of the information provided above can be found in publicly available documents (mostly the Passport SDK) or easily inferred from a network trace of an authentication exchange.
.NET Passport 2.5 Software Development Kit: Software and Documentation. The SDK documentation explains Passport in greater details (be sure to check out the VBScript part, which has the richest description, for some reason).
My description of the current Passport web protocol is provided with no warranties (about its accuracy or other) and definitely isn't meant to replace the SDK ;-)

Links:
The great Kerberos introduction text: "Designing an Authentication System: a Dialogue in Four Scenes".

Andre Durand (PingID) points to a survey on identity being hot amongst the 15 top-rated technologies.

My previous posts on introducing HTTP and thinking about authentication by URL.

The upcoming Typekey service from the MovableType team. (I'm curious to find out what their protocol looks like and will post more details when they become available)
Flickr authentication service.
SharedID authentication service.

Nifty javascript + DOM tricks

A couple of quick links:

• A List Apart's DOM manipulation to break a page into sections: instead of having one big page, javascript is used to transform the DOM into a tabbed view of the chapters.
• Link mouseover color fader effect. Cute ;-)
• Mouseover DOM inspector bookmarklet.
• Topographic page layout bookmarklet: helps visualize the nested blocks in a page. (via redemption in a blog)
• A blog with a draggable divs.

Update:
Javascript event sheets.

Firefox plugins

It's amazing how many plugins extensions are available for Firefox.
But I'm not sure it's such a great thing for less technical users. It seems some behaviors (especially with the tabs) should be improved by default, rather than requiring a setting change or a plugin.
Anyways, here are the ones I use and find most useful:

• FlashBlock replaces Flash content by a placeholder that you can unblock to see the content.
• Focus Last Selected Tab brings focus to the last selected tab when closing the active tab.
• SessionSaver remembers loaded tabs and their history items when Firefox is closed, then restores them when next started.
• Tabbrowser preferences. This extension adds GUI options to change some of the hidden tab browser preferences available in Firefox. It also enables "single window mode" by opening links in a new tab instead of a new window.
• Live HTTP headers. Sniffs the headers of the HTTP requests and response, as they are made.
• PageRank Status. Displays the Google PageRank for the current page, in the status bar.
• AdBlock. It allows you to configure patterns for resources you never want to download as part of a page. For example, "ad.doubleclick.net" or "pagead*.googlesyndication.com" ;-)
• Download Statusbar shows the status on download inside the status bar instead of the usual download manager window.

There are also a bunch of settings that can be tuned via "about:config". And don't forget the DOM Inspector that comes with Firefox, that allows to inspect pages, javascript and figure out CSS rules.

IE is also getting some similar add-ons (that I haven't tried), like a DOM explorer, an inplace CSS editor or request viewers (iehttpheaders or HttpWatch). You can even get mouse gestures support.

Update: I don't like having the download manager or the live HTTP headers using separate windows. Instead I open them in tabs using their chrome urls: chrome://mozapps/content/downloads/downloads.xul and chrome://livehttpheaders/content/LiveHTTPHeaders.xul
Bookmark them for more convenience.
You can find these XUL urls by using the DOM inspector and using the "inspect a window" feature.

Update: Added AdBlock to the list of most useful extensions. Also, with Firefox 0.9 and up extensions are managed much better and there is a new site to get them, Mozilla Update - Extensions. Not all extensions were migrated and the site doesn't support searching though.
The urls in the above list still work, but I'll update them as time goes.

Update (2005/06/08): Greasemonkey has become one of the most fundamental Firefox extensions for me. Highly recommended.

Update (2005/12/28): Here's one more extension I'd recommend for Windows users: IETab. It allows you to open pages in IE as regular tabs in Firefox. You can even configure some pages to always use IE as the rendering engine instead of Gecko, for sites such as Windows Update.

Object vs. Feed: vs. Mime-type

Follow up on RFC: RSS one-click subscription

As I'm progressing on the prototype I have received some interesting feedback and thought a lot about how this solution compares to the two previous ones (feed: and mime-types).
Thanks to Dare Obasanjo, Joshua Allen and Greg Reinacker amongst others for their comments.

Cross-platform and cross-browser?
The main criticism I have received so far (from Dare and Greg) is that this is platform specific. I believe it is not, although the html I posted so far is.
Flash works on lots of platforms and lots of browsers.
The FeedSubscriber button should be the same, instead that the media isn't some flash content, but instead a feed information blob (currently just a url).

Feed: scheme
The main problem I see with the "feed:" URI scheme is that it isn't friendly to new users.
Other than that, I rather like this solution (maybe it should be made a little bit more extensible, but that is a separate discussion).

As an RSS-unaware user, how the heck am I supposed to do with this weird orange button that links to feed://blog.monstuff.com/index.xml or feed:https://blog.monstuff.com/index.xml ?
This is what the FeedSubscriber control and XSL transformation of the feed tries to address.

Also, the other URI schemes (http:, https:, gopher:, mailto:, irc:, nttp:, ftp:) all correspond to a different transport mechanism. Whereas feed: doesn't care about the transport (most feeds us HTTP today, but there is no reason why this couldn't change).
On the other hand, the feed: approach is much simpler to deploy on the publishing side, compared to mime-type based solutions (which needs an extra file to be published containing the feed description or advertisement, and served with the correct mime-type).

FeedSubscriber object
Cross-browser support
As mentioned above it should be completely possible to make the FeedSubscriber be cross-platform and cross-browser.
But the html needs to be a bit more complex than what I originally proposed, to support this. A List Apart describes how to combine the "embed" and "object" tags for flash controls.
Also, supporting the embed tag involves declaring a new mime-type, which in this case would be a "feed information" media type.

Cross-aggregator support
Lots of aggregators use a web request to subscribe to new feeds, like http://127.0.0.1:8082/subscribe?url=...
The component I'm prototyping will read this url from a configuration setting, so that it can be re-used for most aggregators. Only aggregators that have a very specific subscription method would need to re-implement the FeedSubscriber object.

Right click
I recently saw some Firefox plugin to add "subscribe to this feed" to the context menu for the feed button. But that isn't optimal: the most common/useful action should be on the left click instead and secondary actions should be in the context menu.
The FeedSubscriber allows this: a right click on it will open a context menu that allows newbies to get more information ("learn more") and power-users to get to the actual feed ("view feed").
Actions like "copy feed location", "copy feed subscriber", "technorati" or "subscribe in another aggregator" could also be useful.

Is object overkill?
Honestly, the FeedSubscriber object seems a little overkill, because it adds lines of html to every feed button and needs to be installed separately (until the aggregators integrate it).

Also it may be a bit confusing when you installed the FeedSubscriber and go to a site that doesn't support it: the feed button will be a regular button (no one-click subscription).
I'm planning on addressing this by having the FeedSubscriber look similar to the feed button it replaces, but slightly different (using visual cues when hovering, like a tooltip or an image effect).

Then why?!
The FeedSubscriber object solution is the only one that gives us a way to handle the fall back case.
This is really important because user experience is a major roadblock in wide adoption of feeds outside of the blogger community.
Of course, if the deployed browsers had even minimal support for the feed: URI scheme (by showing you a help popup/page about feeds if you don't have an aggregator installed), the FeedSubscriber object approach would be un-necessary.

It should be combined with a smart RSS beautification, to try and improve the "newbie scenario".
"smart" means the solution that I implemented so far is confusing experienced users.
I'll include a new approach in my prototype: the beautified RSS shouldn't display the feed, only a text for "this should not be viewed in a browser, get an aggregator instead" and two buttons: "view raw feed" and "view beautified feed".

Future
I think the FeedSubscriber can be made pretty extensible to support future types of subscriptions. Currently the only thing you need to subscribe is the url of the feed. But richer distribution systems could appear similar to BitTorrent, where to actually subscribe to a feed you need a more complex "feed info" blob (a la .torrent file).

This brings us a little bit closer to the mime-type solution:
The one where a mime-type is created for "feed information" (or "feed pointer") and may be hosted in a separate file, rather than inline in the <object> tag. Another difference is that the subscription is triggered by an action in the client, not merely downloading a file.

[Not the one where downloading the RSS triggers the subscription: that's bad for multiple reasons, including that a feed should not be confused with a "feed information" data type. The aggregator only needs the "feed information" (url), not the feed itself. This is different from the PDF or QuickTime examples that Tim Bray raises. An aggregator is not an RSS viewer, it is a subscription manager.]

FeedSubscriber parameters should be maintained backward compatible when such upgrades occur. But I'll include a "required version" parameter that can be specified in the object tag, so that the FeedSubscriber can detect the situation and offer to upgrade itself.

"Subscribe Feeds" button in the browser
Joshua Allen and Gina Venolia brought up another approach, that I didn't understand right away but is pretty interesting.
The idea: users shouldn't have to search through the page for a "feed" button, the same way they don't have to search for a "print" button.

The solution would work by looking for linked resources like <link rel="..." application="..." ...> in the page. If multiple links are present, the user should be allowed to select which one he is interested in.

[This functionality can even be implemented with a bookmarklet or a remote context menu entry in IE. The javascript needs to be aggregator specific, and can popup a window with links to subscribe to the linked resources that it extracted from the DOM.]

In itself, this doesn't make it easier for feed un-aware users. Something else, like a prompt the first time the user encounters a feed-enabled page would help educate users. Also a little symbol next to the "SSL lock" could appear when feeds are available on a page.
It seems Mozilla Firefox would be a good browser to start experimenting with this, as the version 0.7 added a very similar feature for detecting alternate stylesheets and switching them.

Also, one could argue that the location of the feed button within a page does in fact matter. It gives context as to what it actually will suscribe to: the main feed, the current category feed or the comment replies feed.
Whereas with a "print" approach, you don't know that there is a comment replies feed on this site until you activate the browser functionality.

Work items
... for me and anyone who can help ;-)

• Complete a working FeedSubscriber object prototype, with at least support for IE and Mozilla on windows. A simple demo site to be provided.
• Dig in the feed: solution a bit more and investigate whether that's something IE/wininet team would be ready to support.
• Investigate adding a "feeds are available on this page" icon in the statusbar for Firefox (via a plugin/extension for a start).

Links:
Singing the One Click Subscription Blues.
One-Click Subscription to RSS and ATOM Feeds.
Request For Comments: The "feed" URI Scheme [final draft].
Windows XP Expert Zone implemented the XSL transform for RSS.
Introducing Aunt Tillie to RSS
One-click RSS subscriptions, continued: the lesser of two evils?.
How To Use Mime-Types To Get Your Aggregator To Subscribe To An Atom Feed.
A list of RSS aggregators.
Standards Compliant method to add Quicktime movies to pages.
Embedding flash without <embed>.

Web game collection

Most of these are Flash-based games.

• Separate randomly red and blue moving balls.
• Typing fast ;-)
• Make a Mondrian.
• Set game.
• Grow a tree
• Yeti sports.
• Lots of flash games.
• Dolls hitting heads animation.
• Hammer their heads (using keypad).

RFC: RSS one-click subscription

One reason RSS/Atom feeds aren't mainstream is there is no easy one-click subscription and the first feed encounter isn't user-friendly enough. Jon Udell and David Ely described the problem.

Current solutions:

• have the aggregator clients register with some mime-type (for either RSS or OPML),
• have a new protocol uri scheme (feed:),
• support as many clients as possible via javascript (see QuickSub),
• transform the RSS with XSL in the browser to help newbies (no really a one-click subscription solution though).

New solution:
Note that this is a draft. I am in the process of prototyping this. I'll post it when I have the complete working solution.

The solution relies on the use of the html object tag. That tag is used for embedding flash or quicktime in web pages, for example:

The object tag has very nice properties: when you don't have the required object or if you have an old browser, it offers a fall back.
The "subscriber" button should support any platform that can run a flash player in the browser.

In the case of feed subscription:

• if you have an aggregator installed, the embedded object could be handled by the aggregator or installed separately and configured for your specific aggregator. That's how you get one-click subscription,
• if you don't have an aggregator, you click a regular feed button that takes you to a beautified feed page, that has a quick intro and a link to an aggregator repository. If you really want to see the feed's XML, you can click a javascript powered button.

Replace the orange Feed button:
The orange feed button needs to be wrapped with an object tag:

If the ActiveX control with class ID [1] is installed, it displays a custom "subscribe" button. When you click on it, it uses the feedurl parameter [3] to subscribe.
If the control isn't installed or the browser doesn't support embedded objects, the classic orange RSS button [4] is displayed as a link to the RSS.

Change the RSS:
The RSS feed should be transformed via client-side XSL (by inserting one line of XML: <?xml-stylesheet type="text/xsl" href="/rss2.0-to-html.xslt" media="screen" version="1.0" ?>) to look like:

This part is meant to help new users understand what feeds and aggregators are. Very few users actually need to the the raw XML of the feed. My own RSS feed implements this kind of XSL transform, and more sites are starting to adopt this technique as well.

A list apart describes how to remove/switch a stylesheet using javascript.

Pros:

• help new users understanding feeds and finding an aggregator to install,
• one-click subscription for anyone that has an aggregator,
• should fall back nicely for users that don't have an aggregator yet (will explain them how to get one) or to existing mechanisms like QuickSub, and in old browsers (users need to copy the link manually into their aggregator),
• it should be possible to re-use the same ActiveX control for most aggregators. An aggregator would just need to configure a registry setting for the subscription url (say http://bloglines.com/sub?rssurl=%1&description=%2, or http://localhost:8003/sub?url=%1&info=%2). Aggregators that don't support registering using a url, should create their own control and install it.
• no new mime-type or protocol,
• it's still possible for power users to see the raw XML feed, but most users won't

Cons:

• requires blogs to start using the control for both the orange Feed button and the XSL for the feed XML (it would help if MovableType could include the object tag in default template),
• after the standard GUID and parameters for the object are decided, backward compatibility should be carefully maintained.

Parameters:
The component needs the url for the feed.
A parameter should specify the image that the button will display. This way the blog still has control over his layout and the button doesn't add any constraint.

It could also have a description for the feed, like "Curiosity is Bliss (RSS2.0)". This description could be used when the aggregator asks for confirmation, or maybe as a tooltip when hovering over the button.

Next steps:
I'm learning how to write a custom component for use as an embedded object. I'll write a sample for bloglines one-click subscription and will convert this blog to support this convention (the same way some blogs are currently using QuickSub).
I'd like to get feedback on whether bloggers and aggregators would be ready to support such a solution. Thanks for your comments on that and any technical aspects as well.

Update: I started the prototype and ran into an ActiveX warning issue in IE, when using parameters ("An ActiveX control on this page might be unsafe to interact with other parts of the page. Do you want to allow this interaction?"). I don't know yet how to get ride of it (signing, config, ...?).

Update: Removed warning with a registry setting (safe for initialization).

Update: The prototype is well underway. It basically works, but I still have work items:

• Open a small/simple popup window on the url from the registry,
• Add a right-click menu to the button with "subscribe", "learn more", "copy feed location", "copy subscriber", "preview" (users should never see a raw XML feed),
• Prototype the xsl stylesheet switching in javascript,
• Let the control size itself and accept a relative url for the image path,
• Make it work in Mozilla,
• Have some kind of effect (blurring?) when hover over button to differentiate from a regular image link,
• Make an installer and configuration utility (to pick the aggregator you use).

Some of the things that I came accross so far:
For the button to work on the XSL-transformed feed page, some javascript is needed to pass in the current browser location into the button. The page should also include instructions on how to manually copy the feed url.

The Mozilla implementation will probably need a mime-type defined (for the <embed> tag, like flash)... which makes me think this turns out to be just a variant of the mime-type solution.
The difference is that instead of creating a new file type or format, the "media" (which is the feed information) is inlined in the <object> tag.
That works because a feed info is only a url, today, but this might evolve (say with WS-Eventing subscriptions). In that case we'll move toward a more complex format again, which probably will be loaded from a separate url as usual media are.
The button will be extensible to support these new/richer subscription models.

I thought about implementing the control using Flash, but that means an aggregator can't install it's own version of the "Feed Subscriber"... But still it should be possible to write Feed Subscribers for all platforms that Flash support.

Update: Fixed the mention of the feed: "protocol", as it is instead an URI scheme (thx Dare).

Update (2005-01-17): Winer brings up the one-click subscription problem again. Same solutions re-hashed in the comment thread, no single best solution stands out...