I would prefer this to be a setting and not an environment variable, so it can be enabled more easily on managed hosting.

We should maybe (in a later PR?) add a way to configure it from the admin settings. We could explain that we do not recommend enabling it for servers with < X active users because it can leak some data (if you have 3 users, it can be very obvious who clicked on the link, so this is some data leak), and maybe even show a hint near the option to recommend enabling/disabling it depending on on the number of users on the instance?

I also think this should be an admin setting but it's easier to introduce as an environment variable first.

I also think this should be an admin setting but it's easier to introduce as an environment variable first.

What about keeping it unchanged in this PR, and adding it as an admin setting in a second PR? My concern is having having to maintain awkward code (like for AUTHORIZED_FETCH) while we could avoid that by going directly with an admin setting.

Also, I think this is lacking changes to lib/sanitize_ext/sanitize_config.rb, which is prehaps the most important place if you want to have referrers for links in posts.

Thanks, updated. I don't see a problem with future maintenance if the admin setting is added before a stable release. The reason I would like to add this as an environment variable is so we can immediately enable it on mastodon.social.

This pull request has merge conflicts that must be resolved before it can be merged.

This pull request has resolved merge conflicts and is ready for review.

Wouldn’t some people (e.g. journalists) want link targets to see the full URLs of their posts?

Checking in to make sure I understand the configuration: as it is implemented right now, this is something server infra admins can enable or disable for the server, but not something that users can toggle themselves? e.g. if a server were to "enable the feature" would all users be opted in (or out) with the ability to change to the reverse via their own tools, or is it just globally on or off for the server?

Wouldn’t some people (e.g. journalists) want link targets to see the full URLs of their posts?

They might want that, but realistically, one would often not be on the specific post, but on a timeline, when clicking a link. And this may reveal more information than we are confident with.

Checking in to make sure I understand the configuration: as it is implemented right now, this is something server infra admins can enable or disable for the server, but not something that users can toggle themselves? e.g. if a server were to "enable the feature" would all users be opted in (or out) with the ability to change to the reverse via their own tools, or is it just globally on or off for the server?

This is a server setting end-users do not have control over.

This is a server setting end-users do not have control over.

Thank you!

Brief note for anyone finding this via Trunk and Tidbits - the browser ultimately decides what referrers get sent, so end users do have control in that sense.

If this is a concern for someone and their instance admins prefer having referrers on, I'd encourage looking into browser configuration and/or extensions (discussion on that is better held elsewhere) so you have control over this with any website, not just the Mastodon instance you're on.

Our default Referrer-Policy is same-origin, which means the referrer header will only be sent when navigating within your Mastodon server, however, with ALLOW_REFERRER_ORIGIN=true, Referrer-Policy: origin will be used, which will send the referrer header to external websites with only the domain of the referrer and no specific page.

@Gargron: Very nice that you made this configurable. However, instead of origin I would choose the policy value strict-origin (or maybe strict-origin-when-cross-origin which is the default value for most of the current browsers when a server does not send a Referrer Policy).

According to strict-origin and strict-origin-when-cross-origin basic referrer data (i.e. only the domain of the referrer and no specific page) may be sent to third parties via secure connections (HTTPS) only. The current configurable policy value origin allows the referrer data to be sent via insecure connections (HTTP).

For more details see: https://www.w3.org/TR/referrer-policy/#referrer-policies

strict-origin-when-cross-origin sounds like a good idea. It's something I hadn't noticed when reviewing the PR but we do have some assumptions that the referrer is a full URL when same-origin (in ApplicationController#store_referrer). This change has caused the get-back-to-where-you-were-before-log-in flow to break.