Home Download Source Code Contact FAQ Docs Donate

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 Piped'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?

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.

Why can't LibRedirect migrate to Manifest V3?

There are two ways to redirect URLs:

  1. webRequest (Manifest V2): Runs JavaScript code that listens to the ongoing HTTP requests in the background, and blocks or redirects them.
  2. declarativeNetRequest (Manifest V3): Sets a Rules Table. This table gets updated when you change the settings page for example. The table gets submitted to the browser. Then, the browser will listen to ongoing HTTP requests, and decide what to do according to the table.

According to mdn

The declarativeNetRequest API evaluates network requests in the browser itself. This makes it more performant than the webRequest API, where each network request is evaluated in JavaScript in the extension process.

webRequest and declarativeNetRequest are for listening in the background only.

Examples of listening to ongoing HTTP requests in the background

In the popup, we have some buttons to help with:

All these buttons do NOT need webRequest nor declarativeNetRequest, as the popup is not a background script. The user opened it manually, and pressed the buttons manually.

There are two places where webRequest works and declarativeNetRequest doesn't.

  1. Selecting a random instance from a set of favorite instances for each new HTTP request:

    In declarativeNetRequest, the user can only redirect to a single instance that is hard-coded in the Rules Table. In order to change this instance, you need to update the Rules Table. You can't change it in the "background".

  2. Sending a separate HTTP request to get some information before redirecting to the new URL:

    When redirecting from Google Maps to OpenStreetMaps, the Google Maps' URL only has an address string. It doesn't have lat, lon. We make a separate HTTP request to nominatim.openstreetmap.org to get the lat, lon for that address. In declarativeNetRequest, there's no "code" that can be executed to make a separate HTTP request. It's just a "Rule" in a table.