Feature #502
openCreate a user configurble URL modification
0%
Description
(finally able to activate my account)
I would see as a good feature to have URL manipulation done automatic by the browser, based on domain rules.
Case in point, Invidious
It could turn this: https://invidio.us/watch?v=Yw6u6YkTgQ4
into this: https://invidio.us/watch?v=Yw6u6YkTgQ4&listen=1&autoplay=1
which would make it possible to, without using cookies or javascript, always have invidious play only the sound and start playing on its own. Other options are available this is only an example. I also think other websites might have some tweaks that would be interesting to use this feature.
Also, I see it as a fitting feature for the 3.x version, since the browser already does URL manipulation (to remove facebook tracking and such). Meaning it would hardly require Privacy View. Please correct me if wrong.
Thanks.
GNUser
Files
Updated by Soren Stoutner about 5 years ago
- Subject changed from Allow URL modification automatically by domain to Create a user configurble URL modification
- Assignee set to Soren Stoutner
Currently there are only a few preset URL modifications, and all of them remove sections of the URL. I can envision a lot of good reasons to provide for user created URL modifications, like the one you mentioned above. These would allow for both adding and removing sections of the URL, and could be domain specific.
Note that this gets quite complicated rather quickly. Beyond building a user interface to allow users to create and manage these modifications, there are also considerations about how to apply these to URLs, what to do if there are multiple modifications being applied at the same time (when there are both additions and deletions), and controlling if they are applied to resource requests as well as base URLs. All of these are surmountable problems, but it means that I will likely push this off until near the end of the 3.x series.
Updated by GNU User about 5 years ago
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).
Updated by Soren Stoutner over 4 years ago
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.
Updated by Soren Stoutner over 2 years ago
There is also some discussion of this topic at https://redmine.stoutner.com/issues/844.
Updated by राही अखेराजोत over 2 years ago
Allow user to use split, replace/replaceAll, slice, splice etc methods. Add this option to Domain list.
Updated by Soren Stoutner over 2 years ago
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.
Updated by ask low over 1 year ago
Is this feature request for Link Redirection
?
Updated by Soren Stoutner over 1 year ago
Yes, that is one of the things this will be able to do.
Updated by ask low over 1 year ago
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.
Updated by Soren Stoutner over 1 year ago
This feature will be able to do that.
Updated by Soren Stoutner 8 months ago
That's exactly the type of modification this feature will allow.
Updated by Soren Stoutner 8 months ago
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.
Updated by ask low 8 months ago
- File domain redirection.png domain redirection.png added
Updated by Soren Stoutner 8 months ago
That wouldn't accomplish all this feature request needs to do. I think it is best to leave URL modification as a separate interface.
Updated by ask low 8 months ago
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.
Updated by Soren Stoutner 3 days ago
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.
Updated by Soren Stoutner 2 days ago
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.
Updated by ask low 1 day ago
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.
Updated by Soren Stoutner about 17 hours ago
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.
Updated by ask low about 12 hours ago
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.
Updated by Soren Stoutner about 12 hours ago
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.
Updated by ask low about 12 hours ago
I interchangeably use "URL" and "link". What I meant was the latter. Caz redirection involves only the link, specifically just the domain. Not the other URL aspects.
I thought about #1052 because redirection is the most common use case to avoid social media in favour of read only privacy friendly frontends.
Seems like you're clubbing it with URL which requires extensive work that might take a lot more time for you to code. That's why I was persistent with separating them both, because I use FOSS browser in tangent to PB, just caz it has redirection. On PC, libredirect
does the job for me.