[Bug] Unexpected redirections using random instances with Piped and embedded-videos

[stephenhawk8054]

Hi, I'm using Libredirect with Piped and random instances for both embed and non-embed videos. For some reasons in sites with multiple embedded YouTube links, loading the sites sometimes causes redirections to piped websites. It's really random, and sometimes you have to reload the page a few times to see it happens.

The URLs it redirects to can be different too:

https://youtube.com/sw.js?theme=dark&playerAutoPlay=false
https://youtube.com/embed/bHQqvYy5KYo?enablejsapi=1&theme=dark&playerAutoPlay=false

and these links will be redirected to piped instances at the new non-embed site.

For example:

• URL: https://developers.google.com/youtube/iframe_api_reference

• Firefox 97.0, Libredirect 1.3.4 + ublock 1.41.2.

Video for demonstrating the bug (at the end it automatically redirects to youtube.com/embed and goes to piped instance at new non-embed site):

https://user-images.githubusercontent.com/66517106/154398021-c89be321-b5a2-440b-95f4-d5fd17a70f5d.mp4

I'm not sure if it's related to randomizing the links or not. When I changed to just 1 instance, I haven't got the bug yet.

[ManeraKai]

I changed that behaviour in a commit yesterday where you only redirect an offline instance if it was the whole site, so <iframe>s are not included in redirection. It's still weird though that it redirects the whole site when an <iframe> is offline. https://github.com/libredirect/libredirect/commit/e9cfde78804781b25d9b746f5118a00ffe17d958#diff-a68229f23586e2fb9354f62fea2613ff16d337ab20490663b3bd6031d9b19973R95 btw the piped instance that is giving those errors is as of right now is https://piped.mint.lgbt/

[stephenhawk8054]

I see, yup confirm that instance causes the problem 👍

[ManeraKai]

I'll release a new version this day.

[ghost]

Concerning YouTube redirections to Piped instances my advice is to uncheck all Piped instances and keep only the official one : piped.kavin.rocks Two reasons for that : 1- You can change the Piped instance within the Piped instance / Preferences / Instance Selection (last option, page bottom) Keeping an instance requires accepting cookies (though the prefs are kept in LocalStorage/IndexedDB) 2- piped.kavin.rocks makes no 3rd-party connections : some Piped instances call directly Google for its fonts (privacy) and/or piped.kavin.rocks (absurd in a way). Personally I redirect only to pipped.kavin.rocks but have chosen within its Preferences another instance because faster maybe given geographical proximity : piped.kavin.rocks connects only to its own servers and to the other instance's server I've chosen, but all remains within Piped servers, no connection to Google Fonts givenpiped.kavin.rocks hosts the required fonts ...

Concerning Embedded (IFramed) YouTube videos redirections to whatever Piped or Invidious instance, my experience is that there are too many problems encountered for this option to be pertinent over time. Latest LibRedirect 1.3.4 includes now the option to redirect only non-embedded (IFramed) YouTube, and IMO this is truly the best choice for redirecting YouTube. At this time anyway. Embedded (IFramed) YouTube videos increasingly refer to APIs that make the very fact of redirecting them sort of senseless given the aim is to avoid connections to YouTube as 3rd-party servers and that these APIs make these connections obligatory in order to perform the redirection : you think you've bypassed YouTube when in fact YouTube is contacted before the redirection is processed. This is never the case of course with non-embedded (IFramed) YouTube links.

[stephenhawk8054]

I mean it can be for anyone who wants to minimize connections to google, better than connecting to google all the times the embed appears and users watching 🤷 And in the case the site uses plain embedding (not via YouTube Player API), there are no connections to YouTube at all. Remember that not all sites use YouTube Player API. We already have 2 choices, so why bother to try to completely cut the option of redirecting embedded videos for other people who want to use that 🤷 ?

[ghost]

why bother to try to completely cut the option of redirecting embedded videos for other people who want to use that?

I never mentioned that. LibRedirect offers the option and that'a all that counts, IMO

Why redirect YouTube to a Piped instance which connects to Google Fonts severs when the official Piped instance does not? It's up to each of us to consider the meaning of privacy and decide accordingly. Freedom is the master-word. Again, LibRedirect offers as much freedom as its numerous options testify and provide. My advice is not and never worth more than that of anyone else's. Testifying my own experience and advising accordingly, always and only for what it's worth. My 2 cents as thet say in the States :=)

