Mastodon: Require permission for linking accounts in bio/pinned toots

[hoodieak]

we already have a system for follow requests, and this system could be duplicated and extended to allow many things that (while not inherently bad) can be very bad when done without permission.

the number one worry as a target of harassment is venues for harassment, "just how easy" is it for someone to harass you. hotlinking someone's profile instantly sets that level to max, it is too easy, and anyone can do it at a few clicks.

so, an innocuous thing, like linking someone else's @ in your profile, can go from innocent to malicious purely based on the case.

the easy way to fix this is to require permission. in other words, when you submit a bio (or, should pinned toots exist, when you try to pin a toot that has someone else's @ in it) it would send them a request, similar to how follower requests are currently implemented, that asks permission. upon the user giving permission, it would approve/submit the bio change/pin that was requested.

[mjankowski]

It seems weird to have to ask for permission to link to something?

Part of putting a thing on the public internet is that it might be linked to. This is more good than bad.

[LogicalDash]

I don't think it's weird. If you wanted literally everyone to see what you're writing, you probably wouldn't have locked your account to begin with.

And you'd probably be on Twitter.

[mjankowski]

The initial issue didn't say anything about locked accounts, and I'm not sure how that's relevant to stopping people from linking to stuff. Can you clarify the scenario you're worried about?

[hoodieak]

the scenario is _harassment_, the number one thing twitter fails at handling, since we're bringing that up. locked account is a good example of someone who actively does not want anyone to see or interact with their posts and content. arguing "this is how the internet works" is the most ableist, dismissive thing you could possibly say, and it's frankly ridiculous when said in reply to a post about how to change this little corner of the internet.

as said in the post, a clickable link to someone's account in a bio _is a bad idea_ without tools for the user being linked to being able to make them remove it. it allows, in three clicks, someone to begin a post to someone who actively has not agreed to be presented in this way.

[LogicalDash]

The initial issue expands on follow requests, a concept that only applies to locked accounts.

The scenario is a "pile-on," where someone who hates you and has a lot of followers who don't know you, but wouldn't like you if they did, publicly posts a link to your profile. Even without specific instructions, this tends to result in a lot of those followers hassling you.

[hoodieak]

here's an example: someone who you don't know, someone you have not interacted with and are not friends with, doesn't like you.

so they put "@mjankowski hates free software" or something else ridiculous, and all their followers upon noticing that, jump into your mentions by the hundreds to yell at you about this possibly false claim about you.

this is a thing that happens _way more often than it should_ to marginalized people, and thus, a feature to make it less abusable is inherently valuable.

[mjankowski]

Noted.

[yookoala]

I think there are 2 parts of this issue:

1. Some user spreading untrue / hateful message about a person (with mentioning).
2. The mentions cause notifications to flood the person being mentioned.

I think the first part is not something any program can really fix. You can always mention something on the internet with a proper URL or email address. A mastodon handle (@username@domain) would be no different. This is something where instances' admins should step in and take action.

The second part, however, could be done with program change. Perhaps to introduce some kind of blocking / filtering for mention notifications? @hoodiek do you think this is sufficient?

[hoodieak]

part 2 is already handled in a different issue that has been requested, thread muting. the first is STILL something that can be mitigated, saying that it can't be "Fixed" is saying that it's not worth it to invest in protecting those who need it as best we can.

the idea is inherently to _solve_ this issue of posting said links and the like. the software already has the means to resolve links, we have the means to make it much harder, and i already explained why accessibility to said harassment is worth getting removed.

not implementing said feature leaves harassment two clicks away. @yookoala

[triplefox]

The feature has some immediate value. The behavior can be implemented. However, nobody commenting has attempted to concretely assess what tradeoffs occur in making it:

1. It adds a new "implied service agreement" to the protocol. Like with privacy features, GS would fail to acknowledge it.
2. Unlike post privacy, it degrades gracefully in that if an unwanted mention gets through, we're back to the status quo behavior, vs. some new form of danger in exposure.
3. It would add some more data to store and request, and a point of failure for being able to post: if I can't access the instance you're on at the moment I send the message, will it default to failing, or success?
4. As proposed, it adds more UI(for message approval, and possibly toggles for the feature if it's not associated by default to private account), which is good for power users and bad for onboarding new ones.

Please discuss on the basis of these tradeoffs.

[hoodieak]

re 1: my personal opinion on this rather-frequently mentioned matter is that if the protocol is not worked on and improved there is no progress. while mastodon should, at some point, release definitions of it's expanded version of the protocols used, it should not hesitate to expand it due to this argument
re 2: this is a good argument in favor of it, i believe?
re 3: i don't actually fully understand this one, i think. it would presumably default to failing, preferably with a very precise/well explained message as to why
re 4: considering these are things that happen rather rarely, the UI could be hidden unless there is such a request pending. i would argue that while some might disagree, the follow-requests section could just be expanded to "requests" in general, and whenever groups happen which have been described elsewhere, it would be "requests and invites", as they all act in nearly the same way, giving you a yes or no prompt to answer. preferably, each type of event would have a description of what saying yes to it does. if done in this manner, it doesnt really add any difficulty to onboarding users.

[npdoty]

Is the proposal that if I @-mention @example's account, that my toot wouldn't post until @[email protected] had approved the @-mention? Or that the @-mention wouldn't hotlink in renderings of the toot? (The latter seems more workable; in the former case it would become difficult to have conversations with new people or critique a prominent account.) In the latter case, maybe we'd be looking at a preference approvesMentions (like approvesFollowings), which, if true, requires an approval from the mentioned user before the mention is hot-linked by supporting instances. I'm not sure where we would record that approval, since the toot will have already been federated out to many instances. Maybe a user with approvesMentions could publish a collection of approvedMentioners and instances could check that list before rendering the toot? To @triplefox's point, that might be a substantial increase in the cost of rendering toots.

Facebook has a somewhat similar feature in that when you're "tagged" in a post, you receive a notification and can un-tag yourself from that and future posts. I believe it's implemented such that when you're un-tagged, your name is still present in the post, but not hot-linked to your Facebook page and it doesn't show up in search results. For the dogpiling case, users could still copy-paste the @[email protected] string into search and find the user to jump on, but that small increase in effort could discourage some of the activity. Related, users that wanted to engage in dogpiling could use a server which does hot-link mentions. I believe Mastodon search doesn't provide a quick list of everything you were mentioned in (unlike Facebook), so that particular Facebook un-tagging effect isn't necessary here.

[npdoty]

(Could we re-name this issue to describe the specific idea? Maybe "approvals for mentions in toots / bios"?)

[deutrino]

This is the second time I've ended up on this issue while searching for other things. Can we rename it please?