Feature #721
Updated by Soren Stoutner over 3 years ago
From time to time I receive requests to add a startup lock screen to Privacy Browser. The purpose of this feature request is to document why I consider this to be privacy theater, but I am going to leave it open awaiting feedback. If someone can provide an example of how this would actually be beneficial than I will look into implementing it. The reasons why I don't think it is useful is broken into two categories based on attack scenarios. In the first scenario, standard Android OS tools already provide as much protection as adding a custom lock screen could do. And I am generally unwilling to replicate tools that already exist in the OS if there isn't any benefit in doing so. Consider the following scenarios. 1. You set your phone down on the table and someone with malicious intent picks it up with the desire to see sensitive information in your browser. Solution: Use the lock screen functionality available in the OS. You have all the standard options (PIN, pattern, password, fingerprint, etc.). Implementing a specific app version of this provides no additional security beyond what the OS provides. 2. You want to share your phone with someone, like a child, that needs to have limited access to some features, but you don't want them to have access to what is in your browser. Solution: Use the profiles functionality built into the OS. If you want the person to have ongoing access, setup a profile for their account. If they only need one-time access, they can use the guest profile. <https://support.google.com/nexus/answer/2865483> The second Another class of attacks has to do with sophisticated hacking devices, like those made by Cellebrite. <https://www.cellebrite.com/en/ufed-premium/> These are designed to bypass the lock screen of the device, so the OS protections described above are insufficient. This is one of the reasons why the Privacy Browser's core privacy principles include storing a minimum of information on the device. <https://www.stoutner.com/privacy-browser/core-privacy-principles/> But there is still some information there, including the list of bookmarks and domain settings. The first thing that is important to understand about this scenario is that adding a lock screen that displays to the user when they open the app doesn't encrypt or otherwise protect the actual data. All it does is show a screen to the user that is a little difficult to bypass before they can view the unencrypted data that is available in the app's private directory. Because systems like Cellebrite aren't interested in silly screens presented to the user (they are already bypassing the OS lock screens) they also wouldn't even notice that Privacy Browser had a lock screen. They would just bypass it and read the unencrypted app data directly. Hence, any defense against a Cellebrite attack needs to both implement a lock screen and encrypt the app data at rest. Before going any further, let me impress upon your mind how incredible difficult this process would be. Android expects the data in an app's directory to not be encrypted. All the standard tools expect to be able to access it directly. Encrypting it is possible, but it would require replacing every standard Android function in Privacy Browser with a custom implementation. The amount of work this would take would be staggering, the number of bugs it would introduce would be enormous, and the ongoing maintenance cost would be excessive. But lets assume that I become convinced that this feature is worth all the effort and do implement it. What would it look like? First, users wouldn't be able to use a PIN or a pattern or a fingerprint to open the lock screen. This is because the amount of data contained by any of these is not sufficiently large to provide useful encryption. In typical Android usage, when you enter a PIN or scan your fingerprint, those are checked against what is stored on the system, and, if they match, the actual encryption key is retrieved from Android's Keystore in a hardware security module. <https://developer.android.com/training/articles/keystore#HardwareSecurityModule> These hardware security modules are supposed to be unhackable. But, surprise, surprise, they aren't. <https://thehackernews.com/2019/11/qualcomm-android-hacking.html> And you better believe that there are a number of 0-day vulnerabilities in these hardware security modules that companies like Cellebrite are actively leveraging in the wild to extract encryption keys. The only way to protect against this level of attack is for the user to manually enter the decryption key every time the app starts. To have any real level of security, the key needs to be really long. Somewhere between 24 and 44 characters, and that is if you are using a random mix of numbers and letters that is difficult for a human to remember or type. <https://security.stackexchange.com/questions/45318/how-long-in-letters-are-encryption-keys-for-aes> Do you know any user who would be willing to type a 24 character serial number every time they opened Privacy Browser? Beyond this, Cellebrite devices can also hack information stored in RAM. When Privacy Browser is running, the information in RAM has to be unencrypted. Therefore, to attain any level of security, Privacy Browser would have to clear everything from RAM every time it was paused (another app is displayed on the screen, the screen shuts off, etc.). This means that every time you switched apps, opened a link from another app, shut off your screen, or any similar activity, you would have to type in your 24-44 character encryption key again. Once again, can you imagine any user actually doing this? So, looking at this, I see a feature that would take tens of thousands of hours to implement in any way that wasn't privacy theater, and that nobody would actually use. For anyone who is concerned about attackes by Cellebrite or similar devices, I would recommend that you enable Incognito Mode (which wipes the cache and history every time a website loads), run Clear and Exit frequently, and not store anything sensitive in bookmarks or domain settings. This provides you with almost the same level of protection as a fully encryption system described above, and has the added benefit of being something that you would actually be willing to use.