[stephenhawk8054]

I'm not talking about the instances' codes. It depends on users' choices and reports.

I'm talking about embedded situations. Even when there are connections (actually 2 connections) from YouTube when a site uses YouTube API, it still reduces a large amount of other connections (media, log, xhr...) that YouTube can't track and totally can't be equal or worse in privacy than watching YouTube embeds from themselves. If anyone doesn't want to watch embeds at all, they already hard block it in ublock already, and won't ever bother about this case. And there are a lot of sites that don't use YouTube API to embed. So it's totally worth the effort for this situation.

[ghost]

I'm not talking about the instances' codes. It depends on users' choices and reports. I'm talking about embedded situations.

So am I. User's choice, always.

when a site uses YouTube API, it still reduces a large amount of other connections (media, log, xhr...) that YouTube can't track

You've got a point there.

If anyone doesn't want to watch embeds at all, they already hard block it in ublock already,

Indeed. Not my case, but indeed.

there are a lot of sites that don't use YouTube API to embed. So it's totally worth the effort for this situation.

There are an increasing (IMO) number of sites which do.

Synthesis : redirecting embedded (IFramed) YouTube videos is pertinent given a user accepts the hassle of including the problematic sites to LibRedrect's Exceptions module. Be said that by 'problematic' I mean as well sites which use YouTube APIs and bring privacy maybe to ti its knees (given what you wrote) but nevertheless diminish what we may expect from a redirection... as well as the rendering of the IFramed video, which is sometimes long to appear, sometimes fails (noticed only with Invidious instances on a few sites such as euronews.com). From there on, its up to you, and you (anyone else reading?!) and to me.

Thanks for those worthy clarifications.

[ManeraKai]

@Cade66 about unchecking all the instances but piped.kavin.rocks as this instance already talks with other instances and everything is from the client side, your almost talking about a desktop app like freetube. The extension is for redirecting to multiple decentralized sites, freetube is for getting just api information and is the safest option imo. I don't think it supports piped though but it has it's own UI if you're only concerned about that.

[stephenhawk8054]

I mean the worth part includes the reduced amount of connections that YouTube can't track too.

• Reduce large amounts of YouTube's connections and trackings, or
• Completely block all connections when sites don't use YouTube API,

That's why it's worth for anyone who still wants to watch YouTube embeds. And it's always better to help maintainers find some ways to reduce it more, rather than trying to make it look like not worth and abandon it gradually.

[ManeraKai]

About the iframe problem. I hope that someone from either Invidious, Piped, Cloud Tube will make an idea to simulate the api. That would be the perfect solution.

[ghost]

@ManerKai,

[...] your almost talking about a desktop app like freetube.

I've tried Freetube, the Desktop application (Windows here). First, it connects via Windows only, no browser filtering (even if I have strong system-wide filters) ; secondly I encountered occasionally at the time sluggish rendering. I think all instances (and their updates, nice extra feature compared to Privacy Redirect) is welcomed, participates to this freedom we mentioned, but personally I prefer to stick on one or two instance(s) I know, not to mention that instances (Invidious or Piped) have their Preferences which are not all included in a redirection tool such as LibRedirect : this means I choose the instances after having tested them and stick on those and on those only, with allowed cookies for the happy few and redirection performed with no URL parameters (no URL parameters is also specific to LibReddit as Privacy Redirect doesn't offer the choice).

About the iframe problem. I hope that someone from either Invidious, Piped, Cloud Tube will make an idea to simulate the api. That would be the perfect solution

Indeed, be it possible to work around this requisit's implications ...

[ghost]

@stephenhawk8054,

I mean the worth part includes the reduced amount of connections that YouTube can't track too.

That's what I understood/concluded. We're on Firefox. Be noted that your argument is even more pertinent for users who don't block 3rd-part cookies (or even use Firefox's Enhanced Tracking Protection (ETP) which will isolate 3rd-parties but not systematically block them). Personally ETP is set to custom and I block ALL 3rd-party cookies (network.cookie.cookieBehavior=1). This comforts my choice of allowing access to YouTube servers for their IFramed videos, comforts it without totally advantaging it , again because of what you mentioned, even if I still don't know exactly what data is sent to YouTube accessed for IFramed videos and specifically without 3rd-party cookies permission. I understand what you mean, that's extra information for me, but my arguments above mentioned remain the leaders of my choices, even if they are tempered by what you precise.

