Privacy: Replace Twitter links with Nitter & YouTube links with Invidious

[ghost]

Privacy is a important topic all over the fediverse. Many people share their links in a privacy-respecting way by using Invidious or Nitter, many others unfortunately don't.

Pitch

In my own client Halcyon I already implemented a feature to automatically rewrite those links for incoming as well as outgoing posts but leave it up to the user to use that feature or not. But I think it should be up to the server to make sure that all clients automatically get privacy-friendly links delivered without having to mess with it themselves and also for people who use the web interface, this would be a huge advantage.

Motivation

There was a issue like this for mainstream Mastodon but once again Gargron closed a issue which would bring huge improvement and had 14 likes and no dislikes. If we leave the choice to use it up to the user, there would be no disadvantages. Please help make the fediverse a bit safer and more privacy-friendly.
Link to the original discussion: https://github.com/tootsuite/mastodon/issues/12145

[lanodan]

Maybe it could be done in a way similar to how it's possible in pleroma.

We offer a MRF (Message Rewrite Facility) module which allows to change a keyword/regex to another.

I actually use it on my instance to change invidio.us to youtube.com to prefer browser/OS-level link substitution instead as you can host your own invidious and youtube-dl (used to?) not work properly with indivious.

[ClearlyClaire]

While I get the privacy concerns, I think we should not rewrite users' links on their back, especially if it is to replace one centralized domain with another (e.g. if we replace all links to youtube with links to one specific invidious instance, we haven't gained much).

Furthermore, in Invidious' case, I am very uncomfortable with promoting their project in any way, given their complacency with Gab.

Having a MRF-style system would be useful, but would not solve the “rewriting on the user's backs” concern (although this would be an instance decision). Having a user option would solve that concern, but a bit more of a mess, and at that point, I think it probably makes more sense for the users to do that on their side with browser extensions.

[ghost]

A MRF-style system would only give the same possibilities as it does at Pleroma and I don't think it does any harm there.At the end,every admin could hack some replacement code into their instance themselves but you would make it much easier by making it an official feature.And the Invidious instance shouldn't be hardcoded but the admin should be able to configure it.Many Mastodon admins have their own Invidious instances which could be promoted in this way.Personally I'm in favor of a option for the user but it should be applied on the server-side so that,once set,it works in all mobile clients as well.Browser extensions are a nice help for sites which don't give a shit about privacy but I think we should do better and actively promote the use of privacy-friendly services.I don't know what exactly you mean by their complacency with Gab but as long as Gab people aren't deeply involved in the project,I think it's much better than sending user data directly to Google.

[ClearlyClaire]

A MRF-style system would only give the same possibilities as it does at Pleroma and I don't think it does any harm there.

I actually like the idea of having a MRF-style system, we should just make sure it has reasonable performance, and, if possible, make it so that MRF rules from Pleroma itself would be compatible. I was just pointing out that it wouldn't be an user option, and thus do things on the user's backs.

Given the scope of this, it would be good if it were part of upstream.

Personally I'm in favor of a option for the user but it should be applied on the server-side so that,once set,it works in all mobile clients as well.

That is a good point, but that means hard-coding stuff specific to youtube etc. (or making the interface for end-users much more complicated). Also, so far, there are lots of places were toots are rendered once, then cached or sent to many clients at once, having per-user optional server-side changes would make that impossible and complicate things quite a bit. I am not sure this is worth it.

Browser extensions are a nice help for sites which don't give a shit about privacy but I think we should do better and actively promote the use of privacy-friendly services.I don't know what exactly you mean by their complacency with Gab but as long as Gab people aren't deeply involved in the project,I think it's much better than sending user data directly to Google.

By complacency with Gab, I mean Invidious' devs were considering integration with a commenting/discussion platform made by Gab and used by their own. As far as I know, this did not end up being implemented, but only because of technical/architectural reasons (with the dev stating that it should be handled by Gab's extensions “until there's better support for third-party applications”). That doesn't mean that Invidious is actively bad in any way I am aware of, but their handling of that feature makes me uncomfortable promoting it, as integration with that kind of platforms could be integrated within the software in the future.

Also, you are misrepresenting what we are doing: we are never sending user data to Google. We just don't rewrite links, but we don't auto-embed them or anything (the player embed functionality requires a click-through). The end-user has agency here.

[ghost]

Thanks for thinking about implementing MRF,that would be great but I don't think it will be possible to make it upstream as Gargron doesn't seem to be happy with rewriting posts.I also agree that Pleroma compatibility would be nice to have.Giving the choice to the users of course would mean that it's only for specific hardcoded services but maybe the instance of the redirect could be configurable for the user.I think it would already help to have it on the server-side for the home and notifications timeline which is built per user and where we already mess with it using the filters feature.At the other timelines,the API could simply tell the client to rewrite it like it's done for at the filters feature.I'm actually in favor of the MRF feature which allows more possibilities and can be easily extended to more privacy-friendly proxy services and can be applied to all timelines.However,the other one would give a maximum of choice to the users.And embedding Youtube videos directly (even if it requires a additional click) means sending data to Google.It's the responsibility of developers and instance owners to protect their users.