The strong trend towards increased exchange of programs in combination with the advent of Internet commerce make up a strong argument for treating third-party programs with a little caution. It seems inevitable that security assistance has to be available to manage the granting and revoking of the increasingly fine-grained privileges that can be granted to programs.
We have argued that a Security Assistant can be of great help to both experienced and inexperienced users and that automation, customization and communication of what is monitored in the long run can help reducing the incentives to write malicious programs.
When implementing monitoring of untrusted code, the approach of comparing actual behavior to a profile of expected behavior seems to be the best way to start since it can be useful without extensive information about existing attacks. Instead of monitoring particular programs, functional categories should be used to verify the correct behavior of previously untrusted programs and holds the greatest potential for flexibility and diversity.
The architecture advocated in this paper tries to minimize what is said about what a sensor should monitor. Some suggestions are given, but no definite categories or general rules are given since what is sought is an evolutionary updating of the sensors.
The literature studies indicate that this kind of supervision is lacking in today's end-user environments for untrusted code. Related work has been done in the field of Intrusion Detection, although there the focus has been more into detecting user misbehavior.
More research is needed in this field in almost all aspects discussed in this paper. Most pressing right now is probably to make implementations of ``enabling technology'', i.e how to combine sensors efficiently and how to negotiate and divide work. Without this technology a large part of the work will have to be re-done whenever experiments with program descriptions will be done.