A widely cited publication in usable security research is Simson L. Garfinkel’s thesis: “Design Principles and Patterns for Computer Systems That Are Simultaneously Secure and Usable”. In Chapter 10 he describes six principles and about twenty patterns which can be followed in order to align security and usability in system design.
We’ve been referring to these patterns throughout the webinos project when designing the system and security architecture. However, it’s interesting to note that the web (and web applications) actually directly contradict many of them. Does this make the web insecure? Or does it suggest that the patterns and principles are inadequate? Either way, in this blog post I’m going to explore the relationship between some of these principles and the web.
I’m going to skip some of the principles, and focus on just the most relevant.
Install before Execute
Ensure that programs cannot run unless they have been properly installed.
This pattern is clearly broken on the web. Visiting a webpage does not install anything, but does allow a web application to run. The sandbox model of webpages, however, protects against a malicious web application. What it doesn’t do in practice is protect against phishing sites, clickjacking or other web-based attacks. Furthermore, access to privacy-sensitive APIs such as Geolocation require approval but no explicit installation.
Explicit User Audit
Allow the user to inspect all user-generated information
stored in the system to see if information is present and
verify that it is accurate. There should be no hidden data.
This principle varies on different sites, but is rarely adhered to. Google and Facebook, to their credit, allow users to download and inspect most of the data held about them. However, these are the exceptions rather than the rule. Hidden data is very much the norm.
Ensure that when the user deletes the visible repre- sentation of something, the hidden representations are deleted as well.
While this is theoretically something that a web application could do, it is very rare to see it. Social networks have started to provide full account deletion as an option, but only as a result of user requests and news articles.
Leverage Existing Identification
Use existing identification schemes, rather than trying to create new ones.
This is definitely getting better. The rise of OpenID and single-sign-on means that more websites allow users to be identified by existing accounts rather than recreating their identity for each application.
Email-Based Identification and Authentication
Use the ability to receive mail at a pre-determined email address to establish one’s identity or authorization to modify account parameters.
This is the standard way of recovering credentials and authorising privileged actions on the web. However, one might question the wisdom of this. As email is itself being served by web applications and account hijacking is extremely common, this seems like poor protection. This explains why text messages and smartcards are being used by the likes of PayPal to recover credentials. However, this may also not be enough.
Key Continuity Management
Use digital certificates that are self-signed or signed by unknown CAs for some purpose that furthers secure usa- bility, rather than ignoring them entirely. This, in turns, makes possible the use of automatically created self- signed certificates created by individuals or organiza- tions that are unable or unwilling to obtain certificates from well-known Certification Authorities.
This is very rarely the case on the web – either a website has a certificate with a root in your browser, or you will receive so many security warnings that most people won’t use it. Most browsers do allow you to add self-signed keys to the list of trusted authorities, but I expect this to be rarely used outside of corporate environments.
Disclose Significant Deviations
Inform the user when an object (software or physical) is likely to behave in a manner that is significantly different than expected. Ideally the disclosure should be made by the object’s creator.
Arguably web applications do this when they break the browser sandbox – to access device features – by presenting a dialogue or pop-up prompt for confirmation.
Distinguish Between Run and Open
Distinguish the act of running a program from the open- ing of a data file.
This is certainly not the case on the web. While it should be possible (using content-type headers) to force a browser to display text, it is rarely used in practice. Visiting a web application and reading a page of text have exactly the same security framework around them.
Disable by Default
Ensure that systems does not enable services, servers, and other significant but potentially surprising and security-relevant functionality unless there is a need to do so.
Browsers are a good example of this. The sandbox that websites run within is a default-deny environment which requires explicit consent before dangerous activities can occur. Of course, this may not be true of the web server or cloud-based content.
Warn When Unsafe and Distinguish Security Levels
Periodically warn of unsafe configurations or actions.
Give the user a simple way to distinguish between simi- lar operations that are more-secure and less-secure. The visual indications should be consistent across products, packages and vendors.
This is partially followed with HTTP/HTTPS status. When a website has an invalid certificate, the user is warned constantly by an icon on the address bar. However, little attention is drawn towards an HTTP connection. Other enabled features such as Geolocation may have icons showing that they are active on a page, but this is not necessarily safe or unsafe.
Overall, the web and browsers in particular are guilty of violating these principles. In some cases, this is due to the sandbox enforced by the browser. However, the migration of web pages from static text to dynamic, potentially untrustworthy applications, means that principles such as Install Before Execute and Distinguish Between Run and Open may become more relevant. Reintroducing them for offline web applications and widgets may be a good idea, or might confuse users further.