Stoutner - Redmine: Issueshttps://redmine.stoutner.com/https://redmine.stoutner.com/favicon.ico?16699090422024-02-26T06:46:16ZStoutner - Redmine
Redmine Privacy Browser Android - Feature #1175 (Feedback): Move out Images into the main menuhttps://redmine.stoutner.com/issues/11752024-02-26T06:46:16Zask lowPrivacy Browser Android - Feature #1170 (Feedback): Option to save and add multiple custom user a...https://redmine.stoutner.com/issues/11702024-02-18T22:55:53ZRon Weasley
<p>Hey, I've been really liking your browser so far with all the privacy features. And I think it'll be more privacy friendly if we can store/save multiple custom user agents (You can name using a custom name or using custom user agent 1,2,3..) and change them on the go.</p>
<p>I usually change my user agent between different sites to better obfuscate my identity. But it's hassle to copy and paste everytime, So if it'll be helpful to users like me who changes the user agents often if the browser could store them.</p> Privacy Cell - Bug #1158 (Feedback): random spurious backgrounded crasheshttps://redmine.stoutner.com/issues/11582024-01-23T20:40:42Zw tango
<p>remarkably useful app!</p>
<p>was running very reliably on Android 13 + OneUI 5.1 on Samsung SM-S908U (S22 Ultra) continuously for up to 30 days.</p>
<p>post-Android 14 + OneUI 6.0 [29nov2023-present], background service spuriously & randomly crashes, gracefully w/ notification, after a minmum of 1 day running AOK, typically after 2+ days running. only relaunch is required to recover. not Force Stop or even Clear Cache. kind of annoying, but not a total showstopper.</p> Privacy Browser Android - Bug #1106 (In Progress): New intents sometimes aren't loaded on restart...https://redmine.stoutner.com/issues/11062023-10-18T20:53:45ZSoren Stoutnersoren@stoutner.com
<p>When restarting from a new intent, sometimes the old tabs are restored but the new URL isn't loaded.</p> Privacy Browser Android - Bug #1076 (Feedback): MHT files open blank until refreshedhttps://redmine.stoutner.com/issues/10762023-08-30T16:33:28Zv ...
<p>When I tap on a MHT file (with <code>.mht</code> extension), which I previously saved with Privacy Browser, in Android's default "Files" app (also called "DocumentsUI", <code>com.android.documentsui</code>), it doesn't give me the possibility to open the file with Privacy Browser.</p>
<p>I saw in the app's configuration that it should work with <code>.mht</code> extensions, but don't know why it doesn't, and if this is specific to my device for this app.</p>
<p>I installed <a href="https://f-droid.org/packages/com.oF2pks.jquarks/" class="external">jQuarks viewer</a> to test on it, and it works.</p> Privacy Browser Android - Bug #1067 (In Progress): App bar URL doesn't refresh on broken internet...https://redmine.stoutner.com/issues/10672023-08-16T23:19:44Zv ...
<ol>
<li>Go to a web page ;</li>
<li>Turn off your internet connection ;</li>
<li>Click on a link in the web page previously loaded ;</li>
<li>Because there is no internet connection, the WebView is showing us that the link we clicked on is not available (normal) ;</li>
<li>However, the URL bar continues to display the previous URL (the bug) ;</li>
<li>Turn on your internet connection ;</li>
<li>Tap to the refresh button ;</li>
<li>The URL used to refresh the page is the last one, which previously has not been resolved, and not the displayed one. So, it only seems to be a bug relative to the view.</li>
</ol>
<p>I suppose the refresh of the URL bar is done after the URL is resolved. Therefore, to fix that, the refresh has to be done before the possibly resolution of the domain name.</p>
<p>See the attached screenshot.</p> Privacy Browser Android - Bug #955 (In Progress): I2P is not recognized as a valid top-level doma...https://redmine.stoutner.com/issues/9552023-01-10T17:21:01Zk k
<p>Proxy - i2p, Tor</p>
<p>Tor - If a web address is w/o prefix 'http:// or <a class="external" href="https://'">https://'</a> PB redirects automatically to 'https://'. <br />It should remain 'http://'.</p>
<p>i2p - <br />1. Using i2pd with 'I2p proxy', PB shows the alert that there is no i2p app. i2pd is the i2p client which fully implements all I2P APIs.<br /><a class="external" href="https://geti2p.net/en/about/alternative-clients">https://geti2p.net/en/about/alternative-clients</a></p>
<p>I recommend that i2pd should be recognised by PB as i2p app.</p>
<p>2. Using 'I2p proxy' or 'custom proxy' as advised here <a class="external" href="https://www.stoutner.com/proxy-syntax/">https://www.stoutner.com/proxy-syntax/</a>, if you use a web address w/o prefix 'http:// or <a class="external" href="https://'">https://'</a> PB tries to connect with a search engine via i2p outproxy. PB should try to connect with the provided address using default prefix 'http://'</p> Privacy Browser Android - Bug #814 (In Progress): The Waiting for Orbot message is not being dism...https://redmine.stoutner.com/issues/8142022-03-06T04:20:24ZAir Yes
<p>When toggling thw proxy setting to TOR in PB notification "waiting for Orbot to connect" appears and can be removed by clicking anywhere else on the screen, but pops up again if you leave-return to PB. Orbot is running. And PB is being routed through TOR, I can tell by WebRTC leak being fixed.</p>
<p>Also interesting observation. WebRTC leak still happens when rules in Netguard are not applied to PB and/or allowed for current devices connection.</p>
<p>So to fix the WebRTC leak PB has to have TOR toggled on, and be blocked in Netguard.</p> Privacy Browser Android - Feature #721 (Feedback): Consider adding a lock screen on startuphttps://redmine.stoutner.com/issues/7212021-05-27T17:10:43ZSoren Stoutnersoren@stoutner.com
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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. <<a class="external" href="https://support.google.com/nexus/answer/2865483">https://support.google.com/nexus/answer/2865483</a>></p>
<p>The second class of attacks has to do with sophisticated hacking devices, like those made by Cellebrite. <<a class="external" href="https://www.cellebrite.com/en/ufed-premium/">https://www.cellebrite.com/en/ufed-premium/</a>> 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. <<a class="external" href="https://www.stoutner.com/privacy-browser/core-privacy-principles/">https://www.stoutner.com/privacy-browser/core-privacy-principles/</a>> But there is still some information there, including the list of bookmarks and domain settings.</p>
<p>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.</p>
<p>Hence, any defense against a Cellebrite attack needs to both implement a lock screen and encrypt the app data at rest.</p>
<p>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.</p>
<p>But lets assume that I become convinced that this feature is worth all the effort and do implement it. What would it look like?</p>
<p>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. <<a class="external" href="https://developer.android.com/training/articles/keystore#HardwareSecurityModule">https://developer.android.com/training/articles/keystore#HardwareSecurityModule</a>> These hardware security modules are supposed to be unhackable. But, surprise, surprise, they aren't. <<a class="external" href="https://thehackernews.com/2019/11/qualcomm-android-hacking.html">https://thehackernews.com/2019/11/qualcomm-android-hacking.html</a>> 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. <<a class="external" href="https://security.stackexchange.com/questions/45318/how-long-in-letters-are-encryption-keys-for-aes">https://security.stackexchange.com/questions/45318/how-long-in-letters-are-encryption-keys-for-aes</a>></p>
<p>Do you know any user who would be willing to type a 24 character serial number every time they opened Privacy Browser?</p>
<p>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?</p>
<p>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.</p>
<p>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.</p> Privacy Browser Android - Feature #633 (Feedback): Restore edits in the URL bar when switching tabs.https://redmine.stoutner.com/issues/6332020-10-14T17:35:36ZSoren Stoutnersoren@stoutner.com
<p>Currently, the URL that is loaded in the WebView is restored to the URL bar when a tab is switched. This means that if the user has modified the URL, then switches tabs, then switches back, their edits are lost.</p>
<p>I am not certain I want to change the current behavior. I have created this feature request to see what feedback I receive from users about the issue.</p> Privacy Browser Android - Feature #631 (Feedback): Undo a closed tabhttps://redmine.stoutner.com/issues/6312020-10-08T19:40:08ZGNU User
<p>When closing a tab (which can happen by accident) a message could appear stating "Tab was closed" and have an undo button. Similar to what Firefox has. I didn't find a ticket opened for this, if it's a duplicate I apologize.</p> Privacy Browser Android - Feature #626 (In Progress): Snackbars are too high on the screen if And...https://redmine.stoutner.com/issues/6262020-09-19T03:22:35ZSoren Stoutnersoren@stoutner.com
<p>I expected this to be fixed in Android 11, but it isn't. Perhaps there is something that can be done at the app lever.</p> Privacy Browser Android - Feature #508 (In Progress): Activate Keyboard incognito modehttps://redmine.stoutner.com/issues/5082019-11-05T18:46:39ZLukas ThyWalls
<p>Using Firefox Focus, i realized using this kind of mode (As well as incognito mode in Firefox Android, Firefox Fenix or Chrome) the keyboard enters in some kind of "Incognito mode" that seems to not remember any word (at least), something that happens with GBoard and AnySoftKeyboard as far as i tested it. With both uses this mode automatically with the browser's mode, although with AnySoftKeyboard you can toggle it at any moment.</p>
<p>This doesn't happen in Privacy Browser, with or without incognito mode. The request is activate the virtual keyboards in that mode, if it's posible with an option to make it work "Always" or "Only in incognito mode".</p>
<p>Thanks.</p> Privacy Browser Android - Bug #219 (In Progress): Bookmarks context action menu doesn't work righ...https://redmine.stoutner.com/issues/2192017-11-07T02:29:09ZSoren Stoutnersoren@stoutner.com
<p>In German, the bookmarks context action menu does not initially display the move down option.</p>
<p>Selecting a second bookmark and then de-selecting it cuases the move down option to display. So does rotating the screen.</p>
<p>I have no idea why this happens and no idea why it only affects German. Hopefully it is something silly in the Android build or support libraries that gets fixed with time.</p> Privacy Browser Android - Feature #142 (In Progress): Hide the keyboard when displaying the optio...https://redmine.stoutner.com/issues/1422017-06-08T23:25:55ZSoren Stoutnersoren@stoutner.com
<p>The same way it is hidden when the navigation menu is displayed.</p>