Hello, throngs of adoring fans. I know it's been too long. I'm sorry I've been neglecting you, but I've been very busy at work.

As a result of that, I'm looking forward to sharing these thoughts somewhere else. It might be pretty soon. Not that LJ hasn't been great - but there are obvious reasons to move on.

As long as I'm dropping oblique hints, I was talking to recently, and the subject of a capability-based chat system came up. I suggested that perhaps adding users to your buddy list should be the sort of thing that users can delegate to each other - in other words, adding someone to your buddy list is the same as acquiring a capability that allows you to determine their status and send them IMs. I explained that providing this granting in-system would be a good idea, since preventing it out-of-system is impossible. The de-facto "capability people", e.g. erights.org, even have a nice document explaining why this prohibition is impossible.

Read that document. It's a good one.

For context, though, look specifically at this diagram:



While from a security perspective, the author is technically correct, from a user interface perspective, he's got the issue backwards. The author of this diagram seems to be implying that each of the arrows has equivalent cost. In fact, they do not. If the system openly exposes the ability for bob to grant the power directly to mallet, then the mallet -> power path is effectively of zero cost to bob. However, if it does not, bob has 3 choices to create his message laundry:

1. Trust Mallet implicitly, giving him Bob's authentication credentials.
   Cost: Bob is now completely at Mallet's mercy, as far as the system is concerned; he has all of Bob's power now. This is probably a situation that Bob wishes to avoid.


2. Manually launder all messages, using copy/paste or written instructions from mallet.
   Cost: Bob has to effectively be Mallet's slave, as far as the system is concerned. This will probably annoy Bob pretty quickly.


3. Write a message proxy which runs on Bob's computer and that Mallet can connect to.
   Cost: Bob has to start a software company and produce a piece of software. This is more expensive than most people imagine. Even if you assume the software already exists, Bob still has to pay for bandwidth for all of Mallet's messages.

I believe cryptographic math may have lead programmers' thinking about security astray. Security is not a hard mathematical problem, as crypto implies: it is simple arithmetic. Security is not about making cipher-breaking completely impossible: people make cipher-breaking impossible because that is a relatively easy way to increase certain kinds of security. Security as a whole, though, is an economic problem. It's about making the cost of an attack exceed the benefits from a successful one. If you can trend the cost/benefit ratio towards infinite cost and zero benefit, then you are successfully making the system more secure. After all, physical security is impossible to achieve with the same perfect mathematical certainty that cipher security is - not even close - yet, people still put locks on their doors.

In the case of a chat application, it is a potentially annoying feature to allow users to delegate their interpersonal authority. In the rather long (in internet terms) life of AOL's instant messenger service, no-one (to my knowledge) has bothered to write a chat-proxy bot that would allow the sort of message laundry described above.

I'm curious what other capability thinkers have to say about this, though.

I hope to have some more time to think out loud about this, especially about the implications of cost as measured in spent attention. The internet era is creating a new commodity: attention. There are very few tools for managing and trading it. Right now, attention is measured in "eyeballs", as advertisers say, but that will change, as the personal and professional consequences of spending too much attention in the wrong place become socially apparent. Will you be more reluctant to pay attention if you can measure that attention in dollars first?

That's it for now, though.

I was just reading about Ted Nelson, who still believes he is locked in an epic struggle with the web. Is it possible to be locked in an epic struggle if your opponent doesn't even notice?

Anyway, I came to this site after reading my favorite philosophy-disguised-as-humor site, and I thought that some other people should see these things juxtaposed.

Mr. Nelson: (whose work I am citing in a manner I am sure he would not approve of)

Most people don't understand the copyright law and how much it restricts re-use of content. No other system allows such re-use and is legal.

Others are trying to break the law, hoping that copyright will become permanently unenforceable. Ethical issues aside, this is probably a mistake. They do not recognize the determination and resources of the publishing and film industries. The large fines and occasional imprisonment of violators are likely to be only the beginning.

Still others are trying to change the copyright law, which is now the same in most countries (the Berne convention). Good luck, but change is not likely.

We work within the law. With the transcopyright system we offer the only legal, honest, daylight method of making on-line content reusable in new ways. Transcopyright is a permission system (or license) which lawyers agree is probably legal in all countries.

Mr. Holkins:

Digital delivery, man. It just freaks these people out.

Imagine that you had to go to a well every time you wanted water. Then, somebody figured out a way to get the water to come out right inside your house! I don't blame them for being scared. Progress is a bitch.

Plumbing can only remain a crime for so long while people still get thirsty.

As AMK has recently proposed, I think that the Python team should be focusing more on the standard library. However, I refrain from posting on python-dev to this effect any more because all I've had to contribute to the discussion is directionless whining. I consider it a given, however, that the standard library has reached a near-toxic level of bit-rot, although I rarely examine that assumption, although nits periodically come up that reinforce this impression, I hadn't ever thought of a nice "poster child", an issue with the stdlib that reflects the nature of the systematic problem.

The other day, when trying to hunt down a bug in my own code, I found a perfect example of this, though, and I think it should be a point of reflection for the Python team. Let me dress up this next point a bit, for emphasis:

The standard library does not provide a functioning debugger.

But what about pdb.py, you might ask? Well, pdb:

1. occasionally blows past breakpoints due to .pyc/.py/sys.path disagreements about pathnames
2. has no way of saving a set of breakpoints across invocations from within the debugger
3. integration with Emacs support does not work with python packages
4. doesn't allow you to view the stack when breaking inside a generator
5. provides no support for remote debugging or IDEs

There are probably even more issues than this, but I generally use a set of hacks included with Twisted and Twisted's Emacs support to work around these deficiencies.

These are also problems with basic functionality. There are other things I think a Python debugger should be able to do, for example, "fix and continue", which even environments working with a far less flexible language (for example, Microsoft Visual C++) manage to do.

So, I will focus on this point, for future discussion of Python development, to avoid unproductive discussion of differences of style and taste. I think we should all be able to agree that the Python debugger should not be broken in basic ways, such as missing breakpoints, and should work with all aspects of the language, including generators and list comprehensions.

Apparently the MPAA is harassing Linux Australia on my behalf, without my permission.

I guess this just goes to show that they have no respect for copyright law. Bunch of bloody anarchists, they are, those MPAA guys. Stealing the hard labor of innocent copyright creators of content, rapacity on the high seas, etc etc.

One LJ to another: apparently Doc Searls found my commentary worth linking to. He says "Read the whole thing.". I'm flattered - apparently my impressions of others' experiences in corporate IT were at least somewhat accurate.

I have started using Straw today in earnest, thanks to the ability to aggregate my LJ friends list. I particularly like Straw's UI. I don't think it's using Twisted - although it should be, since it's in python - but it behaves like it does. It is nice and responsive. News aggregators are cool. I'm even aggregating aggregators, most notably Planet Twisted, which if you aren't reading, you should be. It's a Planet thing.