Privacy Browser Android

You are right in that this, apparently simple feature is quickly turned into a complicated mess when one starts thinking about all the possible URL modifications that the end-user might try to apply. So, I suggest thinking about the simple first steps to begin with.

Removing URL part: basically when that string is located in the URL, it is removed. It is up for the end user to be careful deciding what has to be removed.
Replacing URL part: whenever a certain string appears, it is replaced with another string.
Adding URL part: since we already covered "replacing", adding means basically at the end of the URL add some other string. It could also be done at the beginning of the URL, but maybe start with the end for now.

The same code used for removing Facebook tracking could be used to remove ANY part of the URL string and it shouldn't give any trouble (like I said, it's an advanced feature that leave up to the END USER the responsability of what he is deleting and wether or not the URL will load after).
All this would be a simple extra menu in the "Domain settings" in which you could have "add string" "remove string" and "replace string" options. For a start maybe have only ONE option available for a domain, at the same time.

Of course it's easier to say that do, but I hope this at least shows a clearer path of logic as to how this feature should work (for now at least, of course in the long run one could expect to use wildcards and such, but starting small and simple should help a lot).

This is a general implementation of the specific feature described at https://redmine.stoutner.com/issues/505. Likely one interface will be able to handle both.

There is also some discussion of this topic at https://redmine.stoutner.com/issues/844.

Allow user to use split, replace/replaceAll, slice, splice etc methods. Add this option to Domain list.

I am not sure I understand what you are requesting. However, I should make two points.

1. This feature request is about URL modification, not Domain Settings. If you are referring to Domain Settings, you should create a new feature request.
2. For performance reasons, I am unlikely to implement anything that would require processing regular expressions. Some of the words you are using make me think that perhaps you are requesting something that would fall into that category.

https://en.wikipedia.org/wiki/Regular_expression

Is this feature request for Link Redirection ?

Yes, that is one of the things this will be able to do.

The most basic use case for me, is to redirect YouTube videos to piped. An URL typically youtube.com/watch?v=<video-id> should redirect to piped.video/watch?v=<video-id>. Same goes to other sites. But this is the basic usecase I'm familiar with.

This feature will be able to do that.

I've recently started relying on libreddit for reddit too. Everything from the reddit URL is same, except the base domain part.

For example:
youtube.com > piped.video
reddit.com > safereddit.com

by keeping the root uri same.

That's exactly the type of modification this feature will allow.

Maybe introduce this into Domain settings itself. I think it would be a good idea. Just add a textbox for redirection link.

This needs to be separate from domain settings because it can modify the domain, which could change which domain setting would apply. Doing this in domain settings could easily result in endless loop problems.

Rather, this will be a separate setting that will be applied before domain settings.

We can actually call this as Domain Redirection too. For instance, you can place this at the top of the Domain settings. If set up, grey out all the rest of the configuration for that domain.

That wouldn't accomplish all this feature request needs to do. I think it is best to leave URL modification as a separate interface.

It makes sense for a full fledged implementation of this. But just reminding you that this'll become a very jumbled up situation.
Modify in the sense how ? The author is asking some crazy modification like adding &listen=1&autoplay=1 at the end. This is complicated because it should only be applied if watch? exists. And it's just one example.

I don't think this'll be helpful to anyone and too niche to even begin with. Setting aside #844 to be a very simple FR that tries to achieve a basic thing which is also a very important function to a lot.

@GNU User, Invidious already supports autoplay and listen mode by default. You can turn them on inside settings.
Apart from that, what exactly is this feature request ? How different is this from redirection?

This isn't different than redirection. Redirection is one form of modification. That is why #1052 is closed as a duplicate of this, because they are the same thing. Creating two systems that modify URLs would complicate the code.

Modification other than redirection ? I'm not sure of proper use cases for that. The one in the description is a very bad example.
Modifying root website is the only use case I could see for this. The other use cases are too niche and complicated to implement.

One of the important aspects of developing Privacy Browser is thinking about how other people use the program when making design decisions. Often, I see in your comments the attitude that if you wouldn't use a feature in a particular way, you think that the feature is useless and nobody would use it. Sometimes that is true, but often it isn't.

I would suggest that when you make a comment or suggest a feature you take some time to consider how other people would use the program.

I did think about this specific feature enhancement. Well, if you feel like I'm budging my opinion, I apologize.
Just saying that URL path modification is indefinite vague concept. Whereas redirection is very simple and clear cut. Just redirect the root domain and retain the path.

There are significant privacy benefits to URL modification. For example, consider the hard coded URL modifications already in Privacy Browser.

https://www.stoutner.com/url-modification/

Adding the ability for users to create and control this is a significant part of Privacy Browser's future core feature set. For example, consider the benefits of adding the full suite of Léon's URL modifications directly into Privacy Browser.

https://github.com/svenjacobs/leon

We already have AMP removal and tracking queries removal, which by themselves, are half baked URL modifications. I understand further removal of tracking queries is worth the task. But that's completely an another ball game.

Path modification and root domain redirection are completely different. I think you're putting all eggs in one basket. Redirection is not about eliminating tracking. It's about entirely replacing existing crappy websites with open source privacy friendly anonymous alternative web clients.

The reason I'm persistent about this, is that you've closed #1052 in favour of this, which aren't same at all. Even if you accomplish url modification, it still doesn't help with redirection. Because root domain doesn't come under path.

ask low wrote in #note-25:

Even if you accomplish url modification, it still doesn't help with redirection. Because root domain doesn't come under path.

Perhaps you misunderstand what this feature request will accomplish. URL modification encompases modifying any part of the URL, including the scheme, the authority, the host, the port, the path, the query, the fragment, and anything else that can be considered part of the URL.

https://en.wikipedia.org/wiki/URL

It will most certainly handle redirection.

Greetings. For those who still expecting this feature on Privacy Browser, it should take a while depending on the developer's priorities.
As of now, you can use FOSS Browser for Redirection.

Gaukler Faun also recently introduced per site Domain Settings in v9 (replacing Profiles). So feature wise, FOSS Browser can now actually be a replacement for Privacy Browser.