LibRedirect – Redirects popular sites to alternative privacy-friendly frontends

Twitter/X frontends and captchas

• Multiple X/Twitter frontends are compared (lightbrd, xcancel, various Nitter instances).
• Some require Cloudflare or Anubis CAPTCHAs; others use proof-of-work “verifying your request” pages.
• With JS disabled, users may still hit traditional CAPTCHAs that only sometimes work.
• Several commenters feel plain nitter.net is still the most practical option.

Extensions vs userscripts and threat model

• One camp argues browser extensions are an unnecessary security risk; simple userscripts can handle redirects.
• Others counter that userscripts have extremely broad powers too (e.g., actions on any Google domain) and are often long, opaque, and hard to audit.
• Advocates of tiny, self-written 3‑line userscripts emphasize inspectability and lack of auto-updates from unknown maintainers.
• Critics say expecting every user to hand‑code and maintain dozens of redirect rules is unrealistic; LibRedirect centralizes rules and instance lists.
• There’s mention that userscripts typically can’t intercept before the initial request, causing double loads.

Trust, VPNs, and “privacy‑friendly” frontends

• Some argue that using alternative frontends (Piped, FreeTube, SponsorBlock, etc.) can just shift data from Google to Cloudflare or “random strangers.”
• Suggested alternative: use YouTube directly via a separate browser profile + VPN + adblock, logged out.
• Others push back: VPN providers (e.g., NordVPN) have their own criticism and fingerprinting still ties activity together.
• Some would rather leak “small, fragmented” data to many small operators than comprehensive profiles to a few large platforms.
• Concerns are raised about honeypots: operators could silently log detailed user data; detecting this may require source code review and is often non-transparent.

Farside vs LibRedirect and instance reliability

• Farside is brought up as a related project with automatic instance selection based on reachability, handling frequent instance failures.
• LibRedirect’s client‑side approach avoids routing through a central redirector like farside.link, which otherwise could observe what content users view.
• Commenters note instances die or get rate-limited as big platforms fight back, making automation and good instance lists essential.

Security and abuse risks of redirecting

• Critics worry that normalizing redirects from “trusted” sites to unknown instances opens doors for phishing, ads, or malicious replacements if domains change hands or get hacked.
• Others respond that frontends usually don’t involve logins, and self-hosted instances significantly reduce this risk.
• There’s also concern that the extension itself could be compromised or sold and then weaponized via its broad permissions.

Browser ecosystem, JS, and performance

• People fear browsers (especially those funded by ads) will keep weakening user‑friendly controls, citing Safari hiding “Disable JavaScript.”
• Some recommend Firefox, Tor Browser, or Mullvad Browser as more privacy‑respecting options, though Mozilla’s own ad business is noted.
• Several highlight that third‑party frontends are far lighter and often no‑JS or low‑JS, exposing how much original-site JavaScript is primarily for tracking and ads.

Mobile, tooling, and front‑end landscape

• Android tools like URLCheck and Linkahest are praised for system‑wide redirect rules, URL param stripping, and better link handling.
• An “awesome list” of privacy frontends is shared; for Instagram, most self-hostable options are reportedly broken, with only non‑FOSS or CLI tools (e.g., gallery‑style downloaders) still working.
• YouTube alternatives are described as laggy or unreliable; some users now prefer downloading via yt‑dl/yt‑dlp and watching locally with mpv.
• There’s interest in a containerized bundle of all frontends and in the ability to configure arbitrary custom targets; some note LibRedirect still doesn’t fully solve custom self‑host instance mapping.