1Password is private by design. We cannot lose, use, or abuse data that we never have. Your data, your business.
There 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
A 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.
Tweet about this post