Programs that respect your privacy

Core Privacy Principles

Privacy Browser adheres to two core privacy principles.

  1. Minimize the amount of information that is sent to the internet.
  2. Minimize the amount of information that is stored on the device.

Let me explain why both of these are important and how they effect which features are included in Privacy Browser.

Minimize the amount of information that is sent to the internet

The fundamental reason why it is so easy for websites to track you is because your browser sends far, far, far too much information to the internet. Sometimes this is because someone thought up a neat feature that, as a side effect, allows websites to track you. Other times these features were specifically designed to track users. But the end result is the same: websites can track you despite almost everything you do to stop it.

At a very basic level, websites only need two pieces of information to send you a webpage.

  1. The URL you are requesting.
  2. The IP address and port number the response should be sent to.

If the website requires a login, this is expanded to three pieces of information.

  1. The URL you are requesting.
  2. The IP address and port number the response should be sent to.
  3. A cookie that demonstrates you have correctly been authenticated (there are no other valid uses for cookies, in my opinion).

They don’t need anything else. They don’t need JavaScript. They don’t need to know your user agent. They don’t need to know anything about your screen size. They don’t need to probe the specs of your graphics card. They don’t need to read your accelerometer. They shouldn’t get to control tabs, or system popup boxes, or track your mouse position, or what you are typing before you send it to them. They shouldn’t know how you display the information they send you. They don’t need to do any of these things.

Now, for every one of these items above, and hundreds of other examples, there is some genuinely sincere web developer out there who says, “But I can build this really cool website if I just have access to that information.” That may be true, but either there is some way to build that same website (or one just as good) without spying on you, or, as a user, you should make a conscious decision to enable some dangerous permission for that domain because you trust the web developer. None of this stuff should be on by default.

There is an outside argument that can be made for also sending the language of the device, so that websites can automatically switch languages to match. Maybe. But from a privacy perspective it would be better to just include the language in the URL.

Another way of saying this is that I think the browser should be a limited client instead of a general computing platform. This philosophy is in direct opposition to that held by Google or Mozilla, who believe that the browser should be the operating system. The reason why that is a bad idea is because a browser is designed to process input from untrusted third-parties and so it should be very limited in what it allows those untrusted third-parties to do, where an operating system is designed to run trusted code that a user with appropriate authority has installed, so it should allow those trusted programs to do powerful—and therefore potentially dangerous—things. One application of this principle is that I have no intention of creating a plugin framework for Privacy Browser. Although some plugins do useful things, more frequently they do things the user would never approve of it they knew what was going on.

Because Privacy Browser is currently based on Android’s WebView, there is a limit to how much information I can choose not to send to the internet. But in the 4.x series I am going to create a rolling fork of WebView called Privacy WebView, and that is when it is going to get serious. Among other things, this means I am going to break a whole bunch of RFCs that govern how the internet is supposed to work. I am normally very supportive of open standards, and I do not advocate breaking them lightly. But, because the internet has been built from the ground up to track us, and because this tracking has been baked into the core internet standards, overriding them is the only way to reclaim our privacy. In other words, if there is ever a conflict between privacy and a web standard, privacy will always win out (WebRTC being an example that is understood by a lot of people).

This is unlikely to make me popular with web developers. But my end goal is for Privacy Browser to gain sufficient market share so that web developers start making their websites function well without spying on us, and so that other browsers also start adopting this philosophy.

Minimize the amount of information that is stored on the device

Most browsers store massive amounts of information on your device. This information can then be abused by third parties. There are a long list of incidents of websites being able to extract browsing histories by abusing cache timing, or cookies, or other stored information that was supposed to be private.

As a general guideline, Privacy Browser does not store anything permanently on the device unless there is specific user interaction to do so. The Service Worker directory is deleted after every page load. Everything else is wiped when Clear and Exit is selected from the navigation menu or the last tab is closed. Privacy Browser allows users to store bookmarks and domain settings across app restarts, but users do not need to take advantage of these features if they do not want to use them.

For people who need extreme privacy in this regard, there is an Incognito Mode that wipes the cache and history every time a webpage finishes loading. For a human rights worker in an oppressive regime, where visiting a forbidden website could be the difference between life and death, this can be worth the usability trade off.

From time to time I receive requests to add features to Privacy Browser that automatically store comprehensive histories across reboots or restore tabs on a restart. Although I can see the usefulness of such features, I am opposed to anything that automatically stores a browsing history just by engaging in normal browsing behaviors. Doing so makes it easy for malicious apps or devices made by companies like Cellebrite to extract browsing history from user devices without consent. As such, these type of features are unlikely to ever be implemented.

