Anonymous opt-out

[TransCommunist69]

I would like to opt-out from your service but I am not comfortable with giving my account name or my instance domain for you to put in some sort of list somewhere.

The fact that you are collecting a list of vulnerable queer people that dont want to be harassed by bluesky is deeply unsettling and I cant trust you to not use that list in any way that could cause harm to vulnerable queer people on the fediverse.

It would be safer if this could be handled in a anonymous way where you cant have any access to plaintext usernames or instances that want to opt out of your service.

[hobbes]

this is so obvious, it's even strange that you need to explain it...

[Sketch6307]

So then put the tag in your profile. Or just don't make it public since that means the same people who could see it via the bridge can see it anyway. This is so obvious, it's even strange that you need to explain it...

[hobbes]

yeah, wear a sign. Or even better, hide. People around you can already see you, why do you complain about video surveillance ? Please don't ask me to consider your problems.

[Sketch6307]

LOL.

It's not a yellow star.

I don't; I recognize that I have no expectation of privacy in public.

I won't; it is not a stranger's responsibility to consider my problems.

[Sketch6307]

The OP is the one who wants to hide, by the way. I only advised them how to do so.

[Yinchie]

It isn't difficult to put #nobridge on your website.

[hobbes]

It isn't difficult to put #nobridge on your website.

so requiring that people who want to use the service say so is not ok, because many people won't hear about it, so won't be able to state that they want to use it.

But requiring that people who don't want to use it put #nobridge in their profile is ok, because... most of them will hear about it ?

And then someone else makes another software that I don't want to use, and I have to put #noplop, then #nobs2, then #noai, then #nocrawl, then... don't you see why that line of thinking is a problem ?

[Yinchie]

That has been the standard business for years. robots.txt exists also for that reason, to block certain bots - if they obey the rules. The Internet is open and public in general. Fediverse is fully open and public.

Webmention is also a W3C standard. Which you can't even opt-out for.

Anything you place out in the open, is out in the open to be read, shared, copied, used by others.

If you don't want your comments, written text or whatever to be out in the open, go to platform X, where nobody without an account can read it etc etc.

[hobbes]

so basically, google being a giant assh*** means that you can be a tiny assh***, it's not a problem. Nice reasoning.

