iccub
commented
2 years ago Thanks for the feedback, we plan to have it but the work is not scheduled yet.
In the existing implementation each website redirection has two rules we then use to decide whether we redirect or not
- A list of domains and subdomains to redirect to, like [
m.reddit.com,i.reddit.com], in the custom implementation I would prefer the user to enter all subdomains manually. Maybe we could consider a wildcard option to grab them all. - A list of domains we do not redirect to, like [
new.reddit.com] this allows you to bypass the redirection without any UI or toggles. Downside is that not many websites are going to have such domain
For the looped domains as long as every rule is added locally, not a problem imo. But as you said, there should be a way to detect such conflicting rules.
Rule sharing is unlikely, it's not popular feature enough. Rule import/export more likely
distbit0
DEFCON001
davidcollini
bigc0127
specter78
Brave iOS contains a "Website Redirects" tab in settings, however it only contains two redirects; "reddit.com" -> "old.reddit.com", and "npr.org" -> "text.npr.org". This is awesome, but it would be great if users could add custom redirects. I currently have a bunch of iOS shortcuts I made myself to manually manipulate url domains before opening brave with the new link, but its very cumbersome, messy, slow, and dependent on the Apple shortcuts app.
Implementation Details
The UI could be implemented similar to the "Custom-Search Engines" UI, and show the logos rendered from The "redirected to site" (so you don't need to render the logos of sites you don't want to access), and a "Add Custom Website Redirect" option at the bottom. Each Redirect box should have the name "domain to redirect -> domain redirected to", and be simply deleted by swiping it (same way it works in the search engines UI). However also adding a seperate settings tab and toggle options to temporally disable and enable specific redirects might be useful to users for things like diagnosing issues (like in the "Quick Search Engines" UI), this would also allow for you to add the current old reddit and npr redirects disabled by default (please allow the user to delete them if they want, as they may contribute to clutter for some users, this is an issue with the Quick Search Engine UI, but the project needs to keep them there, so it makes sense in that specific implementation). (Custom-Search Engines UI):
(Quick Search Engines UI):
The Actual UI for adding a new redirect could be like the "Add Custom Search Engine" tab, having a "Domain to redirect" and "Domain to redirect to" boxes, and a description of any of the specific syntax required in the redirects.
(Add Search Engine UI):
Additional information
"reddit.com" -> "old.reddit.com" "old.reddit.com" -> "reddit.com"Depending on how the backend logic works and if the app is running on a single thread, this may cause an infinite loop that could crash the program every time it is launched, so this behaviour should be tested.
Three ways to defend against such behaviour are:
"youtube.com" -> "placeholder_domain", "m.youtube.com" -> "placeholder_domain" "placeholder_domain" -> "final_location"You can use the placeholder_domain like a pointer, this is useful for redirecting to services like invidious when the instance dies, rather than changing every single different type of domain manually to the new instance you just change where the placeholder domain points.Future/Further Implementation Details
It would also be nice to be able to re-route embedded site information, this done by programs like "libredirect" which is able to redirect embedded youtube videos to privacy respecting alternatives like piped, which are also capable of embedding youtube videos. However this may be more complex if you are applying these redirects to only user visited sites, rather than all browser fetched content.
Implementing an import/export system for redirects could allow users to produce and share the redirect lists that they produce, however extensive protections should be put in place so malicious lists cannot be produced to cause the issues described above. If the system only checks for redirect loops when the user manually imports them, imported scripts could be used to cause local denial of service attacks to the browser. They could also be used for phishing attacks, so some sort of scanning for local on device blacklisted domains (in brave's local block lists for example), could be an additional protection, without having to query an external server.