[HN Gopher] Why are blocks on Bluesky public?
___________________________________________________________________
Why are blocks on Bluesky public?
Author : carride
Score : 47 points
Date : 2023-06-11 19:15 UTC (3 hours ago)
(HTM) web link (atproto.com)
(TXT) w3m dump (atproto.com)
| klabb3 wrote:
| The obvious alternative is to have blocks be local only, ie a
| view filter. This would solve the privacy issue. I think I like
| that model better (but to be fair have not thought it through
| fully).
|
| However, I _think_ I understand why they're doing it. Bluesky is
| modeled after Twitter, which has sort of public popularity
| contest features built in, like retweets and replies, which can
| let malicious users signal boost using your account. Without a
| public blocklist, there's no way to stop that signal boosting,
| which gives the upper hand to bad actors.
| phoe-krk wrote:
| The Fediverse currently has popcon features built in as well,
| namely, the number of likes and boosts of a given post, as
| collected by the home server of the post. The home server is
| the one that does not count interactions from blocked accounts,
| so a local-only view filter that only the home server knows of
| is enough to solve this as well.
| klabb3 wrote:
| Interesting. That would probably be a better place to keep
| the blocklists, and trust your homeserver to not expose it
| over API is more reasonable in terms of trust.
|
| It's funny how the article focuses on friction to
| _circumvent_ blocking, which is real, but doesn't mention
| that their solution greatly reduces friction of _discovering_
| who blocks who. Because traditionally that discovery is
| tedious and not scalable.
| lalaithion wrote:
| Based on my reading of the article, they _also_ allow that;
| they call that behavior "muting" and distinguish it from
| "blocking".
| jazzyjackson wrote:
| I feel like there's a way to put salts and hashes in here so that
| I can publish a list of conditions, "don't send traffic my way if
| myblocklist.includes(argon2($username + $salt)"
|
| instead of publishing the list of people I don't want to hear
| from
|
| i also think it's fine to let everyone know who i've blocked, but
| people have different threat models
| landr0id wrote:
| With this model someone just develops a website that passively
| collects usernames, performs the calculation, and maps
| usernames to hashed values.
| xigoi wrote:
| That's why they added the salt.
| preseinger wrote:
| this approach results in false positives
| jeroenhd wrote:
| An absolutely minimal probability of false positives. The
| probability that you can find a hash collision that's also a
| valid username is even smaller. I don't think it's something
| you'd need to worry about.
| xigoi wrote:
| Extremely unlikely if you take enough bits from the hash.
| preseinger wrote:
| "extremely unlikely" is still not the same as "impossible"
|
| hash(x) != x
| xigoi wrote:
| Are you afraid to go out because you might get struck by
| lightning?
| preseinger wrote:
| if you and I have accounts at the same bank, it's
| incredibly unlikely that my account number will hash to
| the same value as your account number
|
| are you OK with the bank using a hash of your account
| number to identify your account instead of the number
| itself?
|
| of course not -- any risk of collision, no matter how
| low, is unacceptable
|
| that's the baseline -- risk tolerance is zero
|
| you have to justify any increase of that risk on a case-
| by-case basis
| xigoi wrote:
| Yeah, because the consequences of accidentally blocking
| someone on social media are just as serious as the
| consequences of a bank confusing two accounts.
| sebzim4500 wrote:
| If the hash is cryptographically secure and 128 bits I
| would be perfectly comfortable with them assuming
| uniqueness of it.
|
| To repeat that guy's question, do you avoid going outside
| in order to avoid freak lightning strikes?
| jazzyjackson wrote:
| > are you OK with the bank using a hash of your account
| number to identify your account instead of the number
| itself?
|
| Why not? Cryptographically, entropically, there's no
| difference between a call to "give me a uuid to throw on
| this new account" and "now crunch it through a sponge
| function and use that instead"
|
| Your uuid generator will probably check for uniqueness,
| or your database will enforce unique values, so there's a
| few places you would be alerted of the collision, but
| 2^256 is a very large number
| 8organicbits wrote:
| Password hashing algorithms don't work well if the entire
| search space is small. If you block me it's trivial for me to
| check my username against your hashes to prove you blocked me.
| Reversing every hash is mostly a question of how many known
| usernames there are.
| walkercraig wrote:
| Honestly the more I hear about AT/Bluesky and some of these other
| new protocols, the more I keep coming back to thinking of
| ActivityPub as the one with the most potential for the future.
| jeroenhd wrote:
| BlueSky is a better social media service than any ActivityPub
| system out there right now because of the content
| recommendation algorithms BS was designed to support.
|
| You need to gather the messages from various huge AP instances
| for anything close to a good recommendation algorithm.
|
| I think the whole algorithm situation is exactly what's wrong
| with social media today, but it's also what makes people come
| back for more. Sadly, I think BS will beat AP in this regard
| because of that.
| walkercraig wrote:
| I certainly understand where you're coming from but isn't
| that only demonstrable right now because BS is the only
| "huge" instance running at the moment? They haven't federated
| yet so we assume this is just going to work across the entire
| federation of servers?
|
| Further, development on ActivityPub is not "done," correct?
| As in, someone could technically still write/develop their
| own client and attach its own algorithm over the top of
| ActivityPub, right?
|
| To be clear, I hope I'm not sounding like my opinion on this
| is definitive or anything and I'm just having a conversation.
| There are definitely problems with ActivityPub, it just
| sounds like BlueSky is trying to solve/fix every problem that
| every individual person maybe/possibly/who knows will have
| before they even launch which, in my experience, is generally
| a concerning approach.
| tedunangst wrote:
| > As we currently understand it, on Mastodon, you only see
| content when there is an explicit follow relationship between
| accounts and servers, and follows require mutual consent.
|
| You can't even create a mastodon test account to test (and
| disprove) this theory?
| vidarh wrote:
| It explains a lot about Bluesky of they are that ignorant about
| the alternatives.
|
| You don't even need an account. You can disprove this nonsense
| by visiting any Mastodon server and looking at the local feed
| and confirm that most posts are accessible to anyone.
|
| Your instance won't get posts _pushed_ to it if nobody on that
| instance follows a given account, but you can still pull unless
| an account is private, and at least one instance implements a
| kind of follow that pulls to let people keep tabs on accounts
| without openly following them.
| ChrisMarshallNY wrote:
| On the app I'm writing, blocks are private. Only the blocker
| knows they have blocked someone. If they block, they disappear
| from the other member's view. It's as if they didn't exist.
|
| As mentioned, someone can figure out that they've been blocked,
| but they can't be certain. There's no way to know who another
| member is connected to. That's also private to the member, so the
| logging in as an anonymous user can see that you are available to
| unblocked members, but not who you are connected to. You can
| infer that you are blocked. Also, nothing is truly public. Only
| members can even see other members, and, currently, every member
| request is vetted by a human. We're not going for scale, which
| means that getting that sockpuppet account might not be so easy.
|
| That's mainly because of the demographic we Serve. There are
| quite a few dangerous people, therein, so we need to be pretty
| circumspect about privacy and security. We make sure that every
| member has full control of their privacy and data, and we also
| default to the most secure. No dark patterns to trick people into
| divulging information.
|
| That said, it's a simple community app, so we can't throw too
| much friction into the way members interact with each other. If
| someone is _really_ worried, they shouldn 't use our app (or any
| other social media app, because ours is more anal than most).
| phoe-krk wrote:
| So, in other words, the list of people I have blocked on Bluesky,
| for whatever reason, is readable to everyone on the Internet
| without the use of any external service.
|
| Is this a design I'd like to use? Or a gaping privacy hole
| attempted to be explained away through "implementation reasons"?
| echelon wrote:
| It should be optionally public.
|
| Maybe I want to grab a list of those I also want to block. Or
| negatively weight.
|
| Conversely, the follow list can add positive weight until I say
| otherwise.
|
| Distributed email spam and trust lists.
|
| There's the potential for creating a strong filter bubble, but
| if the user can control their own system's behavior it still
| seems like a win.
| preseinger wrote:
| your block list has to be enforced at some point in the chain
|
| enforcement means it needs to be read-able by the relevant
| software
|
| "optionally" public means that software that can't see the
| block list can't enforce it
|
| and that means the only way to enforce the block list
| (reliably) is in your client (which presumably always had
| read permissions)
|
| this is in no way controversial
| kelseyfrog wrote:
| That would be true if holomorphic encryption didn't exist.
| preseinger wrote:
| _homomorphic_ encryption theoretically allows a block
| list to be query-able without being inspect-able, true
|
| i'm unaware of any practical implementation that would
| address the given use case
|
| if you know otherwise, please point me to it!
| anamexis wrote:
| It's not homomorphic encryption, but publishing a list of
| salted hashes seems like it would fit those criteria.
| phoe-krk wrote:
| Yes. For all the cases you've mentioned, I might want to
| share my blocklist - but it should be an option rather than
| the default. I may want to share it only with select
| individuals rather than everyone who might want to use it to
| scrape it, archive it, monetize it, and stir online drama on
| my behalf AND on behalf of whomever I've blocked.
|
| Seriously, it's worse than on Twitter. Bluesky slowly starts
| looking like "let's redo ActivityPub but so we can make money
| off it".
| jeroenhd wrote:
| I would love the ability to copy someone else's block list.
| Some various popular personalities on ActivityPub have had to
| deal with abuse from servers and individuals that I would like
| to preemptively filter out of my time line.
|
| However, that shouldn't be the default.
|
| I'm not sure why this page keeps bringing up that "people on
| other platforms can find out if they're blocked or not". You're
| always going to have ways to detect that. It doesn't address
| the conclusion "so it may as well just be public".
|
| There's something to be said for server-local blocking
| ("muting"), which this post also advocates. However, if you're
| going with that approach, why put "real" blocks in your
| protocol?
| phoe-krk wrote:
| _> I 'm not sure why this page keeps bringing up that "people
| on other platforms can find out if they're blocked or not"._
|
| The second party can find out if they're blocked by the first
| party.
|
| A third party cannot find out all the people that the first
| party blocked.
|
| That's a massive usability difference.
| preseinger wrote:
| > A third party cannot find out all the people that the
| first party blocked.
|
| the third party can fetch a list of all valid user IDs, and
| sequentially query the first party about each of those user
| IDs
|
| it takes more time and may be subject to e.g. rate limits,
| but the information is equally available
| phoe-krk wrote:
| _> and sequentially query the first party about each of
| those user IDs_
|
| Only if the third party is allowed to query whether
| there's a block between the first party and the second
| party. If the block is only visible to the first party,
| i.e. there's a view filter, then there's no good way of
| figuring this out.
| preseinger wrote:
| if a block should only be readable by the party that
| created it, then there is no reason for that information
| to be shared in the first place
| phoe-krk wrote:
| Which sort of is my point. An option to share blocking
| information with another (trusted?) person should be
| possible, but as an explicit opt-in from the first party,
| with the third party not being able to intercept this in
| any meaningful way.
| graypegg wrote:
| I'm being naive possibly, but is it really required to have
| anything more than "mute"? (To use their language "asymmetric
| block", you stop seeing their stuff, nothing changes for them in
| regards to your stuff)
|
| It's really trivial to get to accounts blocking you if all you
| need to do is open it in your browser's private/incognito/guest
| mode.
|
| I think activity pub solves this by just not notifying blocked
| accounts about new posts anyway. So you can just silently stop
| appearing in their feed. But maybe that's not feasible in
| bluesky.
| electroly wrote:
| I wonder why they even bothered. Only their client-side "mute"
| feature actually works in the presence of rogue federated
| servers, and it only takes one person to set up such an instance.
| It seems like both the federation design and the decision to be
| public-only fundamentally can't support blocks like this, and
| they just slammed it in there anyway and hoped for the best. The
| part that doesn't work is like 99% of the effort they expended
| here; the client-side mute is trivial and the only part that does
| always work.
| LegionMammal978 wrote:
| The rogue client question is addressed in the article:
|
| > In theory, a bad actor could create their own rogue client or
| interface which ignores some of the blocking behaviors, since
| the content is posted to a public network. But showing content
| or notifications to the person who created the block won't be
| possible, as that behavior is controlled by their own PDS and
| client. It's technically possible for a rogue client to create
| replies and mentions, but they would be invisible or at least
| low-impact to the recipient account for the same reasons.
| Protocol-compliant software in the ecosystem will keep such
| content invisible to other accounts on the network.
|
| That is, compliant clients are expected to mute any
| interactions between blocked users, even if rogue clients
| continue to generate such interactions. Only users on other
| rogue clients would be able to see them. So the hope is that
| almost all recipients would not be using such clients.
| michaelmrose wrote:
| This seems like a feature. One could imagine profiles that exist
| solely to categorize say nazis and essentially copying blocked
| entries or sharing blocklists between groups of accounts.
|
| Kind of like filter lists for adblock. I would like to subscribe
| to naziblock, magablock,botblock, and trollblock please.
| [deleted]
| social_ism wrote:
| Funny how quickly the industry "forgot" self moderation with
| simple "report abuse" links because they wanted to sell more ads.
|
| Moderation was solved in the 90s.
| gtCameron wrote:
| So Twitter/Blue Sky/Whatever implements a "report abuse" link.
|
| Who does it report abuse to? What happens to the post? What
| happens to the person who powered it?
| marcod wrote:
| Moderation was never solved.
|
| To name just two issues: It doesn't scale without paying a lot
| of people, and deciding what to moderate precisely,
| reproducibly, and fairly is a major unresolved issue.
|
| How can you look at twitter and facebook and make a statement
| like that?
| preseinger wrote:
| > One proposed mechanism to make blocks less public on Bluesky is
| the use of bloom filters. The basic idea is to encode block
| relationships in a statistical data structure, and to distribute
| that data structure instead of the set of actual blocks. The data
| structure would make it easy to check if there was a block
| relationship between two specific accounts, but not make it easy
| to list all of the blocks.
|
| a bloom filter provides no false negatives, but allows some false
| positives
|
| how do you model an "A-blocks-B" relationship with this data
| structure?
|
| specifically, how do you ensure that "A-blocks-B" blocks only B,
| and never C D or E?
| abracadaniel wrote:
| As I understand it, you enter a fact into the data structure (A
| blocks B). Now every time you query: is "A blocks B" in the
| data structure, it will always return True. But also very
| rarely it will return True for "A blocks C" or anything else
| that isn't true. It would make it harder to dump the full list,
| but it doesn't solve the case of "does this user block me?"
| Because you can still easily query that.
| preseinger wrote:
| > But also very rarely it will return True for "A blocks C"
| or anything else that isn't true. It would make it harder to
| dump the full list, but it doesn't solve the case of "does
| this user block me?" Because you can still easily query that.
|
| if "A blocks C" returns true when A doesn't block C, then
| this is a problem, right?
|
| it means you can trust false responses (no false negatives),
| but you can't trust true responses (some false positives)
|
| if you get a true response, you have to confirm it's actually
| true through some other source, which must not return false
| positives
|
| that other source therefore must be authoritative, and must
| also be query-able by any client that can query the bloom
| filter -- it's no panacea
|
| a bloom filter is an optimization, not a source of truth
| jrflowers wrote:
| This is a really interesting choice, I look forward to seeing
| arguments unfold about this once I finally get an account!
| jmyeet wrote:
| For some reason this is an unpopular opinion on HN but I'm going
| to say it again: federation solves a problem users don't care
| about and creates problems like this (as well as all the other
| predictable problems we've seen from decades of email such as
| spam).
|
| For context, it seems like Elon Musk is toying with the idea of
| removing blocking from Twitter [1].
|
| As another aside, I'm personally exhausted with the pet projects
| of annoying billionaires [2].
|
| [1]: https://www.techdirt.com/2023/06/09/elon-musk-says-
| twitter-i...
|
| [2]: https://www.nationalreview.com/news/twitter-founder-jack-
| dor...
| klabb3 wrote:
| > federation solves a problem users don't care about
|
| The main problem federation solves is centralization of power
| and perceived abuse of that power. The type of stuff that
| caused the Twitter exodus and now Reddit. I'd argue that many
| users do care about that, but I would concede that it's not
| clear that federation will solve those problems. Instance
| operators can go on equally destructive power trips, the way eg
| AP and mastodon are designed.
___________________________________________________________________
(page generated 2023-06-11 23:02 UTC)