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

Add support for private accounts #180

Closed
nex3 opened this Issue Nov 22, 2016 · 9 comments

Comments

Projects
None yet
6 participants
@nex3

nex3 commented Nov 22, 2016

Following Twitter, private accounts would display toots only to followers (not unauthenticated users or non-followers), and would require follow requests to be authorized by the user in question before they go through. This is something that's really important for marginalized users who want to escape not only active harassment, but the passive ability for hostile people to see into their lives.

I know that this is addressed in the FAQ, but I'm hoping this issue can stand as a place for users to express support for the feature and for progress to be tracked, however long it takes.

@nex3

This comment has been minimized.

Show comment
Hide comment
@nex3

nex3 Nov 22, 2016

It looks like GNU social at least notionally supports both of these features within a single instance, as described in the FAQ. Even if supporting federated followers of private accounts takes longer, it would be really great to have per-instance privacy in the short term.

nex3 commented Nov 22, 2016

It looks like GNU social at least notionally supports both of these features within a single instance, as described in the FAQ. Even if supporting federated followers of private accounts takes longer, it would be really great to have per-instance privacy in the short term.

@Gargron

This comment has been minimized.

Show comment
Hide comment
@Gargron

Gargron Nov 22, 2016

Member

I do understand the importance of private accounts. However, I am opposed to solutions that only work within a single instance. It means that all your friends from other servers would have to switch to yours to see your posts, and that runs counter to the idea of federation.

Member

Gargron commented Nov 22, 2016

I do understand the importance of private accounts. However, I am opposed to solutions that only work within a single instance. It means that all your friends from other servers would have to switch to yours to see your posts, and that runs counter to the idea of federation.

@nex3

This comment has been minimized.

Show comment
Hide comment
@nex3

nex3 Nov 22, 2016

It seems to me the fact that privacy is inherently restrictive makes it a little more palatable—you could even imagine someone setting up their own Mastodon node with stringent requirements for registration, and setting their visibility to node-only on purpose.

That said, I do understand your hesitation. What about this as a compromise: support federated privacy controls, but have the UI gracefully degrade across nodes. Specifically, between two nodes:

  • Any request for non-public information about a protected user, or actions on that user, results in a 403.
  • In addition to the above, a request to follow a protected user shows up in their UI as a follower request.
  • If the protected user approves the follower request, the prospective follower's requests no longer 403 (even though they aren't following yet).
  • If the requester follows and then unfollows the protected account, they lose access to it again.

This requires an extra iteration on the follower's part, but it's properly federated and requires no protocol changes. It could also be cleanly folded into the protocol by simply having the publisher's node send a notification to the subscriber's node saying "your follow request has been approved", which would cause the subscriber's node to re-issue the follow request.

nex3 commented Nov 22, 2016

It seems to me the fact that privacy is inherently restrictive makes it a little more palatable—you could even imagine someone setting up their own Mastodon node with stringent requirements for registration, and setting their visibility to node-only on purpose.

That said, I do understand your hesitation. What about this as a compromise: support federated privacy controls, but have the UI gracefully degrade across nodes. Specifically, between two nodes:

  • Any request for non-public information about a protected user, or actions on that user, results in a 403.
  • In addition to the above, a request to follow a protected user shows up in their UI as a follower request.
  • If the protected user approves the follower request, the prospective follower's requests no longer 403 (even though they aren't following yet).
  • If the requester follows and then unfollows the protected account, they lose access to it again.

This requires an extra iteration on the follower's part, but it's properly federated and requires no protocol changes. It could also be cleanly folded into the protocol by simply having the publisher's node send a notification to the subscriber's node saying "your follow request has been approved", which would cause the subscriber's node to re-issue the follow request.

@Gargron

This comment has been minimized.

Show comment
Hide comment
@Gargron

Gargron Nov 22, 2016

Member

The way subscriptions work (PubSubHubbub) is this:

  • Account have public Atom feeds that link to a hub
  • You can send a subscription request to the hub for that feed
  • When the account publishes something, it notifies the hub
  • The hub takes the public feed, takes new items, and delivers them to all subscribers

The hub is independent from the rest of the application, so if a feed is not public, the hub won't be able to deliver it to anyone.

This could be solved by piggybacking "private followers" on the Salmon protocol instead of PubSubHubbub. Salmon is for delivering signed notices to individual accounts (like "alice followed bob" being delivered to bob), but you could technically send private statuses to followers that way. It would, however, at least currently, be incompatible with GNU social. Most importantly, there is no protocol for saying "this feed is private, send a follow request first".

(Quite ironically because there is a follow request verb/activity type in the ActivityStreams protocol iirc)

To sum it up, it's not impossible, but it would take exploring new frontiers rather than simply implementing existing protocols.

Member

Gargron commented Nov 22, 2016

The way subscriptions work (PubSubHubbub) is this:

  • Account have public Atom feeds that link to a hub
  • You can send a subscription request to the hub for that feed
  • When the account publishes something, it notifies the hub
  • The hub takes the public feed, takes new items, and delivers them to all subscribers

The hub is independent from the rest of the application, so if a feed is not public, the hub won't be able to deliver it to anyone.

