Privacy Browser Android

Soren Stoutner wrote:

Thanks. That is a good idea.

I think also would be good an option to redirect domains which don't have known frontends to web.archive.org or archive.is.

I am fairly unlikely to ship any sort of pre-populated list, just like I am unlikely to ship a preconfigured list of domain settings. Rather, I would be willing to implement functionality to allow users to create their own redirect rules.

I hope this helps someone, I am already doing something like that:

I do a search for "hello world". In the search results there is a youtube video link. I long press it and select "open in app". Automatically it opens in a new tab using invidious.
The way I did it was by installing NitterizeMe, and selecting it to always open youtube links. Then I select the result to always open in Privacy Browser by default. So, yeah, you can use these two together to achieve it now. It even works for Twitter, Instagram and GoogleMaps.

However, there is still a valid reason to allow automatic redirection of links, as it would allow for a more transparent usage (if by mistake I simply open the link instead of long pressing it, I have already revealed my IP, UA, etc, to the bad actor server). And maybe it could also help to solve this other ticket of mine (two solutions in one I guess?): https://redmine.stoutner.com/issues/502

What do you think Stoutner?
Thanks.

Also, if you want to have a different browser set specifically for usage with invidious and nitter, you can even have those two websites storing cookies or using Javascript without compromising Privacy Browser (since there is a separation between each webview instance and each app own cookies). If you want to use Privacy Browser, you would have to clone the app to the work profile and set different settings in each one. Not as usable.

I assume when PrivacyView comes out there will be no such need, as I suspect you will enable having stuff like Javascript enabled/disabled per-app, correct Stoutner?

This is a specific use case of https://redmine.stoutner.com/issues/502, which is a generalized URL manipulation. I can't think of any good reason to develop them individually, as long as it is fairly easy to perform this task with the general tool.

GNU User wrote:

I assume when PrivacyView comes out there will be no such need, as I suspect you will enable having stuff like Javascript enabled/disabled per-app, correct Stoutner?

I'm not sure I understand the question.

I meant to say "per-tab".
With WebView you can't handpick which cookies you want to delete, if you choose to delete them, you delete them all. (though I believe a workaround for it would be the same that happens in the WebApps application, that uses backup copies to each sandbox).
With WebView you can't have JS enabled for a tab and not for the others (eventually the first one will have JS disabled as well).

Privacy Browser already allows JavaScript to be enabled for one tab and not for another. That is how it was designed from the beginning.

Regarding fine grained cookie management, that is covered by feature request https://redmine.stoutner.com/issues/5. Also, see https://redmine.stoutner.com/issues/356, https://redmine.stoutner.com/issues/409, and https://redmine.stoutner.com/issues/245.

I was convinced when JS is enabled inside an app (Privacy Browser for example) it would be so for all tabs. Maybe I am mistaken.
Anyway like I said we will need PrivacyView for more control over what the browser can and cannot do.
BTW what is the current situation for cookies, are you still planning fine-grained control for 3.x or will it wait until 4.x ?

General question are best handled through something like the forum, instead of in a bug report about a different topic. Regarding cookies, see https://redmine.stoutner.com/issues/5.