Sense checks for Mastodon 4.4 update

I think this is a good change, and I'm happy it was brought forward!

If the referrer becomes an issue in the future (potential privacy risks?), we could disable it.

I'm still wondering what's happened with our vote to increase the character limit. I thought the Tech WG was looking at alternate server software partly for that reason.

With 470 active users, I think our instance is large enough that we don't need to worry about identifying users when sending the headers.

There is a scenario in which someone can be tracked, but it will require a lot of manual labour on the part of the whomever is collecting the analytic, but I think that is outweighed by the benefits of ensuring that the fediverse's presence is recognized.

I wonder if an individual user override of this option at the account level is on the roadmap for the Mastodon dev team.

Thank you for the thoughtfulness of this process 🌹

@Majd al-Shihabi Although I tend to agree that personal privacy is not a big concern with 470, I think it is difficult to establish a number under which it would become a concern. (I wrote "personal privacy" for the first time above, making me think about "group privacy" which is maybe something to consider too, but I never read anything about it or thought much about it)

Posting here to say I found https://github.com/mastodon/mastodon/issues/21795 a good source of historical (occasionally heated) discussion about the Mastodon referer setting, and people interested in sampling a range of opinions on the interactions between this setting and privacy could be interested in taking a look.

IMHO running a different poll/sense check for the referer setting is appropriate given that people raised it as a distinct concern, but my current expectation is that we will see a similar split in opinions there (a roughly 90/10 split) so we could start thinking in parallel about how to interpret that result :) The CWG might be interested in helping navigate that aspect of the decision? Setting more concrete a priori guidelines for when we go with the majority or minority opinion in divisive topics could be generally useful.

@flancian I think it's worth looking at thread and noting the overwhelming majority of comments were opposed to changing the referer heading away from no-referer.

Hrm. I went with "Looks good" because my default is to go with whatever TWG feels is fine. But I may adjust my vote to Abstain or Concern.

Here's my reasoning:

I do think it would be good for large publishing sites to know that Mastodon/the Fediverse is out here and is a source of traffic. Maybe they will establish a presence here, maybe they will add easy links to articles, things like that. I think it will be very good for mastodon.social to have this on for this reason.

But I don't think having the referrer headers on for a small instance will help achieve that. I think we'd be so far in the tail of someone's referrer list that they would seldom get down to us to even look at the server and realize it's a Mastodon server.

I looked at the github issue Flancian linked to (thanks so much Flan!) and it is clear pretty quickly from the discussion there that there is not a good web way to make the referrer just generic Mastodon at least in the webapp - just a limitation of how links on the web work.

I think I have talked myself around to:

1. Adding the referrer header for our small site will likely not do any good in the world

2. there is a small chance that it will bring our small site attention we don't want, like people looking for servers to hack or set up advertising accounts on.

I think we should not turn on the referrer headers for now.

(Re: ToS, I'm always up for a proposal of "let's talk about it" so that seems great)

(side note: I am a member of the Community Working Group)

Will there be a similar discussion for Mastodon 4.5?

@janwlrvnsocial.coop I don't think there's any planned; which aspects of the update do you think could merit a check? (I haven't reviewed the update yet.)

Update: I have reviewed the release notes and I don't see aspects that would require a pulse check, but let me know if I missed something!

@Flancian perhaps the thought was support for quote posts, but Mastodon has included user safety and privacy controls with this feature rollout

@Andrew Escobar (Andres) · social.coop Finance Working Group Indeed, I thought maybe quote posts could require a pulse check.

Sorry I'm a bit late to this discussion. I do not see any value in creating a terms of service. Our code of conduct already pays out the terms of service for our members. A TOS encompassing member rights and responsibilities would be redundant at best and at worst could have inconsistencies with the code of conduct that could create confusion and unclear policy of either needed to be invoked in a situation. If anything a TOS should mostly say our members must agree to the code of conduct.

For external users, such as other mastodon users, other mastodon instances, the general public viewing social.coop on the web, and bots, the federation abuse policy pays out a lot of the terms of service that apply to them. It may make sense to incorporate that directly into any TOS document because it doesn't exist on social.coop proper and external users don't go through a process where they are required to know of and agree to the federation abuse policy. However I'm still not sure I see any value in creating a TOS for external users. Among Mastodon users and instances I think there's enough understanding, or at least access to understanding, that interaction between users and instances, and instances and instances is voluntary and either party can end it. I have concerns about AI scraper bots but they don't care about TOS so...