those dialogs

October 10, 2007

So there has been a lot of discussion recently about the key import dialog in PackageKit recently. We were talking about it on the bus on the way to work this morning, in fact. Here’s my thoughts (and some thoughts I didn’t come up with, but came from the bus discussion):

  • Showing the fingerprint in the dialog is only useful if the fingerprint is somewhere else the user knows to look
  • You obviously can’t put where to look in the key itself, because the key isn’t trusted until the fingerprint is verified
  • Since you can’t put it in the  key, discoverability is a hard problem.  We pretty much have to hope that the key is in plain view on the website that offers the package / repo.
  • “trust” is a bit of a stretch in any case, because often users will google around for software and install whatever they find. It’s really more “verify the software comes from the website that originally pointed to the package / repo file.”
  • Only users who really understand the security implications of the dialog are going to verify that the key fingerprints  match
  • Given that most people who see the dialog aren’t going to verify that the key fingerprints match, the dialog isn’t useful for security (it only solves the identification problem for a small subset of users)
  •  One way to make the dialog more secure would be to treat the fingerprint like a CD key / activation number that the user has to enter instead of something that gets shown to the user.   If entering the key was a required step for configuring a system to use a repository, then websites that offer repositories would have to include the fingerprint with the repo in plain view for the repo to be useful, and users couldn’t just click past the dialog without reading it.
  • Some might argue that users are accustomed to entering these types of numbers already when installing software.  There’s precedent anyway.
  • Having to enter long strings of numbers sucks (just as much as having to read long strings of numbers sucks)
  • Either way, there’s a very real aesthetic problem with this type of dialog, and it’s not clear there’s an easy way to fix that
  • One thing that can help is have the distribution know about a select number of 3rd party repos/keys out of the box, so then the dialog can hide the key fingerprint entirely.
  • Figuring out which keys to ship within a distribution is an interesting problem itself, but maybe it should have some parallels to the processes that the distribution uses for adding packages?

6 Responses to “those dialogs”

  1. Martin Says:

    “Only users who really understand the security implications of the dialog are going to verify that the key fingerprints match”

    I would say even this is stretching it too far. Even people who know what it means are lazy.

  2. ljt Says:

    If filling the whole key is cumbersome, why not asking for only a part of the key (randomly chosen), say for example max 6 hex?:

    6B F7 45 BB AA __ __ __ DD 23 47 34 67

  3. James Says:

    Debian has the debian-archive-keyring package. Typing in long series of numbers sucks, but there’s always copy and paste, since it’s coming from a webpage anyway.

  4. Peter Van den Bosch Says:

    I’m all in favor of removing the key info from the dialog because it 1) is hardly ever used 2) even weakens security for non-techy users. The most common behavior when normal users get confronted with a dialog containing incomprehensible stuff or which contains too much info is lazy behavior: just click next, yes or okay and most of the time it works. If it didn’t, the user retries and clicks another button.
    Now if the dialog just said only comprehensible stuff, users might have an idea what the risks are, e.g. “Software from this new location might be harmful if it is set up with malicious intentions or when it contains a lot of bugs. Do you want to trust this location?”.

    Giving this text and the key info at the same time might just scare users into clicking ok/next/yes. To retain the key info for more techy or less lazy users, you could use a drop down pane with an arrow.

    Filling in a key is just moving the problem; where could I get the trustworthy key to compare with from? Maybe the linux distro (or the community) could keep a list on the internet of third party repositories without evil intentions, against which the key would be automatically and securely checked. That way the list can be updated regularly too. Most users cannot check the source any better than an entire active community anyway.

  5. Ben Says:

    Idea: widely-used algorithm to display a hash as a color.

    Hashes are designed so a any change in the data produces a big change in the hash, so hopefully the colors would almost always be strikingly different for two hashes.

    For comparing many hashes, this wouldn’t work out as well because the probability of similar colors goes up faster than that of similar hashes, but most common UIs only need a two or three, right?

  6. Abbas Says:

    How about an option to “Trust imported Keys” and a “Always trust imported keys” button in the dialog box which enables this option, that will it can still be secure and only annoying “once” for people that find it annoying, perfect solution to both problems.

Leave a Reply