Sunday, October 30, 2011

The Priority of Constituencies

Lawrence Lessig wrote in Code is Law that the choices we make in writing code embody our values.  This observation is especially true when building a browser because the browser mediates interactions between many distinct entities.  Because the browser's security policy is at the heart of mediating those interactions, we should ask ourselves what values the browser's security policy embodies.

One key value is the priority of constituencies, which is enshrined in the HTML Design Principles:
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.
To better understand this principle, let's consider a specific example: whether the browser's password manager should be enabled for a given web site.

The password manager is a source of conflict for these competing interests.  Implementors (myself included) believe that password managers improve security by reducing the costs of using a large number of more complex passwords.  Many banks, however, disagree.  They believe that password managers reduce security because passwords stored in password managers can be stolen by miscreants.

How do browser vendors resolve this conflict?  By default, we enable the password manager.  Because users have a higher priority than implementors (i.e., browser vendors), browsers let users turn the password manager off.  Because authors (i.e., site operators) also have a higher priority than browser vendors, browsers let authors disable the password manager on their own web sites by setting autocomplete=off.

The careful reader will have noticed that the scheme above violates the priority of constituencies in one case.  What if the user wants to use the password manager on a web site sets autocomplete=off?  Because users have a higher priority than authors, the browser should resolve this conflict in favor of the user.  Typically, browsers handle this case via their extension system.  For example, the autocomplete=on extension lets users override authors who want to disable the password manager.

How, then, should we respond to web site operators who wish to block or override these sorts of extensions?  As long as we believe that these extensions faithfully enact the user's will, we're hard-pressed to let authors block these extensions because that would violate the priority of constituencies.  Instead, we ask authors to be humble and accept the user as sovereign.

4 comments:

  1. As the author of that extension, let me also note that for a long time I've wanted to change Chrome so that its built-in UI lets users override site authors here.

    There is a difficulty, though, in that "autocomplete=off" is used in many types of data fields -- passwords, credit card numbers, and "fields it wouldn't be very useful for the browser to provide completions for later" are three distinct cases -- and while the right behavior may differ from case to case it's often hard for the browser to know which case a particular field represents.

    ReplyDelete
  2. Some users belong to an organization, which may have its own policies. Where do they fit in?

    ReplyDelete
  3. And today is your day, Peter.
    "As we’ve previously discussed, Chrome will now offer to remember and fill password fields in the presence of autocomplete=off. This gives more power to users in spirit of the priority of constituencies, and it encourages the use of the Chrome password manager so users can have more complex passwords. This change does not affect non-password fields." -Daniel Xie, Google Chrome, Chrome release blog

    ReplyDelete
  4. Our free web hostingOpenVZ VPS packages include enormous CPU time and memory allotments and offer a ninety-nine point nine percent server uptime guarantee.

    ReplyDelete