Pete Lacey’s Weblog

A few weeks ago I finished Seth Lloyd’s book Programming the Universe, which argues that the universe is one big quantum computer. Here is an especially apt paragraph:

… complexity is a key issue in engineering. How can we engineer complex systems that are still robust in their behavior? The maxim we teach engineering undergraduates at MIT goes by the acronym KISS: Keep It Simple, Stupid! But what if the system you’re engineering is itself complex, like an airplane? …. One promising technique for engineering complex systems is known as axiomatic design. …. The idea of axiomatic design is to minimize the information content of the engineered system while maintaining its ability to carry out its functional requirements. Properly applied, axiomatic design results in airplanes, software, and toasters all just complex enough, and no more, to attain their design goals. Axiomatic design minimizes the effective complexity of the engineered system while maintaining the system’s effectiveness. Keep It Simple, Stupid—but not too simple.

And if you follow the link I supplied for axiomatic design, you find this intriguing statement:

The Information Axiom requires the minimization of the information content. According to the Information Axiom, the design that has the least information content is the best design.

Take away from this what you want.

Oh, and a capsule book review: Interesting idea, could’ve been better argued.

A little clarity around my previous post of transport-level security and message-level security.

I’ll first note that neither security approach is bound to the REST or SOAP style of component interaction. There is nothing in REST that mandates transport-level security or precludes message-level security. The same is true of SOAP. That said, secure systems implemented via REST or SOAP today tend to leverage the transport-level security mechanisms inherent to HTTP/HTTPS, and a few SOAP systems leverage some subset of WS-Security. But lets take the terms “REST” and “SOAP” off the table, they’re immaterial here.

The point of the previous post was that transport-level security (TLS) and message-level security (MLS) (in their purest forms) are equally credible, and the existence of MLS does not suddenly make TLS worthless. Nor is MLS any more or less better suited to addressing the problems of phishing, identity theft, or trust than TLS is. I do contend that TLS, in the form of SSL/TLS, while not perfect, is mature and of continued value. I further contend that MLS, in the form of WSS, is also imperfect and comparatively immature — not bad, mind you, just young. MLS security provides value that TLS doesn’t, and I’m glad we have it, but the inverse is also true.

But the biggest point I need to make is that the concerns addressed by TLS and MLS are only a small subset of the total number of security concerns. Furthermore, the total universe of security threats, from organized crime and information warfare to shoulder surfing and lost laptops, is far larger than the total universe of available countermeasures, which in turn is larger than the authentication, authorization, encryption, and integrity solutions enabled by TLS and MLS. You cannot secure against every conceivable threat. Organizations have finite resources, and thus must apply threat mitigation under the rubric of risk analysis. When designing a new system, security considerations should be held paramount. A proper risk analysis in the context of the application’s function, design, and user-base must be performed, and it may indicate, for instance, that TLS or MLS or some aspects of both should be used (again, both techniques have value). But the application design must also account for a seemingly infinite number of other attack vectors (XSS, SQL injection, buffer overflows, etc.), and a proper risk analysis is the only means to determine how many resources to allocate to each conceivable threat. And, of course, security concerns extend beyond the application boundaries to securing the physical data, securing private keys, password management practices, network security, physical security, and on and on and on.

As an aside, I find the The eBankingSecurity PDF referenced in Tim’s Web Application Security post of only marginal value. It outlines the many ways that malicious code can steal user credentials or make an untrustworthy site look trustworthy. The fundamental premise is that if a client machine is compromised, then the game’s up. This is very true, but what to do about it? The paper doesn’t say. And therein lies the flaw, there’s no risk assessment or recommendations for how to proceed. It’s good that banks have their consciousness raised and are made aware that some of the security features they’ve come up with are not 100% effective. But what should they do? Fold up shop and go home?

And “the never-mentioned weakness of SSL” is anything but. It requires that the black hats rewrite your host file and install a trusted root certificate of their own making. This is not a weakness of SSL, it’s a weakness of any system that is based on trust, which, ultimately, they all are, including WSS and PGP. I fail to see how any TLS or MLS system can protect against this. I mean once your machine is 0wn3d, its 0wn3d. It’s up to the vendors of operating systems and browsers and security software to make it as difficult as possible for this to happen. But ultimately it’s up to the user to be educated enough to keep his or her machine secure.

