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

Control Access to Block List by Twitter Credentials #46

Open
BooDoo opened this issue Sep 8, 2014 · 1 comment
Open

Control Access to Block List by Twitter Credentials #46

BooDoo opened this issue Sep 8, 2014 · 1 comment

Comments

@BooDoo
Copy link
Contributor

BooDoo commented Sep 8, 2014

Related to #44, but coming from the other direction.

Currently: block list is accessible to anyone who obtains the URL after it's generated.
#44 suggests: a discoverable/reasonable URL is created if users opts to make list Public.

PROPOSED: Require BlockTogether app authorized Twitter credentials in line with some permitted list of viewers.

So we might offer the current "secret-through-obscurity" URI, or a discoverable URL with access level set to one of, e.g.:

  • Public
  • Users I Follow
  • Users I Haven't Blocked
  • Members Of [Twitter List]
    Let me set my list as public #44 is a good place to start here, but combining control and discoverability at cost of complexity may be worth considering?
@jsha
Copy link
Owner

jsha commented Sep 14, 2014

I think we probably do want at least one visibility option besides "unlisted URL." But I want to be really cautious about what we add because visibility options add a lot of complexity and I want to keep the service as simple as possible while still being powerful. Besides the obvious added code, there are tricky edge cases, such as: If I set visibility to "users I follow" and then I unfollow someone, how soon does Block Together need to detect that change? What if it's temporarily down?

There's also the intersection with the eventual 'block list subscription' feature. If I subscribe to your blocks and you have visibility = 'users I follow', then unfollow me, do I get unsubscribed? What if it was an accident and I re-follow? Also, this may mean maintaining an additional table of follows.

The other reason I want to approach this with caution is that I absolutely do not want to break any privacy promise I make to users, and I worry that more complex privacy options are more likely to invite bugs that could expose block lists to people the user didn't mean to expose them to.

So between the options, I think 'public' is the most appealing for the short term, with maybe 'members of twitter list' or 'this specific list of screen names' as a second, for when the app is more mature. Users I Haven't Blocked succumbs to the sock puppet problem: it's easy to get around with a fresh account. And Users I Follow has the DM problem. That is, Twitter uses the follow model to also provide DM permissions, and it works really really badly. Users are confused by it, and a follow doesn't necessarily imply permission to DM.

I also have some thoughts kicking around about what type of network structure is most likely to be useful: dense clusters all following each other vs hub and spoke vs hub and spoke pointing inward? Hopefully BT will be versatile enough for people to use in lots of ways. But certain choices encourage certain styles. For instance, showing all the block lists of people you follow is likely to encourage the dense cluster model. I've been meaning to put together a blog post to lay out some ideas and solicit feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants