Security header

1Password and your browsing habits: What we don’t know can’t hurt you

1Password blueprintThere are some things that we would love to know about people who use 1Password. Some of that information would be useful in improving 1Password, some might just be interesting statistics about our users. Here are a few things we might want to know:

  • What sites are among your 1Password data
  • When, how often, and from which IP address you use 1Password to log in to particular websites
  • Which new Logins you save
  • How often and where you fill credit card data

Knowing such things about our customers would help us focus our development efforts on the things that people want to use most. But here is the point of this article: We do not have that information and we have built 1Password so that it would be hard to even collect that information. Our principle of Private By Design means that we don’t know many things. This is for your benefit.

We have no such data

Despite our curiosity and the usefulness of such data, we have designed 1Password so that we can never see that information. We’ve written before about how our security architecture protects your privacy (see Private By Design and the opening sections of our 1Password for Teams white paper [PDF]), but I will highlight some of its points below.

The importance of knowing nothing

One of our design principles is based on the fact that we cannot lose, use, or abuse data that we never have. We believe that you should be in control of your data and that your use of your data is your business. To the extent possible, we have built 1Password in such a way that not only do we not retain data about your use of 1Password, but we make it hard to even obtain such data.  We have also chosen not to include any in-app analytics tools within 1Password.

Some of this is basic security design. Our design principle isn’t radical in theory, but it can be difficult to implement. For example, our underlying data synchronization system would be much simpler if we allowed ourselves to know which sites you are logging in to when you log in to them. But because we do not want to ever know that information, we have had to put in more intricate machinery.

I should also acknowledge that some of our design principle is motivated by cowardice. We do not want our servers and systems to be heavily attacked, so we have designed our systems such that we have little worth stealing. Our cowardice here works to protect your privacy and your security. Cowardice can be a virtue.

Example: We can’t watch from the Watchtower

1Password WatchtowerA relatively simple example of our privacy mechanism is how Watchtower works in 1Password for Mac and Windows. 1Password does not send a query to our server to ask, “Is site X in the Watchtower database? What does it report?” If we had built it that way, our server logs would be able to determine exactly which sites are in your 1Password data. Instead, 1Password fetches all of the information needed by Watchtower on your computer. Every instance of 1Password is fetching the same data file in a way that does not depend on which Logins you have.

Security designs matter

I would like to step back and look at a picture that is perhaps even bigger than the privacy matters discussed here. Please indulge me in my musings.

We are proud of the overall security design of 1Password, and we certainly like to talk about it. Yet very understandably most people are not going to look at the subtleties of the design and its implications. As a consequence, some of the things that we think are the biggest security benefits of 1Password are invisible to users, and so we occasionally hit you with articles like this.

Sometimes our security design makes certain “features” irrelevant and inapplicable. See Authentication v Encryption for a discussion of one such feature. Sometimes, as in the example of Watchtower described above, it means that we have to work harder to put a feature in place than we would have if we’d used a different security design. But even when we have to work harder, we believe that our security design is the better choice. To maintain a privacy-preserving security architecture we are happy to do the extra work.

14 replies
    • eva
      eva says:

      Hi Trevor,

      And you and your comment are just one of many reasons that I love my job. Thank you for making all of our work a pleasure to do.


    • Jeff
      Jeff says:

      For 1Password (but not 1Password for Teams), you can see a description of what we do know about you here: As you will see, it is remarkably little. We really don’t know whether you use 1Password or not.

      We haven’t yet updated that document to cover what we know for those using 1Password for Teams, where we know considerably more. For example we know that you use Teams, we know how many devices you use it on, we know how many items are in your team vaults and we know when you fetch and share information using 1Password for Teams. We also know who vaults are shared with.

      But even with Teams, we can’t know what sites you have Login items for, we don’t know whether or when you use particular items. So although we do know more about your 1Password for Teams data and usage, we still built it so as to be in a position to learn as little as possible.

    • eva
      eva says:

      Hi Antoine,

      Thanks for the kind words. The feeling is mutual because our customers make us very happy when they are happy to be using 1Password. :-)


    • julie
      julie says:

      No, because we know which rows were used to store which Watchtower items.

      CryptDB is appropriate for preventing the administrator of a database from discovering the contents of the database or which database items are being used. In the case of Watchtower, we create the content, which we then store in the database.

  1. Arun
    Arun says:

    I’ve been waiting for you guys to post how the new versions of 1Password (and Safari/iOS) offer protection against xara. Are you planning to post that soon?

    • Dave Teare
      Dave Teare says:

      Good morning, Arun!

      Apple has provided a great new API for allowing extensions to verify the code signature of the process it is connecting to, which is perfect for protecting against XARA. We have implemented this in the beta version of the Safari extension and have a blog post ready to go when this makes it into the official channel.

      That was the original plan, anyway. Unfortunately we hit a snag and I’m not sure when we’ll be able to promote this feature to the official channel as it has some pretty bad usability issues. We’re still hopeful we can work with Apple to find a solution but for the moment we’re unable to proceed.

      I’ll be happy to press the publish button on that blog post just as soon as we can :)

      Take care,


Leave a Reply

Want to join the discussion?
Feel free to contribute!

What's on your mind?