Over in the comments for Tim Bray’s “S for Simple” post and again over on his personal blog, Gunnar Peterson claims that the standard REST security approach is inadequate and that something like WS-Security is required for any truly secure architecture. Gunnar has a shoot-from-the-hip tone, but we’ve communicated briefly via email and he states that he would like to buy into the REST vision if only security was adequately addressed. So lets compare and contrast approaches.

The standard RESTful security approach is, of course, HTTP Basic or HTTP Digest or SSL certificate-based mutual authentication for propagating identity credentials (the actual act of authentication and authorization being the purview of the server) and SSL for data integrity (digital signatures) and data protection (encryption). Gunnar notes that these technologies were state of the art in 1995, with the implication they are no longer sufficient for meeting the security needs of the 21st century. This is an example of what I call the “Gilligan, you can’t fly” argument; that is stating that something can’t be done even as somebody else is doing it. The fact is that billions of dollars of worth of business is conducted every year over because of SSL.

SSL has shown itself to be amazingly versatile. Not only do I do my online banking and shopping over SSL, I VPN into the office over SSL and check and send email over SSL. That the first version of SSL is now some 11 years old is a boon. In fact, that’s exactly what I want in a standard; stability for the long term. More so in a security related standard, as that provides the time to shake out any bugs and ambiguities. Of course, SSL hasn’t been static; there’s been SSL 2, and SSL 3, and now TLS 1.1. In fact, given the relative youth of WS-Security, what do you think the odds are that it is immune to attack and that all of the implementations are free from bugs? Close to zero I would imagine. That’s not a slam on WSS–all standards are young once–but praise for the tried and true.

Gunnar notes that the world has moved past SSL etc., and cites as examples identity theft, phishing/pharming, and malware. But these security threats are completely orhtogonal to the security concerns SSL addresses. Ditto, I might add, WS-Security. Both of these standards address identity propagation, message encryption, and message integrity only, and neither will protect you from the threats just mentioned. Security is a BIG subject and the areas covered by SSL and WS-Security are just one small part of it. We also need good practices around securing persisted data (and what data to persist); education to prevent social engineering attacks; properly designed operating systems that won’t run anything with a .exe extension or run needless services; developers who are cognizant of buffer overflows, SQL injection, and cross-site scripting attacks; properly managed perimeter defenses; and so on and so on.

Gunnar then notes that HTTP Basic is not secure, and that, of course, is absolutely true. The password passed via HTTP Basic is base64 encoded, which is practically the same thing as being sent in clear text. In fact, it is the same thing, as encoding is not encryption. However, nobody is claiming otherwise. For those use cases where identity is all that’s required, then HTTP Basic is all that’s needed. For the larger number of use cases where credentials need to be encrypted, then use HTTP Basic in conjunction with SSL or use HTTP Digest or use SSL mutual auth. I’ll note that WSS is similar in design. The standard identity token is the Username token, the password element of which is sent in the clear by default. You can hash the password, but it should be noted that the recommendations specified in the Username Token Profile require that the server store the user’s password in clear text. Avoiding this requires an out-of-band negotiation that cannot be specified using WS-SecurityPolicy.

Gunnar next takes SSL to task for providing a great big hole through the firewall. I have to confess that I don’t understand this point. Sure, SSL encrypts the content of the communication channel, but that’s what it’s supposed to do, and, as already noted, it seems to work pretty well. Furthermore, when using HTTPS, communication travels through a completely different port than HTTP. A port that can be monitored more carefully. With WSS, not only do we have SOAP tunneling over HTTP, we have encrypted messages in the SOAP envelope. I don’t see how that could be better. In fact, the SOAP tunneling alone is a fairly significant security hole. Requiring that companies invest in new infrastructure to secure against threats that bypasses all the stuff they’ve already deployed. Furthermore, it’s not like the SSL connection is being terminated on the application server, more likely than not there is some intermediary up front that terminates the session, e.g. an SSL accelerator or proxy server. And before you can say, “ah hah,” know that the same is true for WSS. A properly architected SOA security solution addresses security concerns in “the cloud” using either an XML gateway or a web services management solution. (An article I wrote on this subject goes into more detail.) In other words, done right, the message received by a WSS-secured endpoint is also in the clear.