This could be solved by piggybacking "private followers" on the Salmon protocol instead of PubSubHubbub. Salmon is for delivering signed notices to individual accounts (like "alice followed bob" being delivered to bob), but you could technically send private statuses to followers that way. It would, however, at least currently, be incompatible with GNU social. Most importantly, there is no protocol for saying "this feed is private, send a follow request first".

(Quite ironically because there is a follow request verb/activity type in the ActivityStreams protocol iirc)

To sum it up, it's not impossible, but it would take exploring new frontiers rather than simply implementing existing protocols.

@hikari-no-yume

This comment has been minimized.

Show comment
Hide comment
@hikari-no-yume

hikari-no-yume Nov 22, 2016

Contributor

I agree with @nex3 that private accounts being restricted to an instance could be a feature and not a bug.

But ideally you could federate it, for sure. Even if only between Mastodon instances (if, say, only Mastodon implemented it).

A concern with federated private accounts is that you'd have to trust each other instance you're letting people follow from. Luckily, you'd actually be given the power to decide this, because it's a private account, so you can accept and reject follow requests as you please.

Contributor

hikari-no-yume commented Nov 22, 2016

I agree with @nex3 that private accounts being restricted to an instance could be a feature and not a bug.

But ideally you could federate it, for sure. Even if only between Mastodon instances (if, say, only Mastodon implemented it).

A concern with federated private accounts is that you'd have to trust each other instance you're letting people follow from. Luckily, you'd actually be given the power to decide this, because it's a private account, so you can accept and reject follow requests as you please.

@golbette

This comment has been minimized.

Show comment
Hide comment
@golbette

golbette Nov 24, 2016

Gonna go ahead and add my 2c to the pile that "make account invisible to other instances" would actually be a nice feature to have and not necessarily a bad one. While it goes against federation as a whole philosophically, its effects would very likely be minimal since a minority of users are going to want to be private in the first place - social networks are inherently social! Such a feature would also serve as a useful 'emergency valve' if someone's personal privacy is being breached.

If privacy were "all or nothing", the practical damage to the whole 'federated platform' ideal would be even lower, because people are only going to want to be private in extreme circumstances or for, you know, dedicated weird shadow accounts maintained parallel to a public account to talk about...stuff.

golbette commented Nov 24, 2016

Gonna go ahead and add my 2c to the pile that "make account invisible to other instances" would actually be a nice feature to have and not necessarily a bad one. While it goes against federation as a whole philosophically, its effects would very likely be minimal since a minority of users are going to want to be private in the first place - social networks are inherently social! Such a feature would also serve as a useful 'emergency valve' if someone's personal privacy is being breached.

If privacy were "all or nothing", the practical damage to the whole 'federated platform' ideal would be even lower, because people are only going to want to be private in extreme circumstances or for, you know, dedicated weird shadow accounts maintained parallel to a public account to talk about...stuff.

@hikari-no-yume

This comment has been minimized.

Show comment
Hide comment
@hikari-no-yume

hikari-no-yume Nov 24, 2016

Contributor

An emergency valve has its value. A problem with federation is you couldn't really hide and protect your existing posts, but at least your new ones would be safe.

Contributor

hikari-no-yume commented Nov 24, 2016

An emergency valve has its value. A problem with federation is you couldn't really hide and protect your existing posts, but at least your new ones would be safe.

@Gargron

This comment has been minimized.

Show comment
Hide comment
@Gargron

Gargron Dec 23, 2016

Member

This can be closed now. Separate issue is making private posts work across federation as well, but that's a story for another time. For overview of this update, I'll just link my summary here: https://mastodon.social/users/Gargron/updates/529995

Member

Gargron commented Dec 23, 2016

This can be closed now. Separate issue is making private posts work across federation as well, but that's a story for another time. For overview of this update, I'll just link my summary here: https://mastodon.social/users/Gargron/updates/529995

@Gargron Gargron closed this Dec 23, 2016

@caitp

This comment has been minimized.

Show comment
Hide comment
@caitp

caitp Apr 4, 2017

Privacy is not just about what you post, but also about who you follow, and who follows you. Those (or rather, visibility of those things) ought to be controllable. (and, if a particular instance does not honour visibility/security a user's metadata, they should probably be turfed out of federations)

caitp commented Apr 4, 2017

Privacy is not just about what you post, but also about who you follow, and who follows you. Those (or rather, visibility of those things) ought to be controllable. (and, if a particular instance does not honour visibility/security a user's metadata, they should probably be turfed out of federations)

rinkei pushed a commit to pixiv/mastodon that referenced this issue Apr 25, 2017

akihikodaki pushed a commit to kagucho/mastodon that referenced this issue May 3, 2017

abcang pushed a commit to pixiv/mastodon that referenced this issue Jul 3, 2017

Merge pull request tootsuite#180 from pixiv/fix/toggle_button_sc_bug
Clear state of sound cloud at the end of music

yipdw added a commit to yipdw/mastodon that referenced this issue Oct 19, 2017

takayamaki pushed a commit to takayamaki/mastodon that referenced this issue Dec 2, 2017

Merge pull request tootsuite#180 from masarakki/remove-announcement-o…
…f-friends-at-tokyo

remove-announcement-of-friends-at-tokyo

lnanase pushed a commit to lnanase/mastodon that referenced this issue Aug 21, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment