Use URL Parameters (Invidious, Piped, maybe Nitter) for Private Mode settings instead of cookies. #491
Comments
MintMain21
changed the title
|
I understand the Idea. But Unifying was removed because of the Bugs and Code Complexity it introduced. Using unifying in Private Browsing mode defies the purpose of it cuz Private browsing mode was made for Cookie-less experience. We are sort of sure not to bring unify in Private Browsing mode. This won't happen as there is already unify via cookies in standard and won't be supporting Incognito. |
|
Support for frontends with URL parameters would be really nice The main obstacle I see is that redirecting youtube URLs isn't sufficient for full parameter support—LibRedirect would have to monitor and modify URLs for every single instance. Unreasonably far beyond the project's current scope. I'd be very satisfied with adding parameters to URLs redirected from youtube, though. Would neatly cover the occasional video or embed in private windows. (Are there non-youtube frontends that use URL parameters?) |
|
As far as I'm concerned, YouTube frontends are the only ones that use URL Parameters, and as such are the only ones that should be prioritized. There was an issue on the Nitter Github that referenced the idea of using a singular URL parameter, which insinuated that Nitter already supported URL parameters, but realistically YouTube and Twitter are the only private frontends I want to extensively customize anyway. All the other frontends either don't have enough options to customize as intensively, or have enough variation between instances where I can just choose the instances I like for an ideal experience no matter what. |
|
Entertain just this hypothetical. In my custom Redirector Rules, there are generally three pieces being tossed around. The first piece is whatever instance I want to redirect to. The second piece is the YouTube URL I want redirected. The third piece is the URL Parameters I want applied specifically to YouTube URLs that lead to videos, with a blatant exception rule to avoid applying URL Parameters to URLs that already contain those Parameters. LibRedirect already juggles the first two parts, by keeping an ongoing list of instances to plug into the YouTube URLs, and all that's missing is appending the URL Parameters when redirecting videos specifically. As explained by @umbralOptimatum, that last piece is as simple as a textbox users can add parameters to, with mable a ? icon hiding a table to explain the parameters and the settings they toggle, with both Invidious and Piped having their own individual textboxes and ? icons with their own individual parameter tables. It's not too different from how the extension already stores separate lists of instances for both frontends without overlapping. Maybe I'm foolish to think this could be appended to LibRedirect the way it's currently designed, but LibRedirect is the only extension of it's kind that's competing to be truly comprehensive, so I feel like it's better to pitch this concept than not to all the same. Not to mention, part of what attracted me to LibRedirect in the first place was the promise I could get the experience I want in Private Mode, something Privacy Redirect never even attempted to try. Oh, and another thing. Just as users can toggle whether YouTube and Twitter redirects include embeds or not, so too should users be able to toggle whether the URL Parameters are applied exclusively in Private Mode or if it should be the default behavior even in standard browsing. |
|
From Hygna (in Matrix) : It is not specifically about cookies, but having a clear profile in general in private browsing, unefected by whatever you have in regular browsing. @umbralOptimatum - Piped does support Unify settings. I use it a lot. I am not sure about your issue. @MintMain21 I understand your proposal. The Ideas even hypothetical (according to you) are also great. You are welcome to the matrix room to chat more. |
This argument doesn't make sense to me. Private sessions are independent of regular session data, sure, but not of browser settings and extensions. Making cookies from regular browsing accessible in private browsing would violate this principle. Adding URL parameters with an external tool... doesn't. If editing URLs in private browsing with the same tool as in regular browsing violated their separation, simply using LibRedirect in private browsing would be a violation of good practices, which is clearly nonsense.
Ah, whoops. I don't use Piped myself, I just noticed it uses localstorage and took the FAQ's wording about "unifying cookie settings" at face value. |
|
I think what he means more is that they want to make sure LibRedirect as it currently is is stable before adding new (and dramatic) features like URL Parameters. In any case, this issue is still open, so clearly it's still under consideration. I'll take that win for now. |
|
An update on Nitter URL Parameters. Based on this thread, zedeus/nitter#553 (comment), Nitter does in fact have limited support for URL Parameters, albeit only the theme Parameter (and seemingly only "Light", "Dark", and "Auto". Nevertheless, it is possible to configure Redirector to incorporate them just as it is to incorporate them into Invidious Redirects, albeit the process is more complicated due to how Nitter processes URLs. The ruleset I use to maintain desired rdirects are as follows. Redirect Twitter Search to Nitter Redirect Twitter to Nitter Redirect Twitter to Nitter Redirect Twitter to Nitter Redirect Nitter with URL Parameters (Search) Redirect Nitter with URL Parameters (Tweets) Redirect Nitter with URL Parameters (General) It is worth noting that three of the above redirects were taken directly from the Nitter Github Page, which offers in it's Wiki details on how to configure Redirector for use without taking URL Parameters into consideration. URL Parameters I had to figure out via trial on my own end. (https://github.com/zedeus/nitter/wiki/Extensions#redirector) Furthermore, it can be seen that different Nitter pages demand different redirects with different patterns in order for URL Parameters to register correctly, which would make implementation into LibRedirect more complicated compared to the application of URL Parameters for YouTube or Invidious. Especially seeing as the priority given to one rule could conflict with the needs of another (Hence why these rules are organized in the order they are). I eventually figured out the simplest way to reconcile these differences (usually whether they accept ?url=parameter or &url=parameter) is to make it ?&url=parameter instead. Nevertheless, these options can still be applied to a future build of LibRedirect as well, preferably after the water is tested with a stable feature for YouTube Redirects. |
MintMain21
changed the title
|
Excellent breakdown of the situation, @MintMain21! I think URL parameters would be a healthy middle-ground for all privacy frontends to implement, as they allow for customization while reducing fingerprinting a bit. If Unify Settings truly won't be supported in the future, an "Advanced Redirect Settings" tab in LibRedirect, with "URL -> Privacy URL" and "URL Parameters" fields for customizing our redirects would be greatly appreciated. |
|
I committed a change now, but it has cons and like it's a misuse of the URL Parameters. LibRedirect main goal is for redirections only. After we started modifying things we weren't actually supposed to modify, bugs exploded and many things started to mess up. The same thing will happen now with URL Parameters if we added them. |
|
All I want to do is kill evil autoplay. Without LibRedirect, I can disable autoplay in my browser settings and nothing autoplays. Perfect. But since Invidious doesn't honor that, I have to set every enabled Invidious instance to disable autoplay. Which means turning my privacy measures upside-down by being forced to enable javascript and cookies for every one of the instances, manually disable autoplay on each one, and save a persistent cookie(-ies) to persist that setting. And be forced to go through that anew for every new instance that gets added or enabled in my list of active instances. (And it won't do any good anyway in an incognito session) That's a real pain. So now when I go to some page that has 10 YT embeds, I have to go to each one and pause the video so I don't go nuts just trying to read something on the page, not to mention the pointless data use. (Cannot even set the autoplay on each of those from there, as the Invidious settings menu is not available on embedded YT vids) I realize that if URLs get re-redirected, the parameter idea might not work in some cases. But just adding a field to the extension settings that users can edit which appends that string to any redirected YT URL would be really handy. Thanks |
|
@Sapiosenses I don't know what browser you're using, but as a Firefox user I find Invidious respects my universal "No Autoplay" preference better than say.... Piped does. I would reccomend limiting Invidious redirection to a few Invidious instances that either have "No Autoplay" enabled by default, or respect the browser's "No Autoplay" preference. |
…/browser_extension#491" This reverts commit 2a738e883c5c48207a1f9e737feb3ce53fdd969b.
Earlier this year LibRedirect incorporated saved preferences synced across multiple instances both in standard browsing and in private sessions by loading cookies. As of the time of writing this, Private Mode support was dropped due to how convoluted and frequently broken the implementation was, so invidious preferences are only retained in standard browsing sessions where cookies are stored permanently.
There does exist an alternative way to present these settings in private mode besides cookies however, at least in Invidious.
https://github.com/cloudrac3r/invidious-documentation/blob/master/List-of-URL-parameters.md
Using the above URL Parameters, preferred settings can be maintained without using cookies.
The variety of settings is significant smaller than that which is offered by cookies, but key options are still available including preferred video quality and whether the recommended feed is visible.
Incorporating these settings into a private redirect would be as simple as say, redirecting https://www.youtube.com/watch?v=Q9EspvjWcRs to https://iteroni.com/watch?v=Q9EspvjWcRs&related_videos=false instead of just https://iteroni.com/watch?v=Q9EspvjWcRs
Virtually anything that can be toggled with a cookie can be toggled with a URL Parameter as demonstrated above.
TLDR, I propose reviving Private Mode support for Invidious Preferences using URL parameters instead of cookies, with the option to do the same in standard browsing mode as well should the user prefer it.
For an example of how this would look in an extension, see https://addons.mozilla.org/en-US/firefox/addon/invidioucious/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=search
Additionally, Piped also uses URL Parameters (https://piped-docs.kavin.rocks/docs/parameters/) so this feature could be applicable to at the very least both Invidious and Piped, if not any other private frontend that uses URL Parameters.
The text was updated successfully, but these errors were encountered: