Niall Kennedy has a post[1] on browser history visited link sniffing. By injecting popular links using JavaScript and checking css :visited, he’s able to track where people have been and customize the user experience to suit. It has privacy implications, I can see this being used to build up user profiles without consent and target all sorts of things like phishing and advertising. Having an opt-in system in place to provide this kind of data for sites to use, on a per site basis, could be an interesting use of this data though. If users could be presented with an opt-in option on sites to use this and store this information, it could be useful and possibly bypass privacy concerns, without the need to install anything. Doing so, user profiles could be built up over time, through data-mining those popular links and content then targeted at those users. It does however require data mining potentially popular links in the first place, but should you find a history match, crawling that site for more links and then matching those to users browser history could create a nice usage pattern to mine useful context from.

Apparently this is an old issue, going back to at least 2001. I worry that in all that time XMLHttpRequests will (and are) being used without consent to brute force test a users browser history for visited links, done so while hiding the bandwidth used as a movie or flash is played, etc.

Might be time to start clearing your browsers history, or getting this Firefox plugin[2] if your worried.

[1] http://www.niallkennedy.com/blog/2008/02/browser-history-sniff.html
[2] http://www.safehistory.com/

Jeff Croft writes about whether CSS belongs in RSS feeds.

I just went round-and-round with Brian Livingston, an editor at WindowsSecrets.com, about his article entitled CSS Support is Poor in RSS Feed Readers. Brian believes that we web producers should be using CSS in our RSS feeds to make our content more readable — he talks about colors, typefaces, sizes, etc.

Interesting discussion. While I'd rather CSS and feed content were kept seperate, issues like Jason raises in embedding objects, in his case microformats into posts and feeds that he later parses and displays using javascript, has me questioning this logic. While I'm sure there are ways around issues like his example raises, like external sytlesheets(where supported ahem), etc. I still see that inevitably some users and developers will want to be able to do more and interact and share more than just static content in feeds, and to do that options need to be there to carry this out.

You only need to look at any systems where there have been mass amateur uptake of them to see of potential benefits to allowing the free-for-all. People are attracted to glitz and glam. The more people, the more innovation and resulting technology exposure allowing it to flourish, and who knows what that may bring us next. (see this interesting videocast of Ben Hammersley for more)

For me a feed is all about sharing <em>information</em>. It shouldn't matter what that information is. Apart from security issues with certain style attributes, I don't see a problem including CSS inside it so long as it's function is defined and preferably not as styling. I believe in external styling wherever possible, that way the end user can then being presented with the option to use that styling or not. However styling critical to function as in many AJAX apps are now using, seems reasonable to include. Though ideally it too should be referenced externally should it be deemed dynamic. Often however it seems pointless to do so with such settings vital to operation that are unlikely to change over time. eg. display:none; on Jason's example. The problem as I see it, is there is no standard that I know of tells parsers what external CSS may be vital for functioning. Maybe we need standards of "safe" styling?

Saying all that and wanting to allow freedoms, the last thing I want my feed reader preventing me doing is reading because of some designers like for flashing objects and other heinous crimes. But then I'd probably just unsubscribe from those feeds…
I'm sure there are ways in which the best of both worlds can be accomodated. Seems to me counter-productive to just just say flatly that; no CSS shouldn't be in feed content.

As an aside, there's been an interesting discusson at Clinton DeWitt's blog thats worth reading in regards to RSS and ATOM placing interesting items in feeds.