- 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" set of configuration 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 setting this multitude of configuration as well as allowing this configuration to vary by site visited as well as "operating mode" in which the user agent is being used. Also,
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 operates according to a configuration and does 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 would indicate what the choice should be. There would be no dialogs presented to the user for configuration - ideally a set of "known good" or "known to be trusted" configurations or "profiles" could be loaded and worked from.
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 several "profiles" (sets of configuration settings) to be used when visiting different categories of sites.
A user agent MUST support the configuring of different "usage modes" and allow the specification of which profiles are active in which modes.
A user agent SHOULD allow users to view details of why a request or access to a site was blocked based on profile settings, including 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 configuration settings and profiles can be set up and changed, separate from a "usage" mode to be used by what is considered the "user" of the user agent.
Implementations may choose to support a multitude of configuration settings called profiles in this description. 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 factor of usage mode as well as 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 profile 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 configuration profiles 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 in various operating modes and controlled by certian profiles.
User disruption in the form of a site not being accessible is expected.