Feature #505

Add an option to redirect some domains to more privacy-focused alternatives.

Added by Rayleigh Rayleigh 6 months ago. Updated 15 days ago.

Start date:
Due date:
% Done:


Estimated time:


I'd find it a really nice feature if the user could define a redirect in the domain settings.

For example redirecting to as it doesn't require JS or redirecting YouTube to Invidious, a private YT frontend. There's also Nitter, a JS-less Twitter frontend.

It could be implemented in the domain settings or in the global settings.



Updated by Soren Stoutner 6 months ago

  • Assignee set to Soren Stoutner

Thanks. That is a good idea.


Updated by Samanto Hermes 5 months ago

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 or


Updated by Soren Stoutner 2 months ago

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.


Updated by GNU User 23 days ago

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?):

What do you think Stoutner?


Updated by GNU User 23 days ago

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?


Updated by Soren Stoutner 23 days ago

This is a specific use case of, 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.


Updated by Soren Stoutner 23 days ago

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.


Updated by GNU User 19 days ago

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).


Updated by Soren Stoutner 18 days ago

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


Updated by GNU User 16 days ago

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 ?


Updated by Soren Stoutner 15 days ago

General question are best handled through something like the forum, instead of in a bug report about a different topic. Regarding cookies, see

Also available in: Atom PDF