Regardless whether you want to pretend that not caring about Mastodon is a valid defense when implementing software using the ActivityPub protocol, that still doesn't change anything regarding how Dansup handled the disclosure of the effects it had.

[–] PhilipTheBucket@ponder.cat 9 points 1 day ago (17 children)

This is nothing to do with ActivityPub. It's to do with Mastodon's custom implementation of "private" posts.
Making it extremely clear to everyone that random server software can expose Mastodon's "private" posts is absolutely the right way to handle disclosure here. Dan didn't even try to do that, he just fixed the bug, but if he had made a big post saying "hey this is not my fault Mastodon private posts are not private, here's full explanation about what's going on" I think that would have been completely fine. This is not a "vulnerability" in the traditional sense like a buffer overflow, it's just a design flaw in Mastodon which other softwares are by convention agreeing to cater to. I think the culture of security (and the level of clue in general) in the Fediverse has wandered into territory where "let's all pretend that these posts are secure and get mad at anyone who reveals that they are not" is widely accepted now, but that doesn't make it right.

[–] troed@fedia.io 5 points 23 hours ago (7 children)

It has everything to do with ActivityPub since if you follow that protocol strictly you will cause this behavior. It still doesn't change that Dansup was told that this caused Bad Things(tm) and yet he didn't follow normal procedure in how you handle it.

Vulnerabilities don't need to be buffer overflows.

/cybersec researcher

[–] PhilipTheBucket@ponder.cat 5 points 23 hours ago* (last edited 23 hours ago) (1 children)

It has everything to do with ActivityPub since if you follow that protocol strictly you will cause this behavior.

Absolutely not. Which part of the spec? I linked up there to quite a thorough explanation of what the spec does and doesn't dictate in this area, and how Mastodon chooses to behave in its implementation. What part of my explanation did I get wrong? Are they violating 5.1, 5.2, 7.1, some other part? How?

/cybersec researcher

I do not believe you. "I'm sending things out which need to be handled carefully in a protocol-nonstandard way by the recipient server software (which could be literally anything), or else my user's private posts will be exposed. If someone talks about that situation and lets people know what's going on, that's irresponsible disclosure."

If you actually are a cybersec researcher, you are bad at your job.

[–] troed@fedia.io 2 points 23 hours ago (1 children)

hahahahaha

Watch and try again ;) I post under my real name.

https://www.cve.org/CVERecord?id=CVE-2024-44754

https://www.youtube.com/watch?v=ZbKLAjPYOEg

Feel free to post less and read more.

[–] PhilipTheBucket@ponder.cat 4 points 23 hours ago (1 children)

Okay. What part of the spec did Pixelfed violate? Where in the spec is Mastodon's implementation of private posts justified?

[–] troed@fedia.io 2 points 23 hours ago (1 children)

Read more, post less. I've said nothing about any spec violation. That's not relevant.

[–] PhilipTheBucket@ponder.cat 2 points 22 hours ago* (last edited 22 hours ago) (1 children)

I’ve said nothing about any spec violation. That’s not relevant.

It has everything to do with ActivityPub since if you follow that protocol strictly you will cause this behavior.

That's what I was going by. I guess I could re-read this now and interpret "this behavior" as Pixelfed's side, instead of Mastodon's side as I initially read it, and decide that you are agreeing with me that Mastodon's behavior was (and is) out of spec? Do I have that right?

It still doesn’t change that Dansup was told that this caused Bad Things™ and yet he didn’t follow normal procedure in how you handle it.

It is normal procedure to fix a bug when you are notified about it.

The design flaw in Mastodon that managed to bite Pixelfed in this situation still exists. People were writing about it back in 2017 when this was all being first implemented. The idea that "normal procedure" needs to include keeping it a secret that Mastodon's "private" statuses can be exposed by any server software that doesn't handle them in the way that's expected, is 100% wrong.

I'll rephrase what I said earlier: Since you're a security researcher, and you apparently think Dan should have played into the idea of keeping it a secret that Mastodon's private statuses are not secret by obfuscating the information about how he was fixing Pixelfed to more effectively hide them, you are bad at your job. In this instance. The fault lies with how private statuses are implemented, and nothing about that needs to be kept secret as would a normal vulnerability, during responsible disclosure. In fact, it is extremely harmful to let users believe that these privacy settings are anything other than vague recommendations, specifically because of the risk they will act accordingly and expose some of their private posts to the world. They should know exactly what's going on with it, and Dan accidentally failing to keep that a secret is in no way causing bad things.

[–] troed@fedia.io 2 points 22 hours ago (1 children)

You have absolutely no idea what "responsible" in "responsible disclosure" means :) It's completely irrelevant how Mastodon has implemented private posts when it comes to how Dansup handled the issue, knowing what the effects were.

You don't, when told of a vulnerability, handle it in a way that cause harm if it can be avoided.

[–] PhilipTheBucket@ponder.cat 2 points 22 hours ago

Yeah, you said that stuff before and then you said it again. I do understand what your argument is here. I was trying a couple of different ways of explaining what I was saying in response, but it seems like it's not working. Oh well.

load more comments (5 replies)

load more comments (14 replies)