Frequently Asked Questions

Why LibRedirect?

Normally, you would watch YouTube videos through youtube.com; problem is, everything you watch is tied to your Google Account. Even if you don't use an account, your IP address is still visible to their server. Even if you use Tor, you still have JavaScript enabled, which can gather all sorts of creepy information about your browser and system – just go to deviceinfo.me or amiunique.org and see for yourself!

So, why not disable JavaScript? Great idea! Now YouTube is broken, as it requires JavaScript to function ¯\_(ツ)_/¯

Fortunately, there's a way to make a script that scrapes data off of youtube.com and presents it in a nice simple webpage that doesn't require JavaScript. People have done this already! There's a project called Invidious that doesn't require JavaScript for you to watch YouTube videos – e.g. https://yewtu.be/watch?v=dQw4w9WgXcQ.

Invidious and others are called alternative frontends, where you're still using YouTube (or another website) but with a different interface, in this case a more privacy-friendly one.

Changing links every time from e.g.
https://youtube.com/watch?v=dQw4w9WgXcQ https://yewtu.be/watch?v=dQw4w9WgXcQ
is an inconvenient process and best to be automated, so we did that!

LibRedirect's main functionality is to make the use of those frontends easier by automating it. It makes life much easier and privacy more convenient.

Suggest a frontend

Requirements:

  1. Open source
  2. Enhances privacy over main site
  3. Can be self-hosted, so it's decentralised

Good examples:

Bad examples:

Why fork Privacy Redirect?

Privacy Redirect hasn't been maintained since 6 December 2021. Many instances are hard-coded. Some should be removed as they've since gone offline and many others should be added. Many pull requests were left pending and waiting, so we stepped in. Later, we started improving it further by adding new features and frontends.

Even though we forked from Privacy Redirect, LibRedirect is now independent, as it is ahead of the main project with several improvements and new features.

Why all those permissions?

Let's examine them one by one:

Where the hell are those instances coming from?

Almost every frontend project has a list of public instances, e.g. Invidious' official instances list and Nitter's official instances list. We fetch those lists using an automated Python script, which gets triggered daily. We neither intercept nor modify the lists outside of removing invalid URLs (i.e. the structure is not that of a URL). They are not our responsibility, they are the projects maintainers'.

Hence, if you are not comfortable with certain instances' policies or have found malicious instances, please report them to the project maintainers to remove them from their lists. We will then update our lists manually to make sure those instances are removed, only after you contact us via our Matrix room or by Mastodon and if the case is of high severity which will affect our users; if not, please wait until the script fetches the instances automatically and removes them.

Embeds aren't working, why?

  • The Webpage you are trying to use may have implemented CSP (Content Security Policy) which prevents Libredirect from replacing them with the frontends.
  • It could be broken because of Top layer in HTML element of the embed that maybe a Custom Video Player or Ads.
  • Some instances doesn't support embeds at all or displaced them explicitly
  • They are disabled by default to not help website in creating a fingerprint on you as websites can detect when you redirect an embed inside it.

    Chrome Web Store?

    We can't publish LibRedirect to the Chrome Web Store as it requires Manifest v3, which removed essential features that LibRedirect needs. However, you can still install it manually.

    We are planning to adopt Manifest v3 in Firefox though, as they will support the features LibRedirect needs. If other browsers adopt Mozilla's Manifest, then you might see LibRedirect in the Chrome Web Store someday.