Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Federated links for anonymous/unauthenticated users #21203

Open
muks opened this issue Nov 20, 2022 · 4 comments
Open

Federated links for anonymous/unauthenticated users #21203

muks opened this issue Nov 20, 2022 · 4 comments
Labels
suggestion Feature suggestion

Comments

@muks
Copy link

muks commented Nov 20, 2022

Pitch

Commit 0722908 fixed #19652 where federated account links are linked locally, instead of to a remote instance. This change appeared to us after an upgrade from Mastodon 3.x to 4.0.2.

We don't like this change as a remote user's timeline (including all federated posts) appear to unauthenticated users as served by the local WEB_DOMAIN, when browsing a local user's timeline and clicking on a boosted federated post's poster's account. Previously in Mastodon versions < 4, it linked to the federated user's WEB_DOMAIN, but now that user's timeline, images and other resources appear as being served by the local WEB_DOMAIN to unauthenticated users. I can understand why #19562 was implemented for better UI experience for authenticated users, but I feel the original behavior of linking to the poster's WEB_DOMAIN is desirable when browsed by unauthenticated/anonymous users.

Ours is a company Mastodon instance in a country with anti-pornography laws. We want to federate, but don't want non-boosted remote federated content to show up in public timelines.

Instead of hardwiring it one way or the other, could you make this behavior configurable so local admins may configure it as desired?

Thank you

Mukund

Motivation

Mastodon instance operators in countries with anti-pornography laws may be able to configure Mastodon such that non-boosted content will not be served by the local WEB_DOMAIN to the general public (anonymous users).

@muks muks added the suggestion Feature suggestion label Nov 20, 2022
@afontenot
Copy link
Contributor

This seems more like a bug, because if you try to navigate directly to an external profile when logged out, you get redirected to the original instance. E.g. try this link in a private browsing window: https://mastodon.social/@oxidecomputer@hachyderm.io

Probably the issue is that before the change, the link was external and some JS caught the click when you were logged in and kept you on your home instance, and now, the link is internal, but the JS wasn't fixed to redirect you when logged out.

@muks
Copy link
Author

muks commented Nov 20, 2022

If you see the commit linked in the description, it appears this change was implemented on purpose (i.e., not an inadvertent bug) to keep the user on the local WEB_DOMAIN.

Strike that. I don't know if there's some other layer that's supposed to catch this link and rewrite it for unauthenticated users.

@afontenot
Copy link
Contributor

I just meant that it's a bug in the sense that it's unintended behavior. The point of that commit was to change the URL for logged in users, to avoid sending them to other instances when middle-clicking (or right click, open in new tab). It wasn't intended to change the behavior for logged out users.

Most likely, foreign timeline posts aren't supposed to be rendered at all when logged out - except in cases where it's explicit like the federated timeline. I can't be 100% confident of that part though.

@muks
Copy link
Author

muks commented Nov 20, 2022

@trwnh Could you look at this bug please? I am not able to tell from the commit if it is an inadverent regression, but in any case, could a config option bring back the old behavior when the web user is unauthenticated?

WesleyAC added a commit to WesleyAC/glitch-mastodon that referenced this issue Jul 13, 2023
This is clearer for users (showing all posts, as one would expect),
while patching a potential vector for leaking information to search
engines/etc.

Related: glitch-soc#2225, mastodon#21203
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
suggestion Feature suggestion
Projects
None yet
Development

No branches or pull requests

2 participants