Gunnar goes on to note that the point-to-point security offered by SSL is an interoperability and simplicity nightmare. I don’t get this point either. Not only is SSL well understood, broadly implemented, and properly constrained, it is quite evidently not an impediment to interoperability as I can securely connect to anyone on the planet right now, so long as they let me. In contrast, not only is SOAP well known for its continuing interoperability headaches, they show up in spades with WSS. Just for starters, how do I know that a SOAP endpoint is secured in any way? You can’t tell from the URL and there’s no handshake with which client and server can negotiate security. If a service is secure, in what way? Do I need to provide credentials? What kind? A Username token? (hashed?) A SAML token? (how much of SAML do you support?) Or an encoded certificate? Is encryption used? The whole message or just some elements? Do I need to sign it? You can say that all of this is addressed by WS-SecurityPolicy, but WS-SecurityPolicy isn’t baked yet nor is anyone using it. And, as we’ve just shown, it’s not comprehensive. Furthermore, we have the implementation details. Is, say, BEA’s WSS implementation really 100% compatible with Microsoft’s, and is that 100% compatible with IBM’s, and is that 100% compatible with AmberPoint’s, and so on down the line. I don’t know the answer to this (since there doesn’t seem to be any instances of WSS encryption/DSig use in the wild [read the comments too]), but I strongly suspect not. To demonstrate, please retrieve this encrypted representation of a common greeting. Now, I don’t know what browser you’re using (if any) or what OS or anything. And you don’t know what encryption algorithm I’m using or what version of SSL etc. However, even though we have no a priori information about each other, I am absolutely positive that you were able to retrieve that resource. What can be simpler than that?

With all of that behind us, I can get on to what seems to be Gunnar’s main point and the only significant difference (outside of the whole simplicity and interoperability thing) between SSL and WS-Security. And that is that SSL provides transport level, point-to-point security while WSS provides message level, end-to-end security. That’s true, but that doesn’t provide WSS with magical security powers, it just solves a different problem. Nor does it relegate SSL to the scrap heap of history. SSL is not a security panacea–nothing is, but it does what it is does very well. Regardless, there is nothing in REST that prohibits the use of message-level encryption, though the mechanism–should it be needed–would need to be spec’d out.

I’m not dismissing WSS, it’s a perfectly adequate specification for what it does (though it requires the WS-I Security Profile to introduce enough constraints to provide a reasonable chance of interoperability). But the value of message level security should still be questioned. For one thing, what’s the business case? If message-level encryption is so important, why isn’t anyone using it? When Burton Group queried its clients as to their use of WSS, it was found that the only use was to pass identity tokens over HTTPS. When I was working at Systinet (now HP) I vividly recall the WASP (not Systinet Server for Java) product manager spitting nails because his team had just spent six months implementing WSS at our customer’s request and no one–not even those who requested the feature–was using it. Also, this is not the first time message level security has been proposed. When I was working at Netscape back in 1997 I spent a fair amount of my time advocating for S/MIME. Now, nearly ten years later, how many people are using S/MIME to secure their email? And how many are using SSL? Exactly.

In summary, RESTful security, that is SSL and HTTP Basic/Digest, provides a stable and mature solution that addresses transport level credential passing, encryption, and integrity. It is ubiquitous, simple, and interoperable. It requires no out-of-band contract negotiation or a priori knowledge of how the resource (okay, service) is secured. It leverages your existing security infrastructure and expertise. And it addresses 99% of the use cases you are likely to encounter. SSL does not support message level security, and if that’s a requirement, then leveraging SOAP and WSS makes sense. Recall, though, that this is not a limitation of REST per se, though it is left as an exercise to the reader. SSL is not perfect and it does not address all security requirements, but nothing does or can.

Hope that helps.

Wasn’t planning on posting again today, but this is beyond funny (to geeks).

Update:  And this too.  Move over Google, it’s time to ask Ms. Dewey.

Leonard is looking for a formal definition of SOA. My colleague, Anne Thomas Manes, is a thought leader on this subject, and Burton Group clients and the industry as a whole tend to line up behind her definitions. I’ll share them here:

Service oriented architecture (SOA) is a software design discipline in which application and infrastructure functionality are implemented as shared, reusable services.

SOA is more about design and behavior than technology.

SOA is something an organization does—not something it buys or something it builds.

Admittedly, this is all kinda loosey-goosey and can describe most anything. In fact, a core tenet of Burton Group’s stance is that SOA is technology agnostic: you can create a SOA with CORBA or RMI or DCOM or SOAP or, some say, REST. However, the first definition of SOA given above and the first word in “service-oriented architecture” demand a definition of what a service actually is. People might argue this, but the only reasonable definition of a service is a network available collection of related operations. And an “operation” is an action (function/method) offered by the service that takes in a message or parameter list and generally returns some response. To be clear, however, while you can conceivably create a SOA using, say, RMI, in reality SOAP web services is both the recommended and assumed underlying technology.

Plugging this definition of a service into the SOA definition gives us:

Service oriented architecture (SOA) is a software design discipline in which application and infrastructure functionality are implemented as shared, reusable network available, collections of operations.

And this is where I part company with those that think that REST can be used as the underlying technology of a SOA. Sure, in the sense that SOA implies changes to how you think about designing applications or modifications to your SDLC, then fine. But a resource is not a service. A resource does not have arbitrary operations (that, by the way, have to be specified somewhere in the incoming message—and not in the HTTP headers, because SOAP is supposed to be transport agnostic). Stefan Tilkov put this into brilliant perspective when he demonstrated the differences between how people think about resources and how they think about services.

From this, we can also put to rest the notion that the choice between SOAP and REST is an implementation detail. How REST systems are architected at the resource level is fundamentally different from SOAP. And how REST leverages HTTP (URIs, response codes, caching) is fundamentally different from how SOAP leverages HTTP (as a tunnel).

Back to Leonard then. You can drop the name “Message-Oriented Architecture.” It is, as you noted, too similar to message-oriented middleware and it doesn’t properly reflect that other architecture. The name “SOA” works fine, so long as the “S” is defined. Further, I was being generous when I said that a service accepts either a message or a parameter list. While sending messages is considered best practice, today’s tools and today’s programmers still lean towards sending serialized objects (though serialized as document/literal messages).

ROA, while it doesn’t quite roll off the tongue, is also fine.

Leonard asks “Is it useful to distinguish between the typical robotic SOAP/WSDL interfaces autogenerated from Java or .NET code at the touch of a button, and the in potentia SOAP architecture that can be anything, even RESTful?”

Yes. Yes. Yes.

Stefan and Sam have both noted that you can craft a SOAP message with vi, and that SOAP can be considered orthogonal to WSDL, and that one can leverage the SOAP envelope while ignoring all the other baggage. This is technically all true. But you cannot ignore how SOAP and SOA are being sold and practiced. I’ve been briefed by SOA vendors of all stripes. I’ve sat in vendor sales calls with my customers. Heck, I have myself advocated a web services-based SOA. And this version of SOA assumes SOAP and WSDL and UDDI, and XML Schema, and WS-Whatever, and web service management tools, and enterprise service busses, and web service platforms, and so on ad nauseum. I don’t want to harp on this, but it’s wishful thinking at best and disingenuous at worse to assume that SOAP and SOA can be divorced from this reality.

And to answer the final question about how to categorize those not quite RESTful, HTTP+POX services so commonly found out there. They should be classified as aberrations, as devoid of architecture, and as an example of how not to do things (while acknowledging they work). I direct you once again to Duncan Cragg’s coinage of the term STREST.

It’s time to reawaken this blog, and the current POX/REST/SOAP thing is as good a reason as any. Everyone has something good to say, and I have comments for everybody.

Leonard Richardson kicked it off while ruminating about the forthcoming book on REST that he’s writing in collaboration with Sam Ruby. In it he notes that the HTTP+POX services made evident by Web APIs such as those from Flickr and del.icio.us are not completely without architecture, but lean towards the RPC style of SOAP. I contend that this is not true. That these services have an accidental RPC-like architecture that comes from trying to avoid SOAP while still being muddled in traditional RMI/CORBA style networked application development. While this may be the simplest thing that possibly works, they do themselves no favors by avoiding both REST and SOAP. This is what Duncan Cragg calls Service-Trampled REST (STREST). Leonard makes the great point that most browser-oriented web apps are not RESTful either.

Leonard goes on to note that the PUT and DELETE HTTP verbs are absolutely required by REST, because without them one is tempted to overload POST and put actions in the URL. In practice, this is somewhat true. However, you can’t make the argument that REST is all about the HTTP verbs without conflating the two. REST is informed by HTTP and vice-versa, but they are not synonyms. Tim Bray is correct, REST requires a means of safely retrieving a resource’s representation (Get) and a means of changing the state of that resource (Post), PUT and Delete are nice to haves. Just PUT really, as no one really deletes anything. I would argue that if all of WEBDAV’s methods (COPY, MOVE, LOCK, etc.) were part of the original HTTP specification, Leonard’s line of reasoning would mandate them too. That said, it is extremely convenient to be able to distinguish POST from PUT.

The ensuing discussion addressed most of the rest of Leonard’s post, and I’ll get to them in a second. I’ll answer one more question that Leonard raised, however. For all intents and purposes, the term “web services” has been lost to anything but SOAP and the rest of the WS stack. SOA is an architecture that (tends to) leverage web services. Contrary to what some claim, a SOA cannot be using REST, simply because not all resources are services.

Sam picks up the ball by implying that the line between SOAP and POX (not REST, POX) is finer than one would think. I’m fine with that, but that’s likely because both POX and SOAP are a mistake. SOAP for all the reasons that Steve Loughran pointed out (and them some; links anyone) and HTTP+POX because it is just a simpler RPC mechanism.

Things really get ugly when Sanjiva Weerawarana (of WS02 and Axis2) weighs in. Sanjiva gets it all wrong, but not necessarily entirely from a technical point of view. From my vantage point as a Burton Group consultant, I know is being peddled to enterprise customers, and it’s not some idealized notion of “SOAP is whatever you want it to be.” It’s the whole butt-ugly, can-never-be-restful, WSDL 1.1, WS-HairBall stack.

But on to the details. Mark Baker correctly brings Sanjiva to task for the bulk of his argument. Summary: SOAP is not whatever you want it to be; there are expectations that both communicating parties interpret a message identically. To think otherwise is ludicrous. To believe that a developer coding to Microsoft’s WSE expects BEA’s SOAP stack to freely interpret the intent of his message is just wrong. In Stefan Tilkov’s otherwise excellent response, this is where he gets things just a bit mixed up. Yes, the SOAP envelope all by itself can be a good thing, but SOAP is more than an envelope. You can’t ignore how SOAP is packaged and sold, how it is specified, and how it is implemented. SOAP, despite everyone’s best efforts, is still a remote object protocol, and somewhere in the message, whether it be in the SOAP Body, in a WS-Addressing header, the outer element of a wrapped doc/lit message, or in the SOAPAction HTTP Header, is the method to invoke on the remote object. And, remember, to the business developer, SOAP is also WSDL, and a mish-mash of encoding styles and serializations, and impenetrable XML Schema, and tModels, and vendor wars, and ESBs, and shoddy specifications, and on, and on, and on.

Sanjiva then goes on to make the increasingly common claim that SOAP is only useful when you want to solve enterprisey problems like reliable messaging and end-to-end security. This is interesting in a number of respects.

1. The number of people using WS-ReliableMessaging in production today totals zero.
2. The number of people using all of WS-Security (and not just username tokens) approaches zero
3. These numbers hold true for WS-this-that-and-the-other-thing too.

Zeroing in on WS-Security we can note a few other things. To argue that securing the message (admittedly handy, but handled by XML Digital Signatures and XML Encryption, and only complicated by WSS) and not the protocol is of absolute importance, ignores the fact that we’ve been building secure applications without this ability since time immemorial. It further ignores that a sound architecture does not ask the endpoint to do the decryption, but that the decryption is done upstream in a web service intermediary of some sort, possibly one that precedes other intermediaries, thus negating this argument entirely.