Last updated

6 responses to “Core Privacy Principles”

  1. Dear Privacy Broswer Developer,

    I want to ask you a question regarding your movements towards Private browsing. I totally agree with your arguments regarding the roll of a browser, however, i have a suggestion that I wanted to hear your own option on.

    You had stated that a broswer’s role should only be to send and receive only what is required for you to search the web, log in , etc. But if you were to develop a browser that other features which were open source, that did not communicate over the internet, and did things such as disabling ads or recording your browser history but encrypting the file and not sending it over the internet, wouldn’t you not only support private browsing, but also push for safer extensions?
    Because if we can do this, then not only would we have more protective private browsing, but also be able to compete against major companies such as Mazola and Google, and we would also end up promoting other private browsers such as Vivaldi, which have taking steps to ensure that you get a similar experience of chrome, but with complete customization and pushing against tracking by allowing you to decide if you want to send your location, history, etc.?

    I hope to hear back from you

    1. Soren Stoutner

      This is a very good question and deserves a comprehensive response.

      There are several different attack surfaces that Privacy Browser is attempting to protect against. One of them is what happens when a website is able to compromise the browser and execute code in the context of the browser’s processes. In that scenario, the website would be able to access all the files that Privacy Browser has access to. It would be able to read all the RAM that Privacy Browser can read. It would be able to access any encrypted files that Privacy Browser creates because it would have access to the same decryption keys as Privacy Browser.

      By far, the largest attack surface for a website to gain this access is to exploit a flaw in JavaScript But it could also be possible for such flaws to exist in image codecs, or in CSS parsers, or in any number of other places.

      I would assume that at any given time there are thousands of undisclosed and unpatched browser 0-day vulnerabilities that are being actively exploited by governments and other organizations. For example, the NSA directly went after the Tor browser and were able to compromise those using it Therefore, it isn’t a question of if Privacy Browser is attacked in this way, but how many times per day it is happening.

      Privacy Browser is designed to make it hard to compromise, but it is also designed so that when it is compromised there isn’t much data there to steal. Domain settings and bookmarks can provide some indication of websites that users frequent. The current URL history for each open tab is available. Privacy Browser’s cache and cookie database can be mined. All of Privacy Browser’s private files can be read, but the public file locations cannot if the storage permission has not been granted on Android 6.0 and newer.

      Every time Clear and Exit is run with the default settings the cache and cookie databases are wiped. If you run Clear and Exit frequently during the day, any successful exploit of the browser will provide only whatever long-term information can be gleaned from the domain settings and the bookmarks.

      All this comes down to the issue that there is often a tension between desirable features and privacy. Running a truly private browser is not very convenient. In trying to balance usability and privacy, I come down heavily on the side of privacy, while still incorporating as much usability as I can. At the end of the day, there are already plenty of browser options out there that don’t take privacy and security seriously. There ought to be at least one option that does.

  2. Dear Privacy Broswer Developer,

    This question is somewhat similar to this topic, but it may diverge so I hope you don’t mind.

    In this article you mentioned the dangers of Javascript and I totally agree with you. But what I would like to know is that does this apply to all DHTML elements? Such as pip, ruby, jquery, etc.? And if it does could you explain how for each one? And from my research I read that in order for you to log in, you need something similar to PHP to log in, which is under the umbrella of DHTML. So if you could explain to me what to do in this case I would greatly appreciate it.


    1. Soren Stoutner

      Dynamic web pages (including pages that have a login system) need to have scrips that run somewhere. These scripts can be run on the server, on the client (browser), or in both places. The only scripting language that all browsers run natively is JavaScript. Servers have a lot of options, including JavaScript, PHP, Ruby, etc. From a privacy perspective, it doesn’t really matter to the browser which language is being run on the server. But when the server wants the browser to start running JavaScript there are significant privacy implications.

  3. David


    “Running a truly private browser is not very convenient.”

    Do you think that it’s feasible for a private individual to use your Privacy Browser as his ordinary everyday browser?


    1. Soren Stoutner

      Yes, I use Privacy Browser the majority of the time on Android, although I do keep other browsers around if needed (mostly for testing purposes in my case). Privacy Browser PC currently isn’t mature enough for most of my browsing on Linux, but I expect that to change in the next few years.