Certain aspects of Web technology continue to surprise me, no matter how well I think I understand them. Intermediation is one of them, and it comes in a couple of different flavors.

First, there"s protocol intermediation. Like all Internet protocols, HTTP can be proxied and often is. Enterprises deploy centralized proxies for caching, monitoring, and control. Web proxies can also run locally, and developers have long relied on them for debugging HTTP traffic.

Some adventurous civilians run proxies too, most often to strip ads from HTML pages. Rewriting HTML isn"t really protocol intermediation, though. Let"s call it content intermediation. This technique has been revitalized in recent months by the Firefox extension Greasemonkey. This ingenious gadget hosts scripts that spring to life for specific Web pages and interact with those pages" DOMs.

People are using Greasemonkey to do many things that have traditionally been done with proxies: blocking ads, adding or modifying links, adjusting styles. But Greasemonkey can do more than tweak the DOM. Like bookmarklets, it can also manipulate the JavaScript objects in the page. And in the case of so-called AJAX (Asynchronous JavaScript and XML) applications such as Google Maps and Gmail, those objects are amazingly potent.

Creating waypoints and routes with your own GPS data, as I discussed last month, is one stunning way to use Greasemonkey. Adding persistent search folders to Gmail is another. That trick, accomplishable in 600 lines of JavaScript, weaves a major new feature into Gmail so cleanly that you"d never know it wasn"t part of the native application.

Protocol and content intermediaries are equally vital to the long-term success of the Web as a platform, but their implementation styles and cultural traditions differ in ways that have tended to obscure their natural synergy.

Protocol intermediaries historically lived at the center of the network, where they enforced policy in an application-independent way. Content intermediaries lived at the edge of the network, where they provided application-specific customization.

These are generalizations, but the distinction between protocol and content intermediation used to be pretty clear. Not any more. As protocols, documents, and UI descriptions all converge on XML, the distinction has begun to blur. Policy that was once enforced on the wire can now be patrolled on the desktop. Likewise, customizations added on the desktop can now be inserted on the wire.

Consider a purchase order represented as an XML document and governed by a policy that requires schema validity. We can enforce that policy either on the wire or on the desktop. One way buys you application-independent consistency. The other way lets you tailor your users" interactive experiences. These are complementary strategies.

Here"s a less familiar but equally compelling scenario: You"re leasing a Web-based application, it lacks a feature you need, and the developer won"t cough it up in a timely manner. Because the application"s user interface is delivered through the Web as XML packets alongside the protocol and data packets, you can tweak it globally or locally. Same benefits, same synergy.

Both styles of intermediation are here to stay. Eventually it"ll be hard to tell them apart.