[ManeraKai]

I've tried Freetube, the Desktop application (Windows here). First, it connects via Windows only, no browser filtering (even if I have strong system-wide filters)

what is that?

[ghost]

@ManerKai,

what is that?

It's a desktop application acting as a YouTube front-end. That's for the joke, lol.

I guess you mean to express your astonishment regarding my comment about Freetube.

Yes, as a desktop application it connects to the Web (to YouTube) by itself without any of the advantages of a browser, those advantages being proportional to its privacy settings. As I wrote above I have strong system-wide protections (there is a Web independently of our browsers!) but I always prefer to use the browser.

Sluggish rendering? I meant halts once in a while, felt 'heavy' compared to the quality and speed of videos accessed within the browser.

Again, no discrimination, only relating my past experience. I might try it again but, generally speaking, i'm not fond of desktop applications which, for some, behave as if they had been built with a browser inside, so to say.

[ManeraKai]

It can connect to invidious instances and randomize every restart

[ManeraKai]

Personally I didn't try it that much. idk if the issues your saying are fixed. they should be though.

[ghost]

It can connect to invidious instances and randomize every restart

You mean that Freetube may access YouTube videos via Invidious instances? That triggers a foggy memory, seems now I remember something about that in Freetube's preferences, not sure, I had tested it some time ago ...

Via Invidious is a privacy guarantee but not a quality rendering one. Already that Invidious doesn't handle correctly some live streams, even when performed from their very sites (i.e. euronews.com (connection:impossible), sometimes france24.com (connection:depends...) -- which I never experienced with Piped instances (the maestro handles them all up to now) --- that I dare not imagine the rendering of problematic LIVE streams when accessed via Freetube via Invidious. Sorry to say, I always prefer nice, positive comments but, hey, let's be frank, not about truth but about our very own, truth, or at least evidence of our experiences, which forbids any generalization, of course.

[stephenhawk8054]

@stephenhawk8054,

I mean the worth part includes the reduced amount of connections that YouTube can't track too.

That's what I understood/concluded. We're on Firefox. Be noted that your argument is even more pertinent for users who don't block 3rd-part cookies (or even use Firefox's Enhanced Tracking Protection (ETP) which will isolate 3rd-parties but not systematically block them). Personally ETP is set to custom and I block ALL 3rd-party cookies (network.cookie.cookieBehavior=1). This comforts my choice of allowing access to YouTube servers for their IFramed videos, comforts it without totally advantaging it , again because of what you mentioned, even if I still don't know exactly what data is sent to YouTube accessed for IFramed videos and specifically without 3rd-party cookies permission. I understand what you mean, that's extra information for me, but my arguments above mentioned remain the leaders of my choices, even if they are tempered by what you precise.

ETP does block youtube cookies in other sites, if you look at the report. ETP Strict is designed to be compatible with login, and still block unnecessary cookies like youtube embeds. Mozilla engineers and arkenfox know this than most people, that's why they recommend it. I don't care about personal configurations, all the details I already said it, and it would be redundant if I mention it again. I just talk about how to help Piped/Libredirect in a more meaningful way.

---

I think this goes beyond the report, so I will close this issue as the reason for the bug is already addressed and won't comment until somebody else has relevant issues/contributions.

[stephenhawk8054]

@ManeraKai Btw, do you think it's a good idea to have a whitelisted URLs/domains feature to disable Piped embed in case there are any sites that have conflicts between YouTube Player API and Piped? Because as I see, there might be many ways a website implementing that API.

Situation would be like this: if a user encounters a website that can't play the embedded due to Piped's and YouTube API conflict, they can put the domain/URL to Libredirect YouTube settings to disable redirecting YouTube embeds just in that site.

If I understand correctly, the Exceptions settings in Libredirect's General just applies to main frame cases (youtube, twitter... main sites), not for sites with YouTube embeds. For example, if I put the URL https://developers.google.com in the Exceptions, the embeds in the link

https://developers.google.com/youtube/iframe_api_reference

are still redirected to Piped's instances.

[ManeraKai]

You can check the only not embedded option in the redirect type. If you want a white list for more advanced stuff. plz open an issue.

[stephenhawk8054]

You can check the only not embedded option in the redirect type. If you want a white list for more advanced stuff. plz open an issue.

Yeah, I think only not embedded is for not redirecting embeds in all sites, so not really in this case. I'll open another issue to be more clear.