In short, if SOAP is only useful when used in conjunction with the advanced WS framework, then, for the time being at least, SOAP isn’t useful at all. With the exception of WSS, no other specification has been fully ratified. And to repeat, this is not what’s being sold to the Global 2000 customer. They are being sold SOAP and WS-* from top to bottom. Not, REST when you can and SOAP when you need to.

And, so it doesn’t look like I’m copping out, I’ll answer the next question, “So how then do we meet these enterprise goals of reliability, security, pub/sub, etc.?” The answer varies depending on the need. I suspect that we don’t need anything new to cover what WSS covers, though having it may open up some new opportunities. For the relatively small number of apps that need or desire reliable messaging, pub/sub, etc., then I would say use the technologies that exist to fit that need: MQ-Series, TIBCO Rendezvous, etc. Not everything has to be an HTTP/REST app. (Note, pub/sub is already RESTful in its own way: write a message, read message - nice. Also note, that three of the four main HTTP verbs are reliable enough; GET, PUT, & DELETE.)

And for the record, I do not believe that REST services are currently defined well enough. I think having a standard envelope would be kinda useful, HTML has one. I think it would useful to put a stake in the ground and say XML is the standard for representation. I think that REST needs a better name.

It’s good to be back.

Somebody out there recently sent me an email regarding the Postfix+Dovecot+etc. HOWTO. Unfortunately, it seems that I’ve accidententally deleted your message. To give you a clue as to whether it’s you or not, you mentioned Phamm as an alternative to Jamm. I remember that you also had some other insights to share, but don’t remember what. If you see this, please resend or comment below.

As it turns out, I noticed Phamm a long time ago, when it was much less mature. I even installed it, but it wasn’t ready for primetime. And even though it seems to have grown up in the meantime, I probably won’t go forward with it for the simple reason that I plan to write my own version in Ruby on Rails. And that for no other reason than I want to. Please, though, remind me of what else it was you had to say.

My PowerBook came back from Apple on Friday (I had put it in the mail on Monday, so not bad), and I’ve been trying to make it mine again since opening the box on Saturday.

The machine came back fixed. One of the problems it had (has), was that the battery would go from full to empty in about 20 minutes. Apple doesn’t replace batteries, even with their extended warranty, though they agreed that the “battery no longer has the capacity to function at a level necessary for optimum operation of your unit.” Apparently, the fact that all batteries suck means that PowerBook/iBook users have to shell out $130.00 every 12 - 24 months. Which is what I did last night after the following experience.

I had to put my Mac down to tend to the toddler who had just woken up from his nap. Several hours later I returned to find the PB screen dark as expected. I hit return to wake it up, but there was no response. I hit shift. I clicked the mouse. Nothing. I pushed power, and it booted up. Hmmm, why did it power down instead of just going to sleep?

Here’s a clue: when the PB finally booted to the desktop, OS X informed me that my computer’s clock was set to 1969 and this might cause problems for certain applications—which it did. I reset the clock, rebooted, and now all is well.

Here’s my guess as to what happened. The PB got separated from wall power (it happens, the connection is loose courtesy of the aforementioned toddler who finds no end of excitement making the little light go on and off), then the battery ran down before the machine had a chance to go to sleep, the backup battery (which keeps the clock running and provides just enough juice to allow you to swap batteries while working) soldiered on for a minute longer before it too gave up the ghost. No electrons, no computer—and no power to drive the PRAM (the Mac equivalent of a PC’s CMOS). Lets hope this is it, anyway. I don’t want to have to replace the backup battery as well.

While I’ll never know exactly what the repair department did to bring my Mac back to life, one thing they did was replace the hard drive. Oddly enough, they didn’t put it back to a fresh-from-the-factory state, instead there was already a user named “a” created on the machine. That, and they installed OS X 10.3.4. I suppose it’s fair not to install Tiger, they don’t know I own it, but why not 10.3.9. Maybe ’cause it sucked.

