Kynetx Network Service, or KNS, modifies a user's Web page using Javascript. The ability to customize pages in the browser is a powerful capability, but it goes well beyond that by allowing data from multiple sources, even other Web pages, to be used as part of that customization. Sure we can change change colors, fonts, and layout, but we can also mashup Web sites to produce completely new experiences.

Described as I have, KNS is not unlike Greasemonkey, a popular plug-in for Firefox that allows user scripts to modify Web pages. In fact, in a recent post Paul Madsen discussed the KNS/Greasemonkey connection. Consequently, I thought a comparison of KNS and Greasemonkey would be in order. Note that I'm not a Greasemonkey expert, but I happen to be the world's foremost authority on KNS. :-)

Like the Web, KNS is a hybrid cloud and client solution. Greasemonkey is a client only solution, although it can, of course, reference data in the cloud. This has a number of positive consequences:

• Like any good cloud-based application, Kynetx apps are available and work consistently on any machine you use.
• Referenced data sources can be easily cached and proxied. This offers opportunities to increase performance and ease of use.
• Updates happen automatically as the servers are updated, like any cloud service. For example, recently Google started experimenting with AJAX search result pages which required updating scripts that augment Google. We changed some things on the server and users saw the updates immediately.
• Increased security. As an example, a malicious KNS app can be disabled on the server saving all users from the effects.
• Auditing and analytics are possible. Kynetx can audit apps for suspicious patterns and provide easy-to-understand reports about app privacy and security policies and activities. Server-side analytics give developers usage data on their cards without compromising individual privacy.
• We can track when the actions (ruleset) associated with a particular card change and warn the user.

KNS is controlled by a domain-specific language: KRL (Kynetx Rule Language). Greasemonkey uses raw Javascript.

• KRL provides developers with an easy way to create apps that work across browsers and operating systems. All of the details about working in Firefox or IE are abstracted away.
• KRL provides developers with a powerful lever for quickly developing apps. Augmenting search result pages, for example, is a simple action that replaces dozens of lines of Javascript.
• The abstractions of KRL allow Kynetx to respond to changes in browsers, Javascript, and Web sites with updated interpreters or runtime libraries to address the changes without developers having to change their apps.
• People who would never develop Javascript programs have successfully developed Kynetx apps.
• When the going gets tough, like any good domain specific language, KRL let's you jump out into raw Javascript to make up for holes in the language. As this happens, we'll incorporate commonly used patterns into KRL, making it more powerful.

KNS is based on Information Cards. Greasemonkey scripts are not associated with any particular identity system. We call Kynetx action cards "KIX".

• Information cards are tied to a specific action. Because of the security model of information cards, the KRL ruleset associated with a particular card cannot be changed. Thus, when a user gets a KIX, they can be assured that the actions associated with it are the ones the developer intended and haven't been replaced by a malicious program.
• The converse of the last point is that if someone creates a malicious app, it has a specific identity that cannot be hidden or changed. KIX can be rated, reviewed, and analyzed based on a non-mutable identifier.
• The information card selector provide a nice user interface for installing, controlling, managing, and deleting KIX and their associated actions.
• While KIX do not yet support in-card claims (personally identifying data), when they do, access to that data will be via the well-thought out and "socially tested" information card ceremony putting users squarely in control and mindful of what personal data they're releasing to make a Kynetx app work.

For the moment, KNS is simply placing tags on pages ('ala Greasemonkey 0.3) rather than executing scripts in a sandbox ('ala Greasemonkey 0.5). The later model is clearly superior from a security standpoint and would also give KNS performance advantages over it's current execution model. That's where we're headed. Still, because of mitigating design in our architecture, the current risk is small: we do not allow tags to be inserted on wildcard domains. This allows developers control on which domains tags are placed and thus protect user privacy and security.

Web augmentation is a fascinating place to be building technology because there are so many interesting problems to solve. Our goal for the KNS model for augmenting Web sites is to create a system that is general, safe, performant, easy to use, and easy to develop for. We're very close to opening up the doors for developers to start using KNS to create augmented Web experiences of their own. Stand by!