/devel

Found this at David Ascher’s blog, where he said:

It’s a brilliant paper about user interface design, or the lack of it. In the vein of Tufte, but much more applied to software. The tail end of the paper is a little too fluffy for my taste, and the paper would have been better without it, but that’s a minor flaw on what I hope will be an influential paper. I’ll try and get people to read it, but it’s too long for many.

It pretty much says it all. Don’t let its length discourage you from reading it.

I’m still a fan of OpenID, even though it lacks solid solutions to some of its problems.

Much has been said about risk of phishing and possible solutions, but I’ve been more ignorant than some to a transient nature of OpenID identities. Simply put, even if you run your own server, you don’t own your domain. You just rent it. Thus you don’t really own your OpenID URL either, which makes it a rather risky tool where some sort of permanent identity is needed.

There are plenty of cases where there’s no such need and OpenID is in my opinion a better solution to them than existing ones. But it isn’t good enough where something less fleeting is required. Maybe XRI/XDI is a better answer?

I don’t know. I’m still a fan of OpenID. It’s just a bit less useful than I first thought.

If implementation will be as good as intentions are, and there’s little reason to doubt it, then this thing will rock.

People make mistakes and that’s why we log every error that happens on Marela pages or its API. I imagine most services that care about quality do more or less the same, since it is a great way to find yet undiscovered bugs.

There’s an additional benefit when it comes to an API. You can also get an insight in what developers would like to do and how they go about doing it. With a bit of care you may even correct badly designed calls before they get too widely adopted.

What may not be as obvious is that not all calls are equal and some of them probably need more careful reporting. A good example would be failed authentication attempts.

Marela is one of services supported by Fotofox, a popular photo sharing Firefox add-on, which is great. However support for multiple different services invariably leads to a problem, where users send their usernames and passwords to the wrong site. We weren’t prepared for this and our first reaction was to simply religiously delete all such reports from our logs to prevent any possibility of an abuse.

I think this was wrong, so we changed it. Probably the best way is to record failed authentication attempts the way Unix systems do, by logging just username that was used in an attempt and its success, while ignoring provided password completely. This way we still obtain valuable information while protecting data that we clearly shouldn’t have access to.

This is of course just an example. My main point is that a sufficiently large API will have calls with different privacy needs and API designers should think carefully about what needs to be recorded in service logs and what mustn’t.