To reclaim my Mac I first had to access my secured WiFi network. I couldn’t remember my password, and I had to look it up on my wife’s iBook. Then I installed Tiger on the PB using the “replace and install” option of the install media, and I installed Xcode too. Software Update informed me that I had a 130MB of updates to install as well, and then I had to download (forgot to back them up) and install all of the “little” apps I’ve paid for and can’t live without. To wit:

• LaunchBar. Spotlight before Spotlight was cool, and much more versatile.
• NewsFire. The “Angelina Jolie” of news readers. (hint: NewsFire keeps your subscription list in ~/Library/Preferences/org.xlife.NewsFire.plist)
• TextMate. A text editor for programmers.
• Skype. You know.

And some big apps too:

• Oxygen. A Java based XML editor with XML Schema and XQuery support.
• IntelliJ. An intuitive Java IDE. (I spent $500 dollars on this two years ago as Eclipse on the Mac sucked at the time, but now I never use it.)
• iLife.
• PhotoShop.

And even though I own a copy of MS Office, I elected this time to go without, and installed NeoOffice/J. I’ll let you know how this turns out. It seems to work, but it takes a full fifteen Mississippis to start up.

A note about mail.app. Maill.app may be ugly, but the junk mail filter is fantastic. I’ve barely trained it at all, and it’s flagging like 99% of the junk that comes my way. Someday, though, I’ll have to set up server side filtering on my mail server.

I copied my working files over from back up, my Safari bookmarks, and Keychain too. I had to reauthorize iTunes to play my ITMS music. I’ll have to call Apple soon and have them deauthorize the previous incarnation of this laptop. What else? I disabled Dashboard, removed everything from the Dock excpet Finder, set LaunchBar to start at login, paired-up my BlueTooth phone, restored my wall paper, ran through all the system prefs, and now my Mac is nearly mine again.

I’ll need to reinstall Ruby on Rails and ActiveLDAP for a project I’m working on. Someday I’ll have to recompile and re-install PostgreSQL, but I’m not using it right now. There were a handful of command line utilities I used Fink to install, but I can’t remember what they were. When I do, I’ll have to replace them too. Oh, and I have to set up the printer.

There’s probably more, but for now I’m home again.

Over the last two days I’ve been innundated with comment spam. Furthermore, there’s been a fair bit of discussion amongst bloggers regarding the splog phenomenon. Here are a couple of thoughts on the subject, though nothing earth shattering.

Of most interest is the timing of the spam I received. I had let this blog go dormant for about three months, and during that time did not get a single item of comment spam. However, when I started posting again a couple of days ago, the spam started flooding in. What this tells me is that the spammers are listening to Technorati or some such and spamming only active blogs. As an expermient I’ve turned off my Technorati and Ping-o-matic updates. We’ll see what happens.

Turning off the blog search engine pings doesn’t upset me much. Most traffic is driven to my site from Google, and the Technorati search is so laden down with splogs that it is quite literally useless. I just typed in the name of my town to see who might be blogging about events here. Of the 20 entries Technorati displayed on the first results page 17 were from splogs. Useless. It would be interesting to know how Google filters out the noise.

Speaking of Google, can’t we get some relief from that corner, something more than the rel=”nofollow” attribute. All this comment spam and referrer spam is there for one reason: to game the Google page rank system. So long as Google enables spammers to monetize a link, then there will be spam. And clever ideas like Internet Stamps isn’t gonna help. In a two year old post, Mark Pilgrim explains why.

Despite the above, here’s a potential solution that’s only occurring to me now, so bear with me. It’s very similar to your standard public key authentication technology, but instead of a chain of trust (with Verisign or the U.S. Post Office at the top), it’s a web of trust ala PGP’s system. In this system, all blogging server software (WordPress, MovableType, etc.) automatically defaults to moderating comments. All news aggregators and browers have a button for generating a digital identity. Every time you comment on a blog you send along your ID by digitally signing your text. At some point, possibly the same inflection point that causes you to add someone to your blogroll, you can “trust” this commenter. Now here’s the good bit, the Web 2.0 bit, news aggregators/browsers can subscribe to the trust lists of others and add them to their own trusts list, therefore easily expanding your web of trust.

Needs more work.

I’ve got to me more consientious about blogging.