There are three good reasons for the existence of a default policy. First, it is necessary to provide a reasonable behavior for an object if no policy is provided by either user or author. Second, it is sensible to insist on certain behaviours unless the user or author overrides those behaviours. It is sensible to use lossless compression on objects that implement no compression of their own, such as text, html, postscript, etc. It is also useful to be able to provide default policy decisions that only effect the quality of the media slightly but massively improve down load time or display usability, such as a small reduction in the quality of a JPEG or the frame rate of 30 fps video (see section 4.1). Finally, the default policy is the basis for the user to incrementally develop their own policies.
In an ideal world in which we had usable technology, we would have studied users in context, using browsers connected to the lowband proxy. Unfortunately, the performance of the proxy was stymied by the performance problems of RMI and in particular the Object Serialisation. Whilst we wait for Sunsoft to fix these in a new release of the JDK, we have conducted exploratory interviews to try to capture user opinions about acceptable trajectories of degradation, and interface behaviour.