Some potential activities of software that would generally violate a user's normative expectations include (but are not limited to) the following:
Some of these have already been discussed in Chapter 3, with attention there focussing on collection and storage of personal data, disruption of or changes to the existing operation of the computer, and installation of additional software; and with Garfinkel's approach in mind I nominate a few other activities that are potentially undesirable to users. A user would need to know if their behaviour is being monitored, such as through software that monitors keystrokes or captures screenshots, or which monitors traffic flow over the network. Displaying of advertisements is another: advertisements can be distracting and show inappropriate things or the advertisers may engage in dubious practices such as tracking of advertisement views. Other activities that affect the user could be the practice of directing the software to start up when the computer first boots up, and then running it in the background seemingly invisibly until the user actually wants to use the application, at which point it loads very quickly because it doesn't need to perform all of its startup routines. This is not a bad thing on its own, and can result in speedier loading times for programs. The problem is that with many programs performing this activity, the computer starts to take a long time to start up on boot. This could mean that the computer actually starts to perform much worse than usual because of all of the programs that are running in the background, taking up system resources such as memory and CPU cycles and thus encumbering the computer. Automatic upgrading is also a potential issue, since, although it is usually welcomed by most users and recommended for security issues, there are some upgrades that could be harmful to particular users, especially if the upgrade significantly changes the behaviour of the software. These sorts of changes could be problematic for users that rely on a particular feature of the software that is removed by the upgrade, so there should be at least some sort of notification and re-acceptance of the agreement before the upgrade is made.
Other things not directly related to software activity that should be considered for explicit waiving within an EULA include the normative expectations of merchantability and fitness for a particular purpose, complete termination and deletion of details of any account information on uninstallation or unsubscription, the ability to obtain a refund if the terms are not agreed to, and notification of changes to the terms of the agreement. These are all agreed upon by the standards and codes discussed in Chapter 3 and thus warrant particular attention.
Sets of logos or icons would need to be developed in order to best represent the ideas for waiving. The sorts of things Garfinkel had for his set is a good start, but more would need to be developed. One problem which could arise is that too many icons would need to be included in the standardisation, to the point where the immediate recognition of particular icons is diluted by the sheer number of them. This could be avoided by good graphics that encapsulate accurately the meaning of the icon, so that memory is not needed, or by tooltips that simply need a mouse-over to display a summary of the meaning. Of course, the user could also simply click (or some equivalent) the icon they are uncertain about to visit the area of the agreement that details the behaviour. There will inevitably be design issues with this recommendation, but with the right sort of priority balancing they should be minimised with little effect on the overall positive outcomes of the project.