A somewhat technical discussion on why hardware-based content protection is doomed to failure for at least several iterations, based on discussing Intel's "LaGrange" technology. This is the first I've heard of this so I don't know how this fits into the "master plan", whether they believe this is the first and final iteration or what, and how this ties to Palladium. The interesting part about this article is that it's strictly technical and discusses why this just isn't going to work for a while. The main thesis paragraph of the essay is probably this one from the middle:

[Why is embedding content protection directly into the silicon of a processor doomed to failure?] Because we don't know, we really don't know, what sorts of protection make sense in the emerging digital, networked marketplaces. Despite 35 years of computer security research, we have not yet increased our understanding of what needs to be protected beyond a simplified, very unworkable notion of military document security. Now joined with a simplified, very unclear notion of what Hollywood might really need (as defined by its lawyers and lobbyists - not the most technically savvy designers).

So what other religious phrases can we adapt to Murphyism?... Don't be the last on your block to get a Murphy Saves bumpersticker. Ask your friends, Have you accepted Murphy as your personal savior?. I haven't read enough of the Book of Murphy yet to know whether Murphy died for my bugs, or because of them.

Actually, I think some Eastern religion fits in much better here. "We all have a little bit of Murphy inside us." "Bugs do not truly die, they reincarnate. The more Murphy karma they have, the bigger they come back." And the coup de grace, "The Murphy that can be understood is not the true Murphy."

At every job I've started since the computer age began, I have been required to sign a document that basically threatens the new employee with expulsion if the phone, computer or office is used for any type of personal business. I have always signed. But now surveillance software has arrived, and I think back on that document with dread and anger. [osOpinion]

I think this is close to the right approach to take if this becomes an issue in your workplace. As I've said before, I think employee surveillance is largely between employee and employer. Point out the decrease in productivity they should expect from their best workers. Especially because of the naive trust placed in computers, it's better that nobody have the information at all.

One week and a handful of days ago, I was knocked offline by the cable company, because they put my connection on a four-way splitter in the cable companies box. I am finally back online.

It took them one week after I called to get someone out here. It took that someone five minutes to fix.

Added to the fact that I correctly diagnosed the problem (adding someone else to the splitter) based on my TV signal behavior, this has been quite exasperating. The fact is that I could have fixed it myself if I could have gotten to the box...

Wired.  The RIAA wants information on the identity of a Verizon user that it claims has thousands of MP3s avaiable via KaZaA.  Verizon, is resisting.  The RIAA would presumably use this information to force Verizon to deny service to the individual as well as sue them for civil penalties.  It would also allow them, if the NET Act is involked, to send this person to jail as a felon.  Obviously, the RIAA wants to use this case as a demonstration to the rest of us that they are in control.

For at least a couple of decades we've been copyrighting software, and now I realize that I don't understand why we do. Talking with Doc Searls last night, who is a master of analogy, we kind of agreed that perhaps there is no suitable analogy for software, that software is a unique thing unto itself.

First: Yes, software is unique. I don't want to go too deeply into that though as that's a very, very long story to do it truly correctly.

A follow-up to Damn DRM!, in which I refused to buy a book explicitly because of DRM issues: Rob Tsuk suggested in a comment that I try the Palm version of "A Fire Upon The Deep", as there is a Windows-(and Mac-)based reader available, which probably wouldn't have the licensing provisions I objected to.

I have tried this, and it worked. I was worried that the PC-based reader might not read encrypted content, but it does. And the EULA was quite standard, so no objections. I ordered A Fire Upon the Deep: Special eBook edition from Peanut Press, and it's working fine. I haven't gotten past the prolog yet, so I don't yet know if it was worth it, but I'll post a follow-up.

Untitled markpasc post:

Hint for Radio IM: deHTMLize an item with string.htmlToEmail.

A few hints and tips regarding coding and decoding in tcp.im:

Both AIM and Jabber have the ability to send HTML messages on the network, as do many of the other IM systems. (All that I know of can send formatted text, I don't know that they are all HTML as opposed to, say, RTF.) However, they are almost completely different. AIM sends half-assed, crappy HTML without close tags, inconsistent capatalization, etc. Jabber strictly requires compliant XHTML, or you'll ruin the whole connection.

With the (impending) release of tcp.im to the general public, this marks a transition of my Jabber only feed.

If you are reading this feed solely to watch the status of the Jabber work as it goes public, you can unsubscribe now; it's done.

I will continue to blog interesting things people do with Jabber in Radio and any further Jabber-specific work I do, if any.

Heads-up, some time in the next few hours (Murphy-willing) we're going to release tcp.im, which allows Radio and Frontier to be an instant messaging client or server (either can be either). It was a collaboration between Eric Soroos, Jeremy Bowers and myself; with Jake Savin doing the close. There may be some bugs and more docs to write over the next few days. Should be final on Monday.

Excellent.

tcp.im essentially exposes a reasonable amount of the intersection of the capabilities of AIM and Jabber, with an eye towards easily incorporating anything else that wants to play. So in technical terms, the framework is not necessarily terribly capable. But because of the cross-IM-platform nature of the code, it's gonna have a lot of juice.