This model would use a similar style of screen (or window) to the current generic EULA window (such as the Microsoft EULA screenshot in Figure 2.1 from Chapter 2), but which would provide a lot more control for the user. Of course, the entire legal document would be there for the user to peruse if needs be, but in the same way that a car has dashboard lights to tell a driver of the status of parts of the car, so there would be icon highlights that show users items for potential concern within the agreement itself. Hovering the mouse over the icon would bring up a tooltip with a short explanation of the behaviour requiring explicit consent. Clicking on the icon would take the user to the pertinent point in the document, which would be written in plain, yet legally binding, English (or have a plain English equivalent), and highlight the area of interest. Each expectation as encapsulated by its icon could need to be individually checked off rather than a blanket ``I agree'' checkbox to facilitate feedback for a good communication transfer. If one or more of the individual expectations are not waived by the user (i.e. the checkbox under the icon is not checked), some more information about each one could be communicated to make sure that it is what they intended, explain that it will mean the software will not be installed, and then exit the installation. The agreement also asks for the user's date of birth and location, as a basic form of competence testing and jurisdiction identification. A mockup of the first example window for this style of agreement is displayed in Figure 4.5.
To address expectations needing to be waived but not present in the collection of modules, a second step can be optionally added4.5 which allows for additional expectation waiving. Here, any expectation that does not fit under the previously waived expectations should be listed. An example of the second step window is in Figure 4.6. This allows for an element of future-proofing and flexibility for the scheme. The danger is, however, that with technology changing, new types of expectations would start to crop up more frequently, and this second window could become cluttered. It is because of this that the trusted third party should monitor the sorts of expectations that are outside the standard ones, and eventually include them in the list of standard expectations, while retiring those which are no longer necessary as the situation calls. This style of consent window, though, means that consent-requesters who might otherwise only see the standard modules as being required for disclosure and consent, cannot modify the standard agreement to ``hide'' other things in it, and so must have a more visible second window that draws attention to the additional requirements they have.
