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.
- 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.
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!