The Future of Computing
Data-Centric Computing & Active Data Files

No more viruses, crashes, data loss or piracy


Since we used thermionic valves and punch-cards, all computers have worked the same way. You read about it in the textbooks. You have a processor that runs an Operating System. It may be embedded on a chip, or a big fat multi-purpose one like Windows, the Mac OS, or Linux. This OS offers a friendly environment upon which to sit your chosen applications (Word, Excel, Media Player). These applications all operate upon data files.

The OS is really a special sort of application, so you have just two sorts of programs. Applications are 'active'. Click on them and they do things to other files, connect you to the net, play your music. Data files are dumb. Passive. They can do nothing. Click on them and the best that you can hope for is that your OS will launch a suitable application to allow you to work on them.

Data files do actually have more than one component part. Almost all of them are made up of Data and Metadata. Metadata has become popular since people started putting Meta-Tags on their webpages, and metadata appeared as a core feature of XML. Metadata is data about data. Your data is your word-processed text, your metadata probably just a description of the type of file, the application that created it, and when it was last changed. Open a Word file in Notepad and you'll see the Metadata, largely as gobbledegook, surrounding the data.

This is application-centric computing, based around active applications working on passive data files. In the future all of this will change. Welcome to the world of the Active Data File, or ADF.

To make this easier, I've divided ADFs into 3 type, ADF1s, ADF2s, and ADF3s. There's a special type of ADF1 called an ADF1a, but we'll come to that when we need to.

First, what's an ADF? Well, its a data file that isn't passive. Its a data file that does things. We'll start with an ADF1 and I'll explain it by comparing it to an ordinary passive data file.

If you try to open a passive data file, your application or OS will look to see if it is compatible-the data all laid out properly, and the file undamaged. If it is, the file will be opened. The data file has no say in who opens it. If you want to protect your data file, then you can encrypt it, but the data file cannot ask you for a password, nor can it unencrypt itself. All this has to happen in a suitable application, a program you own and have installed on your PC, or perhaps a distant web-based application that you subscribe to.

Now lets look at what happens when you click on an ADF1. First, the ADF1 is not a passive data file, but an application. All ADFs are applications. They store their data and metadata, encrypted, inside them, like the kernel of a walnut. Inside, the soft, vulnerable data, surrounding it the protective shell of the 'caretaker' application. Click on an ADF1 and the caretaker program runs. This is a program that is set up by the person who created the ADF1 file, say the company that sold you a movie as a file on a DVD, or a fellow employee who is showing you a draft of their project.

The caretaker program can be set to do different things. It can throw up a dialogue box and ask for a password, it can check the date via a time-server, the PC it is sitting on, the unique MAC address of your networking hardware, your IP connection, how many times you have opened the file before, or your thumbprint. It can even 'phone home' across the internet and ask a third party if it should open for you. It compares its current circumstances with pre-programmed variables set up by the person who created it. If you match the criteria, it will then decrypt its contents, and insert them into your application.

The ADF1 then continues running. It can monitor what you do to the data that normally resides in it, and keep a log of any changes you make, and when you make them. This log is maintained within it as metadata. When you have finished with the file and close it, the data is re-encrypted, and re-inserted into the ADF1. The caretaker program can decide whether to allow you to save a copy anywhere else. It can allow you to only have one copy (by erasing itself at its old position when it has saved itself at a new position) and might wish to disable your application's copy and paste facilities whilst you are running it. It can also watch your system for snooper programs or viruses as it allows you to work with the data. If the caretaker program is set up to do so, it can report your use of the data online, log all of your activities on a distant server as well as within its own metadata, and even erase itself, if you are only allowed to use the data once.

The ADF1 is effectively self-aware. If it is copied, it can note discrepancies in its own personal log of where it has been, and refuse to operate. An example is a DVD file that will only operate on the embedded firmware of a player (rather than a PC) and only once. Alternatively, a DVD file may request online ratification of payment, and then play after checking the region it is in via the IP address of the user.

In all cases, the creator of the ADF1 file controls how the file is used after it leaves their physical control, even if they have no electronic connection to it. These details-the ADF1's 'mission criteria'-are inserted into it when it is originally created. All ADF1s are controlled throughout their existence by their original creator. This solves many copyright issues relating to the ownership and use of digital data.

