Updated by Tim Hahn - 8 November 2007
- Browser Lock Down
- 2.6 Reduce the number of scenarios in which users need to make trust decisions 2.7 Authoriing and Deployment techniques
The current approach taken by most user agents is to treat the user of the user agent as having complete control (and thus assumed knowledge) over setting the myriad of security and non-security related configuration settings that are possible to be set in modern user agents. While these settings are presented in a number of ways including tabbed dialogs, check-boxes, combo-boxes, and radio-buttons, there are still a vast number of settings for end users of user agents to consider when setting up their user agent. Too often, the terminology for these settings is written more from the point of view of the developer of the user agent than from the user of the user agent.
Furthermore, in many cases, what would constitute a "good" combination of settings for one type of usage of the user agent (for example, casual browsing only) would not be considered "safe" for other types of usage (e.g. conducting business transactions using the user agent).
Clearly, there is ample opportunity for improvement in reducing the complexity of selecting the best combination of settings as well as allowing this configuration to vary by site visited as well as "operating mode" in which the user agent is being used.
This recommendation is applicable to any user agent which contains configurable settings for security-related processing. The end result of an implementation meeting this requirement would be a user agent which supports the specification of multiple "usage modes" and operates according to the "usage mode" which has been selected for the user's current interaction type (or site the user is visiting). While in a particular "usage mode", a user agent would not allow the user to stray outside of this configuration. There would be no prompting to accept or avoid access to a site - the configuration settings indicated by the "usage mode" would indicate what the choice should be. There would be no dialogs presented to the user for configuration - ideally a starter set of "well known" or "known to be trusted" configurations or "usage modes" could be provided during initial installation.
A user agent MUST support a mode of operation whereby the user is unable to view or modify the security-related configuration settings.
A user agent MUST support the configuring of different "usage modes" and allow the specification of which "usage mode" is to be the active "usage mode".
A user agent SHOULD allow users to view details of why a request or access to a site was blocked based on "usage mode" in effect. This MAY also include a description of which configuration setting or settings contributed to the site being blocked (but displayed only on request).
A user agent SHOULD keep a history of blocked sites and the reasons for the block to allow analysis of these at a later date and time (and possibly by a person other than the user).
A user agent SHOULD support a "admin/service" mode in which "usage modes" defined and changed.
Implementations may choose to support a multiple groups of configuration settings called profiles. These profiles may then be associated with different "usage modes". Implementations may allow a user to act as both an administrator of the user agent and a user of the user agent as a means of transitioning users from current status quo to fully locked down processing.
Organizations and social networking sites could build collaborative works to offer "well tested" or "popular" configuration profiles.
Which profile is employed could be made a dependent upon the site being visited. Site-specific behavior may be done based on rules about the security indicators the site is providing or based on white-list/black-list type lookups.
All information in the available security indicators (Available security information) could prove useful in determining which "usage mode" to employ for a given site visited.
Internet Explorer has an approximation of some of this with its security mode of "Internet" or "Local" configuration settings. However, the implications of this dialog are not well understood nor documented. Also, the user is still provided far too much disruption (spurious dialogs) and is also assumed to have sufficient knowledge and savvy to understand when a particular configuration setting should be modified.
Applicable use cases (from use cases):
- 2 - redirection to the unfamiliar site would be blocked by configuration, no chance for Alice to interpret the site incorrectly
- 3 - download and install would be denied by configuration, no choice for Alice to make.
- 4 - download and install would be denied by configuration, no choice for Alice to make.
- 6 - download and install would be denied by configuration and being in "casual browsing" mode, no choice for Doyle to make.
- 7 - download and install would be denied by configuration and being in "casual browsing" mode, no choice for Frank to make.
- 9 - which sites were allowed would be controlled through white-list/black-list dependent on operating mode.
- 12 - no in-flight dialog pop-ups would be displayed. Betty could go back later and get the certificate if accessing that site is of interest, but does so when she is in the frame of mind of changing security configuration. The log of blocked sites (and reason for the blockage) assists in performing this work.
- 13 - the certificate either accepted or site blocked based on configuration, no choice for Betty to make.
- 14 - the certificate either accepted or site blocked based on configuration, no choice for Betty to make.
- 18 - dialog boxes are not displayed, all decisions based on configuration, no dismissing them out of habit.
Attack resistance and limitations
Attacks on the integrity of the system on which the user agent is running (and thus the configuration is held) are applicable.
Users may find annoyance in experiencing a large number of blocked sites if the configuration is overly constricting or a large number of sites are operating with what appear to be risky behavior. Also, analyzing past blockages to determine if a change in configuration/profile is warranted could prove to be a difficult debugging task.
More analysis of additional attacks is necessary.
Expected User behavior
The overall theme of this proposal is to remove the security decisions from the "user" of the user agent altogether - at the time of the suspicious or risky site being visited. Rather, determine all user agent behavior based on configuration and allow blocked sites to occur. Also, allow what are considered to be "more savvy" or "more knowledgeable" administrative users to exert control over the user agent "usage modes" on the end user's behalf. Thus, someone could contract with some other organization to configure their user agent per their guidelines and thus accept that they will be visiting sites that are determined acceptable based on that contracted organization's rules.
User security choices are eliminated at the expense of sites/features not being available while operating in various "usage modes".
User disruption in the form of a site not being accessible is expected.