consent and safety considerations regarding starter packs #90
Comments
|
@rscmbbng, thanks for opening the issue! Those are some excellent points. I'll do my best to address these points as soon as possible! One question about explicit consent/users should be notified: I worry that if I implement this, people may get annoyed by the notifications they'll receive every time they get added to a starter pack (this might be especially annoying for famous accounts that get added to multiple packs). Do you think this is a valid concern? |
|
In general, I'd say the possible negative consequences of a lack of notifications outweigh the issue of notification spam. People already have multiple ways to deal with notification spam, via clients and via machine settings. But ultimately, you could add a feature to disable further notifications. That way, people can choose themselves whether notifications are annoying but essential, or just annoying. In that case, they can opt-out of further notifications from starter packs. |
|
I've already implemented the proposed stopgap: f8e00f4 |
|
I have just deployed a change that allows logged-in users to see starter packs that contain their account: df31409
|
|
Until (or as a complement) "Explicit consent" is implemented, and for people that don't want to be included in starter-packs, yet don't want to disable discoverability flag neither, would it be a good idea to use an opt-out tag in the bio ? |
|
@villepreux I don't know. If I don't like fedidevs.com and I don't want to be included in starter packs I probably don't want to advertise fedidevs.com or starter packs by having a #no-fedidevs or #no-starter-packs in my bio. Does anyone have a direct contact with someone that does not want to be included in starter packs? I'd love to chat with them to better understand what solution would work best. |
|
A general opt-in via a pending invite and a notification would be the strongest. I initially suggested the stopgap since that was already a model that the service used, and it is a stopgap because the stronger opt-in model will supplant it. The trouble with more hashtags or thing-in-bio hacks is that you end up building hacks on hacks. What if someone wants to be discovered, and in starterpacks but not on fedidevs? What combination of tags is that? Opt-in via pending invite and notification gets around all of that.
No, but I could point some more people towards this issue by forwarding your question including in moderator and safety-focused fora if you'd like? Or you could raise the question yourself, for instance in the IFTAS matrix chat. |
As somebody who has an account that I don't want to be included in fedidevs starter packs (as well as a different account that I would potentially ike to be included). What would work best for me is a system where I am not included unless I explicitly ask to be. Almost as good for me, and possibly better in general, is a system where if somebody wants to add me to a starter pack and I have "discoverable = true" in my profile, I get some kind of notification or message where it's easy for me to respond "yes", "no", and "no and don't ask me again unless I override this" -- and I'm not added unless I explicitly say yes ... I think this what you're referring to as "opt-in via a pending invite and notification" I did a series of polls on starter packs a few weeks ago ... of course these are just as unscientific as any fedi polls, still the results are interesting -- and there were some good suggestions in the comments as well. https://infosec.exchange/@thenexusofprivacy/113512328290399242 |
Could also be opt-in tags. My point is having a tag solution, while indeed being hacky, not perfect and temporary, has the merit of being easy to implement today and do the job. Of course until a better solution that finds consensus is implemented. Since start packs are already there, I'd prefer a bunch of additional hack tags today that allow my preferences to be respected, than no solution because we spend too much time working on the perfect solution. (Hopefully I'm not a fedistar and I'm not concerned by being added in packs 😉) |
Hi thanks for developing tools that help with discoverability and onboarding on the fediverse, much needed!
I've been trying out your starter pack implementation and I noticed some issues that will cause trouble down the road. The current design assumes two things that should not be taken for granted: that people want to be included in starter packs, and that starter packs are used only for benevolent purposes. A feature that can direct the attention of unknown others to a profile should allow at least for the following:
Users should give explicit consent to be included
Currently, this is not the case! Accounts can be silently added to a starter pack, and there is nothing the affected accounts can do about that, except for reporting. Fedidevs should have a mechanism where consent to be included is explicit. Once an account is added, its status should be pending (and not publicly visible), until the account accepts being added. If there is no acceptance within a given time window, then one should assume no consent was given.
I realize the above feature is one that requires some work, in the meantime you could consider using the discoverability settings as a stopgap.
Users should be notified
At the very least, accounts that are added should be notified. That has two advantages: first, people will be able to take action if they do not want to be included. Secondly, if they are ok with inclusion, they might use the starter pack themselves or spread awareness for the project!
Users should be able to self-retract
While you currently have reporting functionality, it is manual and dependent on you. Instead, users should be able to unsubscribe themselves from any starter packs they are listed in. It costs you less effort, but also users know their own contexts and reasons best.
Users should have an overview of all the starter packs they are in
It can be easy to miss a notification, or one might change their mind about their inclusion. How do I know which ones I've been added to so far?
Starter pack makers should be able to review and verify their actions before a pack is made.
Currently, once an account is selected it is immediately added and the starter pack is published. I really did not intend to pollute the overview of starter packs when testing, but did so unintentionally because of the above. A draft mode would allow for tweaking and explicit publishing.
Starter pack makers should be able to remove accounts they have added to a pack.
Because, oops, I picked the wrong one.
Finally, consider the event that one makes a starter pack explicitly for harassment. Imagine the amount of damage that can be done when: 1) a potential victim is unaware they are added. 2) They cannot remove themselves when they find out why they are followed by hundreds of trolls. 3) Have to wait for the fedidev admins to wake up and take down the reported harassment pack because they live in a different timezone. 4) The admins have to take time to weigh whether the "Top 10 Leftists Starter Pack" in question is in fact praise or harassment.
It seems like you have a lot of the required parts (such as oAuth flows etc) to do these things. If the project can tackle these check boxes, it will be quite a useful addition to the fediverse.
The text was updated successfully, but these errors were encountered: