I've been using modified del.icio.us bookmarklets to feed my del.icio.us account, and thought I should share those. More experienced users will find nothing new here, but it's just as likely that it will interest some people.

del.icio.us already have a list of bookmarklets for various browsers, and I started from there.

I have made two additions to the default bookmarklets: a faster way to enter an extended bookmark description, and the ability to add a predefined tag.

This is my generic "add to del.icio.us" bookmarklet, "add bookmark":

javascript:location.href='http://del.icio.us/new/martind?
	url='+encodeURIComponent(location.href)
	+'&title='+encodeURIComponent(document.title)
	+'&extended='+encodeURIComponent(getSelection())

Note the code after "extended=" -- this tells the browser to get the current text selection and use it for the "extended description" field. Before I bookmark a page I try to find a descriptive sentence on the page and select it, then click on the bookmarklet, and when del.icio.us loads the "new bookmark" form I usually only have to tweak the text a bit.

It's a really simple addition, but greatly enhances the experience -- I've already found browsing my bookmarks easier because of having good extended descriptions. Look at my del.icio.us page for some examples.

The second addition I use provides a default tag for new bookmarks. I really only use it for two tags: "revisit" and "later", which are my tags for pages that I either want to watch for changes, or visit at a later point when I have some spare time.

This is also pretty simple: "revisit"

javascript:location.href='http://del.icio.us/new/martind?
	url='+encodeURIComponent(location.href)
	+'&title='+encodeURIComponent(document.title)
	+'&extended='+encodeURIComponent(getSelection())+
	'&tags=revisit'

...so all that I did is add a default value for the "tags" parameter. Also a simple addition, but a great productivity enhancer. It now only takes two clicks to flag a page for later: clicking on the bookmarklet, and then clicking the "OK" button on the "new bookmark" form.

Note that I didn't "invent" these -- I first saw the text selection method somewhere on Jon Udell's site -- can't remember where, maybe in the del.icio.us screencast. And the default tag parameter is pretty obvious.

I guess it would also be easy to create a bookmarklet that doesn't even show the "new bookmark" form and simply adds the page to your account without requiring further user input, but I've found that I like to inspect the bookmark properties before I add it.

I'm having a series of conversations with Falko Schmid about current interfaces to structured information, and about using existing web services to build all-encompassing information structure and search facilities.

Our conversation started with the realization of a problem: apparently nobody can build a single system that integrates all information. There have been many attempts to accomplish that (Google and Wikipedia being the most prominent and successful) -- but if the last years have shown us anything it's that there is no way to define a stable content structure that contains everything. There are just too many reasons why attempting this will fail. Even Wikipedia is only good for so many things -- you don't use it to find the best price for a book.

Read on for our proposal.

Full entry

I'm currently testing the Safari CookieFilter script and have stumbled upon strange launchd behavior that I can't explain nor find a way to fix. Essentially launchd seems to be fairly liberal in how it interprets LaunchAgent triggers, and regularly seems to choke under conditions that I can't reproduce.

The current release version of the CookieFilter LaunchAgent is designed to trigger the script every time there are changes to your Cookies.plist storage. But after running the LaunchAgent for a couple of days I found that it seems to stop responding to changes of this file. With some testing I found that this seems to happen after somewhere between 20-40 hours, but the reason is unclear.

My current assumption is that either there is an error or missing statement in de.dekstop.CookieFilter.plist that I can't find, or that this is a launchd bug. I've currently given up finding the cause, and decided to try another approach: to launch CookieFilter periodically using the StartInterval directive (I set it to trigger every 60 minutes).

But even this is unreliable: now the CookieFilter script is started roughly every hour, but also frequently at seemingly arbitrary points in time in between the hour. Looking at the logfile I can see that is has been triggered at least 20 times in the last hour.

So the current conclusion seems to be that triggering a LaunchAgent periodically instead of via a WatchPaths entry seems more stable, but there is no guarantee that your StartInterval setting is adhered to.

The other conclusion could be that I simply have to reboot the system after all the launchd fiddling to bring it back to a clean state (In the beginning of testing I've used the same LaunchAgent Label for LaunchAgents with different behavior, which could have triggered launchd bugs); but currently I'm reluctant to admit to that possibility. Update: rebooting didn't help.

Watch this blog for further updates.

Normally I don't even glance at site ads, but while browsing Roger Ebert's site I saw a Google ad that made me stop and read. And reload.

As if our democratized content mediation process wasn't confusing enough we now have Google ads that spread awareness of fraudulent business practices behind services advertised on other Google ads, and Google ads that look like they spread awareness of fraudulent business practices behind services advertised on other Google ads but in reality lead to fraudulent products.

How bizarre: advertisers devalue the messenger (the Google ads medium) in an attempt to relativize a (probably valid) critique of their business practices. Don't like other people criticising what you do? Shout louder. And even more interesting: Say the same things that they say, but mean the opposite.

A bizarre postmodern twist on the language of advertising. Promise one thing, and after the click provide another; and assume that the customer will be blinded enough by colorful promises to forget that he is provided with the opposite of what he is promised.

This seems like a cynical admission of the fact that clickrates don't necessarily correspond to your product, but to the attraction of your promises; and it is a reaction to the assumption that web surfers in essence are a forgetful and easily impressed species.

Went to the cinema at Potsdamer Platz; due to some unfortunate timing the evening ended different than planned, but I had fun nevertheless.

Some of these photos are illegal under German copyright law (UrhG), paragraphs 12-21, 23, 32, 52, 62 and 63, unless they are regarded as a quotation according to paragraph 51, or unless Flickr is to be regarded as "public space" according to paragraphs 58+59; and they violate articles 1, 3, and 4 of the European Directive 2001/29/EC ("on the harmonisation of certain aspects of copyright and related rights in the information society"), and article 5 of the European Directive 2004/48/EC ("on the enforcement of intellectual property rights").

I don't even want to think about finding the proper American equivalents.

Read the full story at Flickr: "Tuesday Night Out (almost)"

In my earlier article, "Connecting Web Services: Inherently Insecure", I commented on the sad current state of security in connecting public web services like Flickr, del.icio.us, last.fm and others with specialized client software. In this article I'd like to make suggestions as to how this current situation could be improved. So as a follow-up to my complaint above, this is a proposal of a simple method to provide more secure web service client authentication that should adress most of my ealier criticism.

Read on for some real-world scenarios, and a suggestion on how to securely connect web services.

Full entry

I was looking for ways to automatically start my Safari CookieFilter script, because if I had to launch it manually every time I wanted to clean up Safari's cookies I would never really use it.

On a Windows machine I would put the script into the Autostart folder so that it would be executed upon system startup, but I've found that I never really reboot my Mac, so that wouldn't work.

Another option would be a script that invokes CookieFilter before it launches Safari, and to only start Safari via this script -- but this idea seemed to simple and obvious that quickly I discarded it as uninteresting. After all, I want to learn something along the way of doing this; and I didn't want to mess around with dock icons and Butler to make sure I never executed Safari directly. I was looking for a solution that is as transparent to the user as possible.

So while looking for other ways to automate processes I quickly found that launchd, the system launcher introduced in OS X 10.4, is actually quite interesting for such tasks -- and I had planned to look into it anyway. So I started to read some documentation, and found a solution involving launchd that, while it is a bit of a hack, works quite well, and does everything I need.

While writing the CookieFilter Perl script I had found that Safari uses the shared cookie storage, which is stored in ~/Library/Cookies/Cookies.plist -- you can open it with the Property List Editor to see the cookies.

Safari loads this file once when it starts up, and from then on regularly overwrites the file when there are new or changed cookies. Apparently you can modify the file even when Safari is running -- but the changes are only reflected after Safari has been closed and restarted, because that's the only time when it reads the file.

This creates a nice setup for a solution that mirrors Firefox's great implementation of a cookie whitelist, where all cookies are accepted for the session, but where unwanted cookies (i.e., those which are not in the whitelist) are discarded when the Browser is closed.

Which means: all we have to do is watch for changes to Cookies.plist, and then execute the CookieFilter script. And of course launchd can do that.

Get the updated script and launchd job at the CookieFilter page.

Since Tiger I've been pretty satisfied with Safari, and there are fewer reasons to install third party plugins than ever. Yeah I could use Firefox's keyword search, but after having one too many browser crashes due to a SIMBL plugin running amok I figured I could just as well live without it. The only thing that has really been missing was a working Cookie whitelist. There is Cookies Eater, another SIMBL plugin; but that hasn't been updated for the current Safari version yet. And even if it had been, I'm not so sure that SIMBL is the best way to enhance applications and still maintain a stable system.

So after one too many times of hand-deleting unwanted cookies I figured I could just as well write a script for it; after all, Safari's cookies are stored in a .plist file, which basically is XML. And then I found the hardly documented but functional Mac::PropertyList. After some time of figuring out the specifics it turned out it's remarkably simple.

So here it is: cookiefilter.pl -- simply edit the @valid_domains array to reflect your personal preferences, make sure that the script finds Mac::PropertyList, and close Safari before you execute it. De rien.

#!/usr/bin/perl -w

# Simple whitelist filter for Safari cookies: removes all 
# those cookies where the domain name is not in the whitelist.
#
# Edit the @valid_domains array before you execute this; and 
# Safari should obviously be closed.
#
# No warranties. Backup first.
#
# Martin Dittus, http://dekstop.de/
# Last change: 2005-07-25

use strict;
use warnings;

use lib './lib';
use Mac::PropertyList;

my @valid_domains = (
	"flickr.com", "musikcube.com", "del.icio.us"
);

my $filename = glob("~/Library/Cookies/Cookies.plist");
my $in = Mac::PropertyList::parse_plist_file( $filename );
my $out = Mac::PropertyList::array->new();
my $count = 0;

foreach my $entry (@{$in}) {
	my %cookie = %{$entry};
	my $domain = $cookie{"Domain"}->value();
	my $match = 0;
	foreach my $item (@valid_domains) {
		$match = 1 if ($domain =~ m/$item/i);
		last if ($match == 1);
	}
	if ($match == 1) {
		push @{$out}, $entry;
		print "Keeping cookie for $domain\n";		
	}
	else {	
		print "Removing cookie for $domain\n";
		$count++;
	}
}

open(FILE,"> $filename") or die $!; 
print FILE Mac::PropertyList::plist_as_string($out);
close(FILE);

print "$count cookies removed.\n";

During the last couple of months I've been using more web-based services like del.icio.us, Flickr, last.fm and others, and while I like the growing availability of web site APIs I'm often wary when testing out the possibilities, e.g. when testing a new client software: They usually require that you hand out your full login data!

Read on for my rant on the current state of web service security, and some suggestions.

Full entry

Asa follows up on his recent Linux not ready for the desktop commentary. He acknowledges that there are several lines of argument that disagree with his assessment, and he reacts by making this a bigger topic in his blog: he announces a four-part series about more specific questions of Linux on the desktop.

I've been using various SuSE Linux distributions since the mid-/late-90ies, and I love it as a server, but I definitely agree that Linux is still anything but user-friendly. I've been trying some versions of the Ubuntu Live CD and was delighted by the approach; but there still are spots where the "old" Linux approach shines through and destroys the apparent simplicity. And even the more recent SuSE distributions lack user-friendliness.

Small example: System boot. The Ubuntu Live CD loader could use some heavy optimizing and UI work. It takes ages to load from a CD, and there are silly text mode screens with cryptic messages. The SuSE boot process in comparison uses a graphic mode loader, but manages to make it look shrill. Too many random colors.

When (if) I boot up my Powerbook, it shows a logo and a rotating circle. Nothing else, until the login prompt.

Yeah the boot process is indeed not a reflection of user-friendliness, but it's an indicator of the underlying thought process. The SuSE desktop matches its boot process: shrill and loaded with options. Ubuntu: spartan. OS X: mostly clean, and rather refined.

I love Linux on the server; but not on my dekstop. A user-friendly Linux desktop can't be created by the people who make Linux so great for the server. This requires a culture change, a new class of developers. Let's see how Ubuntu turns out... and until then I have the best of both worlds.