Skip to content
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

Privacy still reveals the existence of a system #238

Closed
LunNova opened this issue Oct 26, 2020 · 7 comments
Closed

Privacy still reveals the existence of a system #238

LunNova opened this issue Oct 26, 2020 · 7 comments
Labels
question Further information is requested

Comments

@LunNova
Copy link

LunNova commented Oct 26, 2020

Running pk;s privacy all private is less private than might be expected.

pk;s <id> list on an account with no system gives:
image

The same on an account with one with privacy all private gives:
image

@ghost
Copy link

ghost commented Oct 26, 2020

Since a system with all privacy settings set to private can still be used for proxying, it is required to keep a very small amount of information public, solely for moderation reasons.

This has been asked before, and I'm not really sure what would be best to do here.
One idea was to disable proxying for a system whose existence is hidden from third parties, but from my vague recollections of that conversation it was stated that this is probably not something that would be added to the bot as it goes against the main use of the bot (proxying).

I do see the need for this, though. Outside of its proxying features, PluralKit is a unique system organization tool and really something that doesn't have a good alternative, whether on Discord or elsewhere. (At least to my knowledge - do let me know if there's something out there that I've just missed, heh.)
Unfortunately I don't have an answer for you right now, but I will look into possible solutions for this.

@LunNova
Copy link
Author

LunNova commented Oct 26, 2020

Suppose a given discord user only uses PluralKit for proxing in some small private servers. Someone who interacts with this user on a large public server which doesn't even have PluralKit can determine that the discord user has a system associated.

I don't understand why making the <no permissions message> match the <no system found message> would cause problems. Do you have an example? Sorry for missing the obvious :L

@ghost
Copy link

ghost commented Oct 26, 2020

i get your point, but while there is a way to disable proxying on a server, there is not a way to have different privacy settings per-server. (at least for now)

as per just changing the no permissions message, i think you missed the fact that you can still look up a system with all settings set to private - that error is only produced by attempting to look up the member list.

here is an example:
image

@LunNova
Copy link
Author

LunNova commented Oct 29, 2020

Still not understanding why server moderators need any more info than "which discord account proxied this message" when all privacy settings are set. Do you have a more specific example of why/when PluralKit needs to provide more information?

@silasary
Copy link
Contributor

Knowing how many accounts have access to a System is important if a server moderator needs to ban every account associated to that system.

@FriendlyGamer
Copy link

Knowing how many accounts have access to a System is important if a server moderator needs to ban every account associated to that system.

if this is the case and others regarding the accounts, could we just not make it moderator friendly in the process and prevent panicking at the same time?

right now the problems seems that a System ID initially meant for organizational reasons must've created personal associations with such. So if the System ID to needs to be preserved privately from the logs for sanity stakes... Why not do the below instead?

In place of a system ID, it would instead put the Discord account list, a separate ID for Discord Account listing within PK or similar? In a way where the System ID is contained privately except to the accounts' using said ID? So it's like a "one way street" while still allowing moderators to do their jobs.

@greysdawn
Copy link
Contributor

There will always be some information given about a system by Pluralkit. It's a public bot created for a relatively public setting. You shouldn't be supplying extremely private information to the bot to begin with, as there are both better and more secure options for storing that info

And that's ignoring the fact that in order to find out if someone has a system with PK you need access to their user ID (or system ID) and knowledge of/access to PK, and it's easy to play it off as just "Oh, it's a roleplay thing," because RP usage is encouraged

All that said, as an example for why privacy settings hinder moderators: we used to help run PluralHub and several other system servers. In our time as moderators we had several situations crop up where we needed to use a system's linked accounts or system list in order to connect alts to dangerous users. In one case a system who threatened to (and almost actually did) dox another PH staff member kept coming back on alt accounts to do various things, including trying to become a moderator in the server of the person they were trying to dox, and without access to their member list we'd never have known

It's situations like these- where users are actively dangerous and are willing to create alts- that privacy features are an extreme hindrance to server moderators. Not even having linked accounts visible is always helpful due to importing and exporting (hence needing to see a specific user's list to connect them with their other alts). We use privacy features and appreciate their existence, but they still can and do make things harder for people trying to protect themselves/their server members

Hope that helps explain things a bit

@ghost ghost added the question Further information is requested label May 19, 2021
@ghost ghost closed this as completed Jun 9, 2021
ghost pushed a commit that referenced this issue Jun 9, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants