“Design depends largely on constraints.” — Charles Eames
Sunday, 24 April 2005
Should cookies be shared between your RSS aggregator and your Web browser? If they were, sites would be able to automatically personalise the feeds you subscribe to; would people be interested in that, or see it as an intrusion in their privacy?
The possibilities are certainly interesting; if I knew who you were, I could not only modify entries to suit you, but I could also insert an entry into just your feed, saying anything from “Hi” to “Do you want a job?” Of course, advertisers would be especially interested in this.
I’ve done some testing, and can’t find any aggregators on Mac OSX, at least, that do this, even if they use WebKit (OSX’s HTTP and HTML framework). I imagine that WebKit’s developers made a conscious decision to limit cookies on a per-application basis, but I don’t know that there’s any real reason for that.
Stepping back, I think the relevant question is what is the scope of a cookie? The Cookie RFC just talks about “User Agents;” is that a single piece of software on my computer, or is it my computer? In certain lights, the delineation is fuzzy and somewhat arbitrary. The same question could be asked about passwords for HTTP authentication.
One final question — what would the sharing mechanism be? I’d imagine that individual operating systems would have their own way of sharing cookies between applications that use common Web frameworks, but what if your cookies were made available on the Web themselves, as stateful resources?
Filed under: Syndication, Web
RSS Bandit uses the same cookies as Internet Explorer for a given site.
Monday, April 25 2005 at 9:14 AM +10:00
Sage runs fine under Firefox on OS X for me, and it's an aggregator. And I suspect it shares Firefox's cookiejar.
Monday, April 25 2005 at 2:52 PM +10:00
Unintended sharing is certainly interesting: I subscribe to the feeds for a couple of MSN searches as Live Bookmarks in Firefox, and one day while searching in the browser for something buried hundreds of results down I set my preference to 50 results per page. Rather surprised me, a few days later when I next looked at the feeds, to see that they now contained 50 items instead of the usual (nearly) 15.
But I don't really have a cookie jar suitable for any random program to use: apparently when I use RSS Bandit, it sends whatever cookies I've collected testing things in IE, Firefox itself uses the cookies from whichever profile I'm using at the time, some of which are testing, some of which are separate identities, and I certainly don't want Feedburner, for instance, setting any cookies whatsoever, what with the feeds for multiple publishers and images inserted in thousands of separate domains setting them up to be the next Doubleclick.
Monday, April 25 2005 at 7:56 PM +10:00
Why use a cookie? Wouldn't it be easier to generate a random identifier into the feed URL similar to the way mailinator works? Then all your sharing problems go away. Sharing
http://www.mnot.net/blog/index.rdf?ea031k3cbe
would be simple
Individuals could even create ad hoc references to the feeds
http://www.mnot.net/blog/index.rdf?winter-feed
http://www.mnot.net/blog/index.rdf?another-feed
Tuesday, April 26 2005 at 6:08 AM +10:00
Certainly, the “right” way to do it is with a URI. I can think of a number of reasons (justified or not) why people don’t like using session identifiers them;
* introducing transcription errors - when people have to work with the URI — e.g., writing it down, copying it, visually inspecting it — there’s a chance for errors, for for them to purposefully remove or change information.
* ugly — session identifiers in URIs aren’t as pretty.
* inconsistent — it’s very difficult to guarantee that a session identifier will be preserved, especially when you have external links coming in, etc.
* adding server complexity — regenerating each page’s links with the appropriate URIs adds complexity and load to the server.
* affecting cacheability — you can’t share a page with customised links between many users; if you identify them with a cookie, you don’t have to customise the links, making it more likely you’ll be able to share the page (whether it’s actually marked as cacheable is another problem).
Interestingly, HTTP authentication addresses these problems as well as cookies, because it doesn’t show up in the URI. Also, modern browsers will seamlessly keep your authentication details for you. I think people still prefer cookies for yet other reasons, which have been discussed before;
http://www.mnot.net/blog/2004/08/26/form_auth
Tuesday, April 26 2005 at 8:20 AM +10:00
Personally, I think that cookies / session are the way to do it, but that they shouldn't be encoded in URI's. If you encode it in a URI, and then, for example, do an OPML export of your feedlist for other people to add to their feeds, you completely screw up what's going on.
Another reason why you might want to do this, incidentally, is so that if, for example someone goes on holiday and is away from their computer for a week, when they refresh their feed it can be tailored so that they receive all of the entries that they missed, not just the ten most recent ones. *That* is where the real benefit of identifying users lies.
-- Andy
Wednesday, May 4 2005 at 9:01 AM +10:00