For the rest, data that is publicly accessible is not public data. Plenty of things are publicly accessible and yet you can't use it. Download facebook's assets to copy their design for your website, and see how it goes. Even better, use a Disney character on your website, good luck with that 😃 (hint: no, don't do that, really)

Another analogy: anyone passing by can see my garden, or in my living room through my windows. That does not mean that I would accept or be comfortable with someone installing cameras to observe everything I do there. The fediverse is a group of interconnected isles, where people can interact together and keep control. BS is... let's just say that it's not that.

Now the good thing is that I don't have to convince you. Just @snarfed . He can take the multiple hints that he received those last days, or not. In that latter case, I'm afraid that his system will simply get defederated into near irrelevance, hopefully without adding too much weight on fediverse admins.

[srd424]

One might be able to do something useful with hashes to anonymize opting out .. but then I guess you'd end up having to somehow protect against people maliciously opting-out third parties? (To effectively DoS the bridge or whatever.)

The suggested opt-in model might be a lot easier, on balance.

[Yinchie]

Now the good thing is that I don't have to convince you. Just @snarfed . He can take the multiple hints that he received those last days, or not. In that latter case, I'm afraid that his system will simply get defederated into near irrelevance, hopefully without adding too much weight on fediverse admins.

Even if he gets defederated, your content can still be taken elsewhere.
Mastodon has a public JSON feed and as I mentioned before, there is a thing called Webmentions, which also takes your content and can be posted elsewhere if the person using Webmentions decides to.
There are already multiple websites that take data from that JSON and put the comments placed on Mastodon, onto their website.
Available data = available data. Public = Public.
Here is an example how to do it with using the JSON.
https://carlschwan.eu/2020/12/29/adding-comments-to-your-static-blog-with-mastodon/

What happens in your home is not public.

If you think you own the control about anything you post online, dream further.

[snarfed]

This is a fascinating idea, and a good conversation, thanks all.

I'm curious about prior art here. Does anyone know of existing systems that do something like this? Ie provide some opaque id, let a system compare a plaintext id against that opaque id (or some aggregation), but otherwise prevent them from checking if a given plaintext id is in the set?

It sounds either difficult or impossible, since those two requirements seem like the same thing, but fields like zero knowledge proofs and homomorphic encryption regularly surprise me with the things they can do that seem impossible.

[srd424]

I have very few functioning brain cells these days, but I wonder if any aspects of https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity would be applicable here?

[bkil]

I think it is worthwhile to split this issue in two:

• One is (perhaps rightfully) not comfortable with you storing all user handles in a CSV unencrypted all the time -> many solutions exist. I think this is the major issue for the original poster. You could protect the data better by salt & pepper. You could even enact a security boundary by storing it (hashed) on another node and only access it via some sort of zero knowledge proof scheme.
• A second issue would be a user not trusting you at all with their handle. This is more complicated, because in this case, why would they trust that you would honor their (anonymized) request in the first place and not just go crawling anyway?

[bkil]

Regarding not trusting you with the handle: regardless of how it is stored or fetched when accessed, in the end, you will have a trivial way to brute force any and all Fediverse handles you encounter through instance directories, posts, likes, reshares, mentions or even normal web crawling. A malicious operator could test each found handle against its set and then record it in the clear if they want to go rogue. So assuming a malicious operator would probably not leave us with a usable service.

At the same time, the confusion set is already of a decent size, hence it might not pose an additional privacy risk. People may want to opt out for various reasons, and the exact reason would not be recorded:

• copyright - be it for commercial or ethical reasons (against statistical learning scrapers)
• GDPR - right to be forgotten, not allowing to handle data on unknown servers, etc.
• harassment - be it due to political ideals vs. country of residence or relating to minorities with protected attributes
• not having sufficient bandwidth for dealing with new "rando" subscribers (i.e., preferring friends of friends or direct contact exchange instead)
• still just trying out the Fediverse, undecided what it has to offer and whether they will stay, or in general using it in a "transactional" way rather than as a "durable publishing platform of durable links" and hence are not comfortable with replicating it in a way that possibly makes it immutable
• the instance they are registered on has special terms of service that outsiders may not be aware about and hence their incoming content could also be in violation
• YAGNI - what if they will later decide to opt-in the first time they befriend someone requesting it, but otherwise chose to reduce the potential attack surface according to security best practices?
• TODO

[hobbes]

Even if he gets defederated, your content can still be taken elsewhere. Mastodon has a public JSON feed and as I mentioned before, there is a thing called Webmentions, which also takes your content and can be posted elsewhere if the person using Webmentions decides to. There are already multiple websites that take data from that JSON and put the comments placed on Mastodon, onto their website.

as said multiple times, that's not the point. Others doing it does not mean that it's ok.

Available data = available data. Public = Public.

as said multiple times, publicly available data != public data.

What happens in your home is not public.

Exactly. Even if people can see it, it's not public. Same for what you do in public: it's definitely not available for anyone to do as they please, even if you do it on the street.

If you think you own the control about anything you post online, dream further.

journalists, artists, web designers, communicators,... routinely post public online content that is definitely not public data. A friend of mine posts his photos on his website, and won a trial against a big American film corporation because they used one of his photos without credit for a blockbuster promotion. A small Belgian photograph against an American big studio, a photo publicly available on the web, and he won.

If you think that what is publicly available on the web is public data, dream further.

[snarfed]

Hopefully discoverable opt in #835 (comment) may obviate some of this. Users and admins can just block the bsky.brid.gy domain, which has the same effect as asking me to opt out. If someone requests to follow them via Bridgy Fed, it will attempt to send them a DM, which will fail, and so they'll never be bridged.

[MadokVaur]

"Users and admins can just block the bsky.brid.gy domain, which has the same effect as asking me to opt out..."

How can users just block the bsky.brid.gy domain when I (as a mere Mastodon user) have repeatedly searched from the "Search or paste URL" field on my profile page and have yet to see any sort of Mastodon/Fediverse instance name returned?

I am not an instance admin. I can only block those domains which return a Fediverse-compatible domain name page from my search.

I will also note that "bsky.brid.gy" does not return any response from the Server search page at FediDB, here: https://fedidb.org/network

[snarfed]

@MadokVaur good question. The Bluesky bridge hasn't launched yet, it's probably at least a month away, which is why you're not finding any bsky.brid.gy profiles. How to block domains as a user varies across different fediverse software, but if Mastodon only lets you do it after you've found an existing user on that domain, then you're right, you can't block it as a user yet. If so, that's definitely an unfortunate surprise.

The Mastodon docs don't explain this very much, https://docs.joinmastodon.org/user/moderating/#block-domain , but you might be right. If so...ugh.

[MadokVaur]

Thanks for your reply

"The Mastodon docs don't explain this very much..."

There's a lot the Mastodon docs don't explain. But I digress...

[TransCommunist69]

Users cant do instance blocks on any fedi software that i know of so you will need to convince your instance admin about the danger that this bridge poses to our safety. And to be safe you probably also need get admins from all instances that your friends are using to also block this bridge.

I still hope that all the massive safety issues will be fixed but if this bridge goes live before addressing them then i will be doing everything i can to agitate for wide #FediBlock of brid.gy in order to protect all my lovely trans comrades

[MadokVaur]

Well, I've blocked many, many instances in 14 months on three different Mastodon instances as a user, so I'm quite familiar with how to do it.

And my instance admins are pretty on top of most situations so I'm not concerned from that direction. Probably busy today with that burst of Japanese Misskey spam. Did some domain blocking there, just in case.

[TransCommunist69]

You might be right it's quite long time since i used mastodon. but atleast with sharkey users can only mute instances not block them

[Sketch6307]

It isn't difficult to put #nobridge on your website.

so requiring that people who want to use the service say so is not ok, because many people won't hear about it, so won't be able to state that they want to use it.

But requiring that people who don't want to use it put #nobridge in their profile is ok, because... most of them will hear about it ?

And then someone else makes another software that I don't want to use, and I have to put #noplop, then #nobs2, then #noai, then #nocrawl, then... don't you see why that line of thinking is a problem ?

Quite the contrary. Requiring some developer who you don't know to do what you want instead of what he wants is not okay. You can decide how the bridge software that you develop works.

[Sketch6307]

so basically, google being a giant assh*** means that you can be a tiny assh***, it's not a problem. Nice reasoning.

For the rest, data that is publicly accessible is not public data. Plenty of things are publicly accessible and yet you can't use it. Download facebook's assets to copy their design for your website, and see how it goes. Even better, use a Disney character on your website, good luck with that 😃 (hint: no, don't do that, really)

Another analogy: anyone passing by can see my garden, or in my living room through my windows. That does not mean that I would accept or be comfortable with someone installing cameras to observe everything I do there. The fediverse is a group of interconnected isles, where people can interact together and keep control. BS is... let's just say that it's not that.

Now the good thing is that I don't have to convince you. Just @snarfed . He can take the multiple hints that he received those last days, or not. In that latter case, I'm afraid that his system will simply get defederated into near irrelevance, hopefully without adding too much weight on fediverse admins.

robots.txt predates Google by about a decade. You don't even know the beginning of the stuff you're talking about.

[snarfed]

I appreciate the debate, but let's try to keep this issue focused on anonymous opt out, please, everyone.

[reyafyi]

provide some opaque id, let a system compare a plaintext id against that opaque id (or some aggregation), but otherwise prevent them from checking if a given plaintext id is in the set

dude that's called hashing
you could ask people to give you e.g. sha512 (maybe with multiple iterations) of their fedi handle, for you to check
or bcrypt-ed

[snarfed]

@reyafyi hashing alone only gives you the first part there, not the second.

[Sketch6307]

It is not possible to be able to check if an ID is in a set, without being able to check if the ID is in the set. What even...

[jfietkau]

As a Mastodon user, you can block a domain even if you don't yet have access to a post on it by importing it as a block list.

1. Edit profile
2. Import and export
3. Import
4. Import type: Domain blocking list
5. Data: A CSV containing the domain(s) to be blocked, I'm attaching one that blocks the Bluesky bridge
6. Make sure (!!!) it's set to "Merge" and not "Overwrite"
7. Upload

@MadokVaur FYI

[bantryblues]

Will the bluesky bridge examine each fediverse reply to a fediverse post before sending all those replies to bluesky?

Suppose:

1. fediverse account A opts-in and is followed by bluesky account B
2. 100 fediverse accounts reply to a post from account A
3. account B at bluesky asks to see the replies to a post on the fediverse account they follow

Will the bluesky bridge check all 100 replies and only send replies from accounts who have opted-in?

That is an issue that was used as justification for needing opt-out -- is the plan to send requests for each reply and only send on the ones the bridge already has opt-in for?

IMPORTANT POINT ABOUT BLOCKING BRIDGE DOMAIN
Blocking the bridge domain doesn't prevent the bridge from getting replies from people who have not opted-in. - it will get all the replies and will need to filter out the ones it doesn't have permission to send

[bkil]

I still think that the second part of the problem (untrusted bridge operator) is not solvable completely and hence any effort in that direction is LARP'ing with many drawbacks.

If you still insist, one such workaround would involve:

• when a user registers on a Fediverse instance, their server would offer a choice for them to specify metadata about their feed: archiving, mirroring, web search indexing, statistical text mining, copyright, embedding, bridging, bot requests, etc.
• the operator of each Fediverse instance would publish a list of hashed & peppered handles of their own who have opted in to the bridge, signed with their PGP key and timestamped
• the operator of each bridge would periodically fetch this list (and optionally mirror it for others), and use it to decide whether a given message or reply is allowed to be forwarded or not

I think any anonymized/hashed list not backed by the respective instance operator of the domain would open the possibility of trivial DDoS of a bridge as already mentioned.

[snarfed]

@bantryblues let's keep this issue focused on anonymous opt out. I've filed a separate issue, #894, for your questions.

[bantryblues]

@snarfed thanks for opening the new issue!

the reason I mentioned it here was someone suggested blocking the domain as a solution to this issue - but I should have started a new issue and just referred to it here.

[snarfed]

Bridgy Fed is currently opt in for the fediverse. I plan to add DM prompts for discoverable opt in - #1148, #966 - but I don't plan to switch it to opt out in the fediverse anytime soon.

Also, we haven't yet seen a technically feasible solution here yet, ie "It is not possible to be able to check if an ID is in a set, without being able to check if the ID is in the set." (#878 (comment)).

So, I'm closing this as obsolete. Happy to hear more thoughts if anyone has any though.

[qazmlp]

It's likely already supported (implicitly). If an individual user either blocks the entire bridge domain or mutes the service account, their home instance will take care of permission management for this without even notifying Bridgy Fed of those actions.

It also normally shouldn't send any activities towards the bridge if there's a domain block, but I don't know if that's usually a hard filter or just a result of there being no connections or interactions with bridge content (in which case this could differ if Bridgy acted as ActivityPub relay at some point, i.e. for instance-wide opt-in by admins. In that particular hypothetical case users may indeed have to undo the opt-in by blocking the service account individually).