Users and ActivityPub

Hi Michelle,

this is a thing that people frequently seem to dislike about the plugin. Could you enlighten me about your reasons?

For context, when you follow a user or become friends with another WordPress, that friend or follower is represented as a WordPress user that the Friends plugin creates. When they post something elsewhere, their post is cached in a custom post type and as a post_author that user is set. Thus, the posts are segmented per user. The users have very low privileges (read) and a throw-away long password.

but don’t want any other users in my WordPress installation

I am curious why this is? Is it of cosmetic nature or security reasons?

On your WordPress users list you can filter users with a certain role so that you don’t see the friend users in the list.

Each user has a throw-away long password, so it’s impossible to login with them. Thus not a security risk.

The positive sides are that the cached custom posts are assigned to the right sources. If we didn’t use WordPress users or virtual users, all posts would be assigned to the same user, thus showing just the posts for a certain user would be more expensive.

For the friendship aspect, if you, through a friendship request+confirmation, establish a trusted connection to another WordPress, you can login to your friend’s blog through that connection (similar to IndieAuth). But only in that case.

I am considering changing the creating-user because I hear this a lot. But I also have to say: it is just a user. A line in a the users table.

Curious about your reasons, thank you.

Thank you, Michelle, for giving me some insight into your perspective! This is very helpful.

I think to sum it up, I want to follow you but don’t want to be your partner for life. Adding a user is like a partner for life.

I am curious about this statement and why you believe that? I think we need to make a distinction between a user who is able to log in to your site, and one that doesn’t.

The users that the friends plugin creates have a long unknown password. They don’t have an e-mail address through which a password could be retrieved.

If you follow a site, such a user is created (with the role “Subscription” and no other priviledges) and merely used for the following things:

• Attribute posts to that user in the caching post (i.e. the post_author is the id of that user).
• Store metadata such as profile picture, website, description.
• Make it easy to delete all posts and metadata associated with that folllowed site when you decide to delete/unfriend the user.

If you befriend a site, such a user can get a role where they have some priviledges. A “friend” will indeed be able to read private posts. An “acquaintance” will not. Both can use the friends plugin on their site to log in to your site with this user in order to make comments on your posts. This is only true if the friend user has one of those roles. There is an issue on Github to discuss ideas around potentially preventing priviledge escalation.

Users with a Subscription role (thus not having a “friend” capability) cannot log in to your site.

You never get into the territory of someone having more priviledges on your site if you don’t send or accept any friend requests. You can prevent receiving friend requests by setting a passphrase in settings.

Recently the Advanced Custom Fields plugin vulnerability “allows any unauthenticated user to steal sensitive information for, in this case, privilege escalation on the WordPress site tricking a privileged user to visit the crafted URL path.”

An unauthenticated user is someone who doesn’t have an account on a site. So in such a scenario any Friends users would have been irrelevant.

To me, every user that I add to my website, adds a risk that someone out there can exploit.

I hear you but I’d argue that this is only the case when there is a chance that they can log in.

There has been a similar discussion on Github already and this system has been compared with Unix/Linux. Often services have their own user in the system that cannot be used for logging in and this is not considered a security problem.

I have read that Friends uses the common WordPress infrastructure. Could you possibly have a Friends plugin that gives an option to have the users in a customer table for Friends plugin users that don’t want to add actual WordPress Users?

Exactly using “common WordPress infrastructure” means not creating custom tables. So this is not an option. I could not attribute the posts to users in that table since the ids in that table could clash with real users in the system.

Summary

I hear your concerns and I have seen in other discussions that technical arguments do not help the perception that people don’t like its usage of users for post attribution.

Thus, I am investigating if I could replace subscription users with a taxonomy. I cannot give a timeframe but the code design has some potential to allow this.

I believe taxnomies have much worse visibility and it is much easier to lose overview of them, but “out of sight” might just be what people would like.

I have to admit that I still don’t see how adding a user should increase the risk for when your own account username is already exposed through many other means (e.g. an author page, REST API, etc.). The exploits you mentioned have been all for unauthenticated users, thus having more users would not increase the risk.

Despite this and because I respect your opinion and I believe that there is value in perceived security as well, I have worked on removing the need for users when you just subscribe to someone else:

You can follow this Pull Request “Don’t create a user when only following someone” to get notified when I merged it. It is already usable, I just need to personally test it for a while.