As for cross-platform issues with current technology, an ADF1 may have an 'outer shell' formed from a Java applet. This would run on many platforms. The Java applet would look to the platform upon which the file found itself, and choose the appropriate caretaker program to run. Alternatively, the ADF1 may be designed to only work under a specific OS. For security, the caretaker program could choose to operate the ADF1 on a RAM-disk, or at a low level, to prevent OS-based elements from attempting to disrupt it.

E-Mail

E-mail is an example of a special type of ADF1. Call it an ADF1a. E-mail is not a data file, although it is passive (even if it contains a script, as the script must be run from an external application). E-mail is (like a data packet or a protocol), a string of data. Here's how ADFs apply to it.

Take your e-mail message and encrypt it. Wrap it inside an application, or an applet containing an application, and then embed this inside, or attach it to a blank message, with a script to run it. On arrival, the script runs the applet, which runs the caretaker application, which then decides whether you can read the message. If you can, it decrypts the message and places it inside the (apparently blank) body of the e-mail in your e-mail program. It retains control of this, records when you read it, and may not let you retain the text of it. It can also send a note of the e-mail's receipt in the background, perhaps refusing to allow you to read the e-mail until this response has been sent.

ADFs allow each and every data file to control how they are used, where they are used, and whom they are used by. Each ADF may be unique, containing an ID taken from their moment of creation, and identifying features of their initial creator. Rudimentary functionality can be built into an ADF1, so that it may be e-mailed to you as a legal form, which you fill in, and (when complete) it returns itself.

Unlike passive data files, ADFs negotiate their own use, and are 'self-aware' during operation, and cumulatively, from operation to operation.

ADF2 Files

ADF1s are clever, and have important implications for copyright owners and secure computing. Much of what an ADF1 has to do can be put together using current programming techniques, or you can buy a dedicated off-the-shelf pseudo-ADF solution like Spinware. Things become more interesting with ADF2 files.

An ADF2 not only contains its own caretaker application to negotiate its own use. It also contains its own application. This application is the only one that will run the data inside the ADF2, and it will only run if you meet the criteria laid down by the ADF2's original creator. The ADF2 application may be a DVD viewer, CD player, image viewer, text viewer, or full word processor. If the creator lets you, the ADF2's built-in application may allow you to change the data it contains, redrafting a document, say, or may simply allow you to view it.

When the ADF2 is created, as well as the data, the creator would choose the application to be packaged with it from a collection of 'parts' or 'functions'. The ADF2 creator program would accept plug-in suites of application parts from third-party vendors, that you could then go on to incorporate into your ADF2s before sending them out. So you may send your file out with an open source supplied viewer and a secure, encrypted file that only your friend could see when he typed in his password, or you could send it out similarly, but with an ADF2 application built from Microsoft-authored parts. The data would be just as secure if you wanted it to be.

ADF2s can allow you to view or alter themselves. They can also be 'fertile' or 'sterile'. A fertile ADF2 allows you to create new ADF1 or ADF2 files from within it. These may all be accessible only to you (and those whom you wish to view them) as their creator, or to you, your nominated users, and the original supplier of the fertile ADF2 software that allowed you to create them, one step down the hierarchy.

ADF2 files no longer require a user to own their own copies of specific applications on their computers, to be able to use files supplied to them. At any given time, you only use a small percentage of your application's features, so bundling an appropriate application feature-set with every file is not as crazy as it sounds. You can view a .doc file using a very small viewer application, for example. You don't need a resident copy of MS Office. And as before, a cross-platform outer-shell, maybe a Java applet, can choose whether to run the PC or Mac versions of your ADF2 application, when you click on your ADF2.

ADF3 Files

ADF3 files go further. They include not just the data and metadata, and the application, but a fully functioning OS too. Now don't panic. That isn't as crazy as it seems either. Windows may be a huge hulking brute of an OS, but there are plenty of much smaller ones out there, like QNX, which fits an OS and a browser on a floppy disk. You only include the OS and application functionality feature-set that your file needs.

ADF3s offer more security. An ADF3 is a data file that partitions its own space, or runs in a RAM-disk on bare hardware, avoiding any installed OS. It can sit on the hardware layer, the basic BIOS, and just needs to be booted. It cannot be touched by resident code, and is fully compartmentalised and self-contained in operation.

ADF3s are designed as the bridge from current application-centric computing, to data-centric computing. Forget owning a PC with a resident copy of Windows and a set of applications. Instead you have a bare ADF3 box with a hardware/software interface designed to an open standard. You insert a card containing your ADF3 file, and boot it. The ADF3 box is now a device dedicated to doing one thing really well. No virus can sit in the background and snoop on you. You do not need to purchase any applications, nor do you need to choose a specific OS or a version of that OS. No more worries about device drivers or incompatibilities. Everything is subservient to each unique file, right down to the look and feel of the OS it runs on. Whenever you use an ADF3, the application and OS were both created when the data file was created, specifically to run it, so they aren't going to crash.

An ADF3 box may be a payphone or a cash dispenser. Insert your ADF3 on a card and it becomes your dedicated device using whatever keyboard, display, and internet connection that it can find.

Using the ADF framework, we can move from application-centric computing to data-centric computing, and everything we do now, we can do more safely, but in an entirely new computing environment. ADF computing is a mature, robust and secure computing environment. It is a fundamentally different way of doing things. Data files become active, self-contained objects and negotiate their own use according to their creator's wishes, autonomously. It is the future of computing. The basic structures of DCC need to be laid down carefully, as they may need to last for 20 years or more-a lifetime in technology terms. No repeats of the 640K memory issue.

Suggested exemplary prototypes

1. An ADF1 operating under Windows securing access to a Word or Excel file.

2. An ADF1 file that opens a compatible variant of its contents according to resident app. compatibility.

3. An ADF1a file operating as a secured e-mail.

4. An ADF1 secured and PIN-gated HTML file.

5. An ADF1 requiring networked verification (MAC address/IP connected SQL-call verification).

6. An ADF2 file offering AV content with a built-in player.

7. An ADF2 file offering HTML content with a built-in browser offering interactive response to a dedicated server.

8. An ADF2 file securing itself by running on a RAM disk, perhaps intervening in the operation of any non-essential tasks running under Windows.

9. An ADF2 with an external Java shell capable of launching either a Mac or PC app. subject to its resident environment.

10. An ADF3 file running on a bare Intel box.

11. An ADF3 file partitioning its own space on a Wintel box and running alongside Windows, polling time from the hardware.

12. An ADF3 Box accepting multiple ADF3 cards using compartmentalised memory and polling processor time.

13. An ADF3 public kiosk (video conferencing; VoIP; cash dispensing in multiple currencies; web browsing; e-mail; txt messaging; fax TRX; printing; scanning facilities).

Examples of commercial use of ADFs/DCC

It is difficult to pick out specific uses, as everything that is currently done using technology could be done differently within a DCC environment. In a sense, limitations of processing power and cost made the decision to go with application-centric computing the right one, many years ago. Now, technology has changed, and the cultural implications of the way computing operates within our society suggests that DCC may be a better way to go. Under DCC there is no distinction between active applications and passive data files. All files can be ADFs. A passive data file can still be used as an open source alternative, but it may become typical to package it with a mediating application.

(a) Passport/Digital Payment technology

An ADF can be used as an intelligent digital wallet. You can program an ADF to act as an authorisation for payment from any account to any other account, and despatch it electronically by any media. It cannot be stolen and the funds diverted, as the file contains not just the amount, but details of the transactors. Possible usage: The Microsoft Passport; The Liberty Alliance's alternative to the Microsoft Passport; PayPal; E-Bay; Mastercard; Visa; American Express.

The technology is entirely secure. Theft is an impossibility. Instead of moving money (banknotes), or a generic authorisation to make a payment (a credit card transaction), you are sending detailed instructions of the entire transactions, and in a manner that prevents unauthorised usage. Your credit card company can send you a blank pile of sterile ADF files, or a fertile ADF creator, and these allow you to make payments. Although they may pass through the hands of third parties, like Amazon, the files would only ultimately be readable by your credit card company. And before your transaction finally goes through, you may have to give final and direct authorisation. The ADF can be so programmed that you create an ADF file for payment, it goes to Amazon, opens for them and has the amount and their details entered into it by their software as a part of the payment process, returns to you, is checked, and then goes to the credit card company.

(b) An OEM-facing description of digital content protection using ADF/DCC

What our technology offers

1. The prevention of mass-piracy of DVDs, CDs, and software.

2. DVDs and CDs that only run on players (and PS2s), not PCs (or X-Boxes).

3. Control - on an individual title basis - of the release of DVDs as they are currently released in the cinema. Our DVDs would have a best-before date for playing. They would only play after a certain date in a certain region, for x days/weeks.

4. Complete backwards compatibility with ordinary DVDs and CDs.

5. Complete invisibility to the user. No IDs or PIN numbers required. No mobile phone chipsets, no online verification checks, and no product activation by phone.

6. OEM chipsets required by all player manufacturers who want their kit to be compatible.

7. The option of not using the technology for low-piracy-risk DVDs and CDs to reduce cost. This is for major releases of new movies/albums.

8. Control over the ability to record and playback broadcast TV programmes. Some programmes may not be recordable, some may only play back for a week.

9. On recordable media, a DVD or CD can be 'married' to a single player after a first run, so that it cannot be shared with friends or sold on.

10. A portable CD player that can securely transfer its music on to a small detachable unit using eeproms, increasing the battery life by 10x.

What our technology requires

1. The insertion of code into the chipsets of CD and DVD players.

2. The ability of the DVD units to pull time and date data from Teletext signals (something they already do) and use it for release management.

3. CD players and (optionally) other media player units without access to TV signals, possibly including DVD players, would need a Date Chip built on to the circuit board, with its own trickle-recharge battery.

4. Piracy-proof disks would be fundamentally different to ordinary disks, and have a start-date and a best-before date. The dsitribution chain would need to accomodate this, as it does with cinema movie reels, Cadburys Creme Eggs or Christmas cards.

5. Coded signals incorporated into broadcast TV, invisible to the user, that determine how the programme may be recorded/replayed. A line across the base of the screen using two digitally different shades of black would do.

How it is implemented

1. Start inserting our hardware and firmware into players, especially the new R-DVDs. Recordable media is not required for most of the anti-piracy technology, but it is the purchasing of these machines that will leverage the new technology into people's homes.

2. Over the next 2 years, recordable DVDs will become the new standard. The original DVD players will go into childrens' bedrooms.

3. When a critical mass of ownership of players with the new chipsets in has been reached, a major new release is sold at half normal price. It cannot be pirated digitially in any number as pirates cannot match the distribution channels of a major vendor like, say, Sony. Thats the key. They can copy the disks byte-by-byte, but they cannot match an international vendor's distribution of them to stores. You can only pirate these disks after release, and by then, the clock is ticking.

4. The DVD is released and works for 1 week on a best-before date release. Later, an unprotected version can be released for the collector/owner market, to keep the shelves full.

5. Normal disks can still be sold where there is little piracy risk.

How it works

1. The Date Chip, if you are using one, is programmed when the player is built and keeps track of the date throughout the life of the player. Alternatively, a DVD unit can detect the date from the teletext date signal.

2. A normal disk is simply played in the player.

3. A protected disk isn't simply encrypted DVD data. It is an 'active data file' (ADF). It contains both a program and encrypted data. The new DVD chipset recognises this, and doesn't use its normal firmware. It loads the firmware it will use to play this disk from the disk itself. This program now runs, checks the date from the player and the date of acceptable release from the disk, and decides whether to play. It then decrypts the disk using decryption chosen for this specific release, and plays it.

4. Using recordable media, the DVD may erase after playing n times. It can also 'marry' itself to a single player, remembering the serial number of the player it first played on. The disk will only then play on this machine, preventing it being shared amongst friends. After use, for environmental reasons, the DVD can become a blank disk you can use to record ordinary programmes upon.

5. A protected disk will not be recognised in an old player, or in a PC. A PC may be able to read the data, byte by byte, but to play it, software would have to do more than decrypt it, it would have to be a reverse engineering of the code in the DVD player, to run the software from the disk, to then play the disk. The player firmware that boots the software on a protected DVD needs to be protected from reverse engineering, and any date chip needs to be un-moddable. Miniaturisation, encryption, and resin should do that. The enabling software supplied on the disk as a partial replacement for the DVD's firmware can differ from release to release, and from disk to disk.

6. On a CD player, once release criteria are met, a CD's music tracks can be unencrypted and stored on internal solid state memory. The part of the unit containing this can be detached, and the music can be played from this n times, or for n days. So you can listen to music purchased on a CD, securely, from a memory chip. This is a much smaller power drain as the CD unit is not operating as you listen, and the detachable player unit is much smaller. This is good for the user and the environment. As capacities improve, you will be able to upload a DVD onto a portable player.

7. Control over the recording of broadcast TV has considerable potential, improving the value of content.

8. DVD and CD rental is still possible within the release window of a disk, if you do not marry a disk to a unique player, but rental can effectively be abolished for major new releases, until they have passed their peak profitability.

9. As you send out new firmware with each protected disk, you can offer new features on old players. So a DVD may contain games, and if you plug a device into your DVD player, you may be able to buy merchandise associated with the movie, or enter a competition interactively, when you run the disk. An external access port that the firmware can talk to, would be a good idea. This would make DVD players interactive and future-proof. A DVD player becoming a PS2 rather than a PS2 becoming a DVD player.

It is absolutely vital that the technology is implemented into players before recordable DVDs hit the the price point where everybody buys them. When they do, they will not have a reason to replace them for 5 years.

(c) Kiosking

ADF3s and DCC are particularly good for public kiosks and public computing, turning a PC from an expensive and vulnerable piece of stealable goods with a high TCO, to a simple infrastructural piece of domestic furniture like a payphone.

ADF3s contain all of your own PC bar the hardware, for whatever file you are working on. You can slot one in a public kiosk and the OS built in to the card the ADF3 is on will boot on bare hardware, and seek whatever screen, keyboard, and network connection is available. You do not have to worry about security, as all data transactions beyond the card the ADF3 is on can be encrypted. You cannot pick up a virus as the OS and application are packaged with the data you are using, and are yours. You are not sharing a public version of Windows, Word or Explorer. All you are sharing is the hardware and the BIOS on firmware.

Wherever you are in the world, your ADF3 cards are your entire PC bar the generic hardware you run them on. This offers real potential for Public Kiosking technologies (for companies like BT), replacing PCs with kiosk units in libraries, hotels, cybercafes etc. An ADF3 aware machine can, for 1 a transaction, be a hole-in-the-wall bank machine, if you insert the right card and it has a banknote port, or an e-mail terminal, or a web link for surfing or videoconferencing, or a VPN terminal. Without an ADF3 card, it is basic hardware.

ADFs/DCC and BizTalk

BizTalk is an expensive way of pre-programming the movement of dumb files between disparate applications. It's a file manager. It's needed because we live in an application-centric universe. It demonstrates that the basic benefits of doing it this way, evident many years ago when we only had a few Kb to play around with, may now be outweighed by the downside of trying to manage dumb files in a chaotic world of different OSs, versions, protocols, etc.

BizTalk uses XML, SOAP, XSLT and lots more besides, and it's only going to get more complicated.

Now consider a data-centric version.

You have a pile of blank ADF2 templates supplied by head office for returns. When a customer wants to make a return, you open one up and fill in the details. The ADF2 will then be preprogrammed to handle every aspect of the procedure. It can talk to any application, anywhere, as instructed, to arrange the pick-up with the delivery company's database. It can sit on your PC waiting for a response, it can ask head office for advice if a problem comes up. Basically, it deals with the job. An autonomous object-oriented data file that can do anything it needs to to complete its function. Then it dots the i's, and crosses the t's, sends a completion e-mail, logs its behaviour on the company archive, and erases itself.

Addenda

Prototypes of ADF2 and ADF3 files may be done as both sterile and fertile. ADF1 files may be read-only or writeable. A primary ADF creator program with Works-level features would be advisable. As would an ADF analysis app. for forensic examination of the logs of ADF files. There is considerable scope here for products aimed at the legal professions.

An electronic trip-wire can be attached to a file, so that when stolen, it reports back what is happening to it.

Essentially ADF/DCC technology attempts to emulate firmware in software.

Adobe appear to be heading in this direction with the latest version of Acrobat.


Back to Stig's Dump.