From time to time I become involved in conversations regarding the integration of Privacy Browser with password managers. The purpose of this post is to place all of my thoughts on this subject in one place, as well as to explain why I consider it insecure to integrate a password manager into a web browser.

First, let’s talk about what a good password policy looks like. I like to refer to this XKCD classic when discussing this topic.

In my years of work in IT, I have had the fairly rare experience of observing how many people select their passwords. Generally, most people do the following:

1. Reuse a small number of short passwords.
2. Have been trained to think that adding weird characters to passwords makes them secure.
3. Save their passwords in a browser password manager, or, if they are elderly, write them in a paper notebook.

On the other hand, in recent years I have seen a trend among tech savvy users to design their password workflow along the following lines:

1. Generate lengthy random passwords for each site.
2. Store these passwords in a third-party password manager that syncs with some cloud service.
3. Integrate the password manager into their browser so it can automatically log them into websties.

I would like to propose a third route that is better than either of these. In doing so, let’s analyze the threats users face with their passwords.

The first threat is that someone is able to acquire knowledge of a user’s password. The most common way this happens is by hacking a fairly insecure website, like a local library system, accessing the list of usernames and passwords stored on that website, and then trying those same combinations on other, more secure websites, like banks. This is called credential stuffing, and it happens all the time. This is why you should never reuse a password.

The second threat is that someone is able to acquire access to your password store. If they get that, they have all the keys to your kingdom (hopefully, you have enabled some form of two-factor authentication for sites that are important, but I will save that conversation for another post). If you sync your password manager to some cloud service, this will probably happen to you sooner or later. In 2020, there was a high profile instance of this with LastPass. There are probably many more of these types of hacks that have gone undetected, and I anticipate they will become much more common in the future.

Let me propose a third method of approaching passwords.

1. Select unique passwords for each site that are several words long. Length gives you all the security you need.
2. Have the password describe some aspect of the website that is easy for you to remember.
3. Store the password in a secure place, like a password manager, that you have backed up in such a way you are unlikely to ever lose it, but which is not synced to a cloud service.

The key to this approach is that passwords are unique for each site, but are also easy for you to type and remember. So, you do not need to frequently refer to your password manager.

For example, the password for your library system might be:

Let me check out a book.

You can make it use standard punctuation and grammar if you like. You can mix words from two languages if you speak more than one. You can add special characters if it makes you feel special.

Years ago, after my wife’s Amazon account was compromised by a contractor working for Amazon who placed a number of false charges on her credit card, and after Amazon was unable or unwilling to shut it down (even after the account was disabled Amazon was still processing fraudulent charges on the card), I changed my Amazon password to be the following.

Amazon sucks.

Easy to remember. Never had to look it up in my password manager. Not even once. That isn’t my current Amazon password, because my wife thought it was funny and told it to our kids one day, so it had to be changed. But I offer it up as an example.

Note that most websites will not let someone try hundreds of bad passwords. Typically a bad actor only gets somewhere between 3 and 10 tries before some additional form of identification is required. So, even something as short as Amazon sucks. is plenty secure as long as it has never been used somewhere else and a bad guy wouldn’t be able to easily guess it in the first ten tries.

One important aspect of this approach is that it eliminates the need to integrate your password manager into your web browser. If your passwords are lengthy random characters that are hard to type, you either need a password manager to fill them directly into the browser or you need to copy and paste them between the password manager and the browser. Copy and pasting can have its own problems as, often, unprivileged malware running on your system can read the clipboard even if it can’t access any data that is in your password manager or your browser. So, moving passwords from one secure environment to another through an insecure channel is inadvisable. Android has made some attempts to address this in recent versions by indicating on the screen the name of any app that pastes from the clipboard as well as clearing the clipboard after a certain period of time. But, if you have easily typeable passwords, even if you are going to a website you haven’t visited in years, all you need to do is open your password manager and look at the password to remember what you selected. Then you can switch back to the browser and type the password.

Which brings me to the main purpose of this post, which is to convince you that integrating a password manager into a browser is dangerous.

Danger, Will Robinson

I have already written about minimizing Privacy Browser’s attack surface. The reason why this is important is that web browsers process untrusted data from the internet. In other words, almost every website you visit is trying to compromise your security and privacy. That comes in the form of malicious data sent from the web server to your browser. Every part of the browser that processes that data is an attack surface. All of those attack surfaces are designed to sort through the untrusted data and remove or ignore anything malicious. But sometimes the browser makes a mistake. The more parts of the browser that process untrusted data–the larger the attack surface–the more likely there is to be some vulnerability the bad guys can exploit.

You can do a lot of things to minimize your attack surface. By far, the largest attack surface in the browser is JavaScript. If you turn JavaScript off you have eliminated probably 98% of your browser’s attack surface. But even when running a minimal attack surface, your browser will eventually be compromised. Period. End of sentence. Always.

In case you don’t believe me, consider that even the NSA operates under the assumption that their own computers have been compromised.

So, not only do I design Privacy Browser to have a small attack surface, but I also design it to have very little post-exploit data. Basically, when the inevitable exploit compromises Privacy Browser, it is designed so that nothing of value is there to be stolen. Privacy Browser is a secure bank vault with no treasures inside.

That is why Privacy Browser is designed to not run too many tabs in the background.

That is why all cache, cookies, service workers, and all other auto-generated data is deleted by default every time the last tab is closed.

That is why I am fundamentally opposed to Privacy Browser ever storing a user’s browser history.

And that is why I am opposed to allowing password managers to integrate into Privacy Browser. If Privacy Browser can directly query your password manager and populate data from it into a web page, then someone who has managed to compromise Privacy Browser through some 0-day exploit could leverage that integration to exfiltrate data from the password manager. A few years ago I dealt with an interesting bug in Privacy Browser Android where a malfunctioning autofill provider on LineageOS was connecting to Google every time a user tapped a field on a webpage in Privacy Browser. In recent years, Google has broken automatic WebView autofill integration, which I consider to be a privacy and security benefit.

If you use passwords that are easy to type and easy to remember, you won’t even miss password manager integration.