When developing these expectations, I discovered that often several expectations were discussed simultaneously, with similar reasonings behind their requirement. Thus I have grouped some expectations together with similar expectations, in order for the discussion to avoid repetition and to establish a working context for the inclusion of each expectation.
A software user should have the following expectations:
1a. The software should meet minimum standards of merchantability and fitness for the purpose for which it is made.
1b.
The software will adhere to known software standards.
A user has the expectation that the software will work in the way that it is advertised to, with the functions and features as claimed, and with an accurate description of these functions and features. The software should perform the required task after having been tested adequately to meet quality assurance standards. Of course it is likely that the software will have bugs even after rigorous testing, but the process of testing should find the major problems which impact on the fitness of the software for the advertised purpose. These bugs would typically be addressed before a software product is released, or at least listed as a known problem, so that the user is aware of the limitations of the product. Miller states that the specifications of a piece of software should be accurate and obvious enough to the user so as to be unambiguous, and that software should be sufficiently tested and verified [Miller, 1997], Black Hill Software claims that protection of fitness and merchantable quality standards should be met and that the user should not be deceived about any functions [Black Hill Software, 2007], and the IEEE Computing Society expects software to work as expected and specified, that it be fit for its particular purpose, that it adheres to known standards, and that the information on the software packaging describes its form, fit, and function accurately [IEEE Software and Systems Engineering Standards Committee, 2001].
The sorts of situations where these conditions might be waived by the user would be for experimental testing of software (such as beta-testing) for 1a and 1b, and for cutting-edge technology where no standards are defined, or where the standards are inappropriate for use for 1b.
2a. The software should not disrupt the existing operation of the computer.
2b. The software should not
distract the computer user.
Users do not expect to be interrupted by software unless it is an important notification, within parameters that they can configure. Users also expect that when they install software, it will not change any way that the computer or other software works, unless they specifically installed the software for that purpose. For example, the Sony rootkit incident involved the software Sony installed to play music CDs on the computer also installing a rootkit3.7 which changed the way the operating system behaved. This allowed for malicious software writers to take advantage of the operating system and infect the computer with malware, with the computer user completely unaware [Russinovich, 2006]. A rootkit is not the sort of software that a user would expect a CD player to install on the computer, since rootkits are usually used by hackers as a way of accessing higher level privileges of a computer in order to exploit it. Other software that changes the way the operating system works, or how other software works is acceptable, however. Some examples of acceptable software would be anti-virus and anti-malware programs that find and disable (or delete) virus and malware applications. According to Google's software principles, vendors and manufacturers of applications that change the behaviour of the computer or of the user's experience should assert the reasons for doing so and make it clear to the user that the software is the reason for the changes [Google, Inc., 2006]. Black Hill Software's software code of conduct requires software to not interfere or disable the function of other programs [Black Hill Software, 2007], and the IEEE Computing Society's list of expectations for software users states that correct and naive use of software should not interfere with the general use of the computer [IEEE Software and Systems Engineering Standards Committee, 2001].
Expectation 2a could be waived in the situation that the user wishes the operation of the computer to be changed. For example, installation of a hardware driver or keyboard layout changing software could modify the operation of the computer in a way that a user would want. Expectation 2b could be waived when the user wishes to be reminded or distracted by software such as calendar software, or software that enforces breaks from computer user to stave off injury.
3. Any collection of personal information will only be done with the user's knowledge and understanding. The amount of personal information collected and stored will be minimised, with that data effectively obfuscated, transferred and stored securely, and all collection and storage procedures subject to applicable privacy laws and standards.
Many software applications require some sort of information to be sent to the developers of the application, to be stored remotely on a server for all sorts of purposes: everything from IP addresses to billing details to photographs, myriad different sorts of information of varying levels of importance. A user who wishes to use this sort of software would expect to have their data transferred securely, and stored securely, and only after they have allowed the data to be transferred in the first place. Under many circumstances, that user would expect any data that did not need to be personally identifying (tracking of search requests for example) to be anonymised so that no link could be made back to any personally identifying information. The user would expect other information that is personally identifying, such as registration or account details, to be treated with a high level of security, such as high-grade encryption. Of course any software should be expected to adhere to the relevant privacy laws and standards that exist. The Electronic Frontier Foundation (EFF) is particularly concerned with the collection, use, and storage of personal information. In their guidelines for online service providers, they focus on user expectation that the collection of personal information is minimised, and that any collection and storage adheres to privacy laws. Storage of such information should be for the minimum amount of time possible, and personally identifying information should be effectively obscured. Transmission of personal information should be secure, and demarcations between different sorts of personal information should be established, because different sorts of personal information need to be treated differently (preferences, tracking, and authentication in Web site cookies are all examples of personal information, but sorts that require different levels of security and obfuscation) [Electronic Frontier Foundation, 2008]. Google's set of software principles requires notification and informing of the user when personally identifiable information is transmitted [Google, Inc., 2006]. Gibson states that users should expect software to inform them when it communicates information, to state how it plans to use Internet connections, and to not unnecessarily gather information. One of the earliest grounding principles in user expectations of Internet services and software products is encapsulated by the RFC 1746 requirement of privacy [Manning & Perkins, 1994], which shows that this is a highly important normative expectation for computer users.
This expectation is a little different from the previous expectations, since it is difficult to find a situation (in the current information technology climate) where a user might wish to waive it. There could be specific parts of the expectation that might be waived, but this sort of expectation is the sort that would need a significant amount of justification for waiving.
4. A user should be able to easily opt-out from any service or uninstall a software program at any time, with that action being final and persistent, removing all traces of the software and fully unsubscribing from any associated service.
Users expect their computers to respond to their commands. They expect that when they choose to uninstall a program using either the program's uninstall function or the operating system's uninstall function, that it will then be uninstalled fully, leaving no trace of itself on the computer. Unfortunately, this is often not the case, as many software applications that have trial periods will leave traces of themselves on the system in order to stop people from installing the trial, uninstalling it when the trial period is over, then reinstalling the software to exact another trial period. Examples include the RSS reader FeedDemon and many applications that come pre-installed on new consumer computers [Krazit, 2006,Moise, 2004,My Digital Life, 2006]. Some software and service trials take the credit card information of the user at the beginning and, after the trial is complete, automatically start charging the user for the software or service, even if the user does not use it. The movie service Movieland is one such example: it would charge users a monthly fee unless it was explicitly cancelled within the three day ``free trial'', without giving users an opportunity to opt-out before the charges began [McMillan, 2006]. The expectation of full control is fully backed by several recommendations from various sources: the EFF states that a user choice to opt-out from a service should be both available and persistent, that is, that once a user has opted out, there should be no further requests for confirmation of the user's choice [Electronic Frontier Foundation, 2008]. Other sources state the expectation for software to be easily and simply removable [Gibson, 2008,Google, Inc., 2006]; that if the software is exited or shut down, that it exits completely, and doesn't continue to run services in the background [Black Hill Software, 2007]; and that management of software (preferences, installation and uninstallation, etc.) conform to the operating systems standards (for example, the Control Panel of Microsoft Windows OS, and the ``drag and drop'' disk image format and Preferences pane for Mac OS X) [IEEE Software and Systems Engineering Standards Committee, 2001].
Similarly to expectation 3, there would be little need to waive this expectation. However, there could be some situations where removing all traces of the software could leave the computer operating system unstable, so in that circumstance this expectation could be waived.
5. Any additional software that requires user informed consent under these guidelines and installed by the host software should be upfront and present its own install process, as if it were installed as a standalone application.
As in the Zango case (see section 2.1.2) we can see that installation of other software as ``part of the package'' is commonplace, with each additional piece of software's terms and conditions simply referred to in the Zango EULA, rather than installing each application on its own with its own installation process. When a user downloads and installs a piece of software, they do not expect it to automatically install other software, especially other software that does something different from the software that the user installed (such as Zango's bundled advertising software, which was only referenced deep within the Zango EULA). Each additional software package, no matter how closely related to the original software package, should thus be installed separately, and treated like a standalone application. The software should also explain how it is related to the parent software, and if the additional software is required for the parent software to function, allow for the user to uninstall the whole package easily if the user does not agree to the requirements of the additional software. As Google states it, ``good software should keep good company'' [Google, Inc., 2006]. Bundling of notorious applications (such as in the Zango case with the advertising software) is not keeping good company; the way for it to become a good relationship is for the vendors to be up-front about the installation, and the best way to do that is through an installation process that shows the relationship between the two pieces of software.
There might be situations where this expectation could be waived, if the software is treated as part of the main software. For example, some software include other software such as language interpreters, emulators, etc. that would be considered part of the main software, even though they are distinct pieces of software in their own right. One way to determine whether they are distinct would be to assess whether the additional software performs a function that is necessary for the normal operation of the installed software.
6a. All rights and responsibilities of the user and software company should be easily understandable, with important information
obvious and easy to access.
6b. If the user does not agree to the terms of the software agreement (in the case of a
``clickwrap'' or OEM license) they can return it unused for a full refund.
The fact that the majority of software packages do not have their EULA printed on the shrinkwrapped box is seriously problematic. Users expect that if they do not agree to a contract, they can get their money back on the service or product provided. However, software manufacturers make this difficult because they are worried about piracy, specifically the sharing of serial numbers that are usually printed somewhere inside the box, and which are unique to the purchased software. This means that many manufacturers will not accept returned software regardless of the reason outside of manufacturing faults, which puts the user at a significant disadvantage since the EULAs are not made available before the purchase of the product. Similarly, hardware manufacturers often sell ready-made computers with software pre-installed (such as the operating system). The cost of this software is absorbed into the price of the computer as a whole, but the user is presented with an EULA for the software when the computer is first started. The difficulty of returning software obtained in this way was highlighted by Bennett (1999) who, after several months of persistent correspondence with Microsoft, eventually obtained a refund for the software he never used. There are now ``how-tos'' available for this particular problem [Wroclawski, 2007], with the refunding practice increasingly common. In many jurisdictions the expectation to return unused merchandise is law, but it should be made explicit within the license agreement so that those who do not know the details of consumer law are informed of this right. As for the EULAs themselves, users should expect them to be short and simple, pertinent, and easy to read, outlining their responsibilities and rights, with important information easily accessible (i.e. not four thousand words into a five thousand word document).
Expectation 6a is another expectation that would be unusual to have to waive, but expectation 6b could be waived depending on the method of obtaining the software (especially in the case of free software), for example.
7. Any software specification or policy changes should be communicated effectively to the user and require user consent to the changes.
Users expect companies to keep in touch with them if any major policies change, especially policies that change the way that the user uses the software, or changes the billing, or changes any other fulfilment of expectations the user has of the software. Many software license agreements include a clause that states that they can be changed ``at any time'', mostly without any mention of notification of the user, or with specific mention that the user will, in fact, not be notified (see the section 2.1.2 on Zango's clause, which does not mention user notification, but that the EULA can change at any time).
Once again this expectation should not be commonly waived, but there could be circumstances where waiving the expectation of explicit
consent to changes is necessary, in the event of a major security vulnerability or similar. However, in the case of such a situation, the
user should at least be notified that the software is being updated, and not ``piggyback'' other changes without adhering to this
expectation.
A summary of the expectations and which sources they were derived from is provided in the following table:
|
As shown in my examples, and supported by the recommendations for standards, all of these normative expectations are important to users, and thus gaining informed consent by way of waiving them is vital for software. Of course these are only a subset of any number of expectations that would change depending on the context and market for the software, or for particular information technology services, but these are a good starting point for examples. As mentioned earlier, identification of normative expectations specific to a particular project requires examining the uses of the project by different sorts of users, with their values and expectations at the forefront of the design so that as few of them as possible need to be violated in the first place. Value-Sensitive Design could well be a good tool to work with when attempting to identify normative expectations: with specific focus on end-values like privacy and honesty it could be a useful method for identifying the values and norms for the specific stakeholders. However, it requires a very strict set of boundaries in which to work for it to be useful, that is, the recognition that using the concept of informed consent as a goal for the design principles is not an acceptable aim; instead recognising that informed consent should be used as the mechanism by which values can be attained or upheld.