Found this via Aurynn Shaw:
When following someone on a different server on the Fediverse, the remote server decides whether you are allowed to do so. This enables features like private accounts. Due to an implementation mistake, Pixelfed ignores this and allows anyone to follow even private accounts on other servers. When a legitimate user from a Pixelfed instance follows you on your locked fediverse account, anyone on that Pixelfed instance can read your private posts. You don’t need to be a Pixelfed user to be affected.
Pixelfed admins should update to v1.12.5 ASAP, but upgrading can be a major hurdle.
Importantly, your Mastodon or GoToSocial instance isn’t handing your private posts to any random server, just because it asks. The problem only becomes apparent when you have at least one legit accepted follower from a Pixelfed server. Now that server is allowed to fetch all your private posts. And when it knows the posts, it has to decide who to show them. When you accept a follower, you not only place your trust to keep a secret on them, but also on their admin and the software they are running.
Edited to add the last block quote.
Give it a rest. A fork of Mastodon created a new abstraction for “private posts” and started sending to instances some posts that were marked in a new way as “private,” and now they’re trying to blame Pixelfed for not adopting their homemade standard for what posts their servers are sending out to everyone that they’re not supposed to show, and what ones they are supposed to show. And, Pixelfed fixed it once they became aware of the issue.
It’s fixed in 1.12.5. Why is this not titled “Mastodon instances claim to their users to offer ‘private’ posts but send them out exactly like normal posts, get surprised when software that hasn’t magically adopted their new standard is showing them to people”?
Honestly pixelfed should have just not fixed it. It’s a fediverse problem that can be fixed and mastodon is just misleading people.
Platforms should either make it clear that it means just that the post isn’t advertised by default on all platforms but is always accessible to anyone that wants it or actually implement e2e encryption.
I’m not sure I would go that far. A lot of “trust and safety” type things are like this, just soft boundaries to try to shape the types of interactions people are going to get themselves into to be a little more on the pleasant side. There’s nothing wrong with Pixelfed trying to show some honor to the same advisory boundary. The real problem comes into it when projects like Mastodon start giving people the impression that “private” posts that are federated out are going to be able to stay private. As long as the user expectation is clear that it’s just an advisory setting that will tweak the algorithms for showing the post in non-assurable ways, it is fine.
audience targeting is NOT a new abstraction by mastodon, it’s part of ActivitySTREAMS, not even ActivityPUB
rtfm and do NOT give a rest to bad behaving software
I did a whole analysis of what the spec actually says, how it relates to “private” posts, and Mastodon’s implementation details. TL;DR they just made things up and it’s a huge disservice to Mastodon users to give people the impression that these posts are private.
linking barely relevant threads is a bit annoying
your complaints on “unlisted vs public” are completely unrelated to the issue at hand
your analysis that relates to this pixelfed flaw is just:
Privacy Enforcement:
- No explicit requirements for how receiving servers should restrict visibility based on audience fields
- No requirements that servers must hide content from non-addressed users
these aren’t good analyses: content should be private by default, nowhere is stated otherwise. if you feel like this common sense practice is somewhat arbitrary, it’s actually mandated by GDPR and more data protection laws.
if you want to rule lawyer that “acktually spec doesnt EXPLICITLY say that you cant show stuff meant for alice to bob if bob asks” and ignore this web good practice (probably implied by the many privacy remarks in the spec but let’s ignore those) which is actually mandated by governments, feel free to still ignore the incompetence displayed by dansup in implementing something that every other fedi software managed, go for it
even if you were right, even if the spec was really that vague, even if it wasn’t a good practice and requirement, in a federation parties cooperate. pixelfed breaking a common agreement is defederation worthy, and dansup remains either incompetent for implementing badly something easy or toxic for federating ignoring what the federation requires
you’re still not addressing the point, just linking other posts back and forth and moving the goalpost
content should be private by default, nowhere is stated otherwise
This is completely false. Read section 7.1, “Note: Silent and private activities”. It specifically says that privacy behavior, for activities with no recipients at all, is undefined. It recommends not showing them to anyone, obviously, but that “behavior is not defined” has a very specific meaning in a specification document. It means, if you sent an activity of that type to someone, trusting that they would then keep it private, then you fucked up, because behavior in that area is undefined and cannot be relied upon.
That’s not “rules lawyering.” That is how specification documents work. That’s an important note, which I suspect is why it is highlighted and in its own separate box. There are some similar parts of the document, involving the big word “MAY” in all caps where they had the option of writing “SHALL” or even “SHOULD”, to indicate that a server had to keep certain things private, that follow the same philosophy.
None of that means you can’t use some common sense. It’s obviously not good to be handling intended-to-be-private information in some way that the sender doesn’t expect, and that’s why Dansup fixed it quickly when it was brought to his attention (particularly since the issue wasn’t even directly related to access control on private posts, just in a subtle interaction involving approved-followers-only users and a setting that was failing to federate). My point was just on the broader issue, that if Mastodon is sending out “private” statuses to random servers, then this is at the root a Mastodon issue. The quick fix (regardless of whatever it was about that made the blog poster even more upset when Dansup took it seriously and fixed it quickly) puts the lie to your assertion that Dansup is “toxic” “ignoring what the federation requires” and so on.
I suspect that we’re going to keep going around in circles on this forever. I have a new strategy when someone is just endlessly arguing with me about some weird minor issue. I just make a new post dealing with the issue in more depth, so that it’s not just you and me endlessly going in circles deep in the comments at each other. You’re welcome to come to that post, and continue the conversation there, if you’d like to:
I wouldn’t call it Pixelfed’s vulnerablility, but a reminder that nothing on Fediverse is private. Even if Pixelfed is fixed, someone can create rogue instance to read other’s private posts.
If I understand it correctly, it’s kind of both. Sounds like Pixelfed didn’t follow best practice setting privacy guardrails in follow request approval, and it exacerbates the inherent lack of privacy on the fediverse.
You’re right of course, anyone (with the coding chops) could’ve intentionally set up an instance that does the same for malicious purposes. That should be a wake-up call for anyone who thinks ActivityPub is a great sexting medium.
receiving posts is trivial but you need to convince others to send it to you. i can’t just set up a malicious instance and get your private posts, i need to convince you to send them to me, and once convinced i can use any normal software to access it, no malicious custom thing needed. literally just follow me from a mastodon.social throwaway and you get my followers-only posts. content addressing is great on fedi and your instance sends your private posts exactly to who you want and noone else. pixelfed receives a private posts and shows it to third parties, its not the system’s fault.
fedi is not great for sexting because your pics just sit in clear on your server admin’s machine and all dms are easily searchable on db, it’s a whole other issue
The whole point of this issue with Pixelfed is that none of what you describe is required.
Find any follower of a Fediverse account of any kind (Target Account) that’s on a Pixelfed server. Go to that Pixelfed server, view “private” posts from Target Account there.
No need to set up a server, or get sent anything. Granted, even without this flaw ActivityPub is not the way to go for anything private.
even without this flaw ActivityPub is not the way to go for anything private.
This is the real issue. The whole story about how his partner’s posts were getting shown to random people should have ended with both of them realizing that these posts were in no reliable way “private,” and to stop putting them up with the assumption that they would be. Not with them yelling at Pixelfed for the way it works, and then yelling at Pixelfed again for starting to honor these fake privacy settings.
I dont know about other fedi services, but lemmy tells you at message composition, that DMs are not safe/private. If pixelfed doesnt do this, then that is really the issue.
I kinda of lean towards the idea of “private accounts” being a bad idea as a result, just because it creates a false sense of security. But I’m not in the target demographic so idk
Yeah this just sounds like one of the drawbacks of a federated system. In order for people on remote servers to be able to see your “private” posts, your local server has to feed that info to them and trust them to handle it appropriately.
private posts are only sent to instances that either your followers or the list of people you want to see the post are on. If they all co-operate, you will be fine.
if they all cooperate
Gonna stop you right there
Its like email, an email server can decide to expose everyone’s emails to the public, so don’t add that email to your mailing list or email chain.
100% yes. But I think people also drastically overestimate the chain of trust within email. Never send anything over email that you don’t want going all over the place.
I really wish people (normies) could figure our pgp for email.
private posts are only sent to instances
Well, obviously they’re sent to some other ones, or else this wouldn’t be an issue.
This is a design flaw in the protocol. If your instance is going to send your private posts to other people, they’re not private. The authors need to fix your instance software, not demand that every other software in existence needs to “cooperate” and find out whether they’re “private” and not show them to the users if they are.
this is wrong, you’re assuming incorrectly. private posts get sent to only intended recipients. pixelfed allows other recipients on the same server to read that. it’s not your instance software, it’s pixelfed, please dont spread misinformation based on uninformed assumptions
No, Imagine this
There is @bob@pixelfed.example their is their friend, @joe@mastodon.example. bob also follows @jane@gotosocial.example
If bob makes a private post (ie, followers only), only the instances of people he follows will recieve the post. The instance will see that its supposed to be private, and not show it to everyone.
This may, gotosocial.example, mastodon.example and pixelfed.example have the post, but don’t show it. misskey.example won’t have the post.
Then, if gotosocial.example (hypothetically) had a bug where it ignored posts visibility settings, those posts would be shown, since the post is sent to that server. If misskey.example had a similar bug, nothing would happen as the post wouldn’t have reached that server anyway.
Yeah, so there’s no real way to implement private posts on Mastodon.
I mean, it is fine if you want to implement sort of “best effort” semi-privacy and make it clear to everyone involved that that’s what it is, but for any reasonable definition of “private,” the requirement that it not get shown to people outside the list of people allowed to see it needs to be enforced better than this. There will always be server software that doesn’t “cooperate.” That’s just the nature of open distributed systems. If you’re making assurances to your users that their posts will be private, you need to be the one enforcing that, not everyone else on the network and the protocol needs to be set up with the ability for that to happen (which ActivityPub is not, which means it’s misleading that someone told users that they can have “private” posts via this hack.)
email works the same way. it’s impossible to implement private emails? if you cc your email to im.going.to@leak.it and it leaks, would it be fair to complain about the whole email system?
e: should have read deeper first its already been said
I wouldn’t consider it a hack, as the protocol was actually made with these posts in mind. Public posts weren’t the focus of activitypub.
I would consider it similar to email, should we abandon it (yes, but not because of this) just because a malicious email server started publishing all the emails it recieved? AP is just email but social media.
I would consider it similar to email, should we abandon it (yes, but not because of this) just because a malicious email server started publishing all the emails it recieved? AP is just email but social media.
Yes, and people implemented PGP for encrypted email, and also made SMTP over TLS the standard, so that they wouldn’t have to demand that every router and every SMTP server everywhere on the internet agree not to republish or store secret information that was passing through it, because it started to become understood that email was in no way private.
A proper standard for private posts would be similar. You could have all private posts be encrypted with a rotating key, for example, and have them decrypted by anyone who had the key, on the client side, and stored and transmitted in encrypted form. Being approved to follow the private posts would involve your user being given a copy of the key through some kind of private key exchange. It sounds complex (and it would be, a little), and it would involve moving to the client some of the key management that currently happens on the instance server (and thus undoes some of the actually good design of ActivityPub, by just putting the instance software back in the position of keeping every actor’s keys for them and doing all the crypto work on behalf of the users). Anyway, it would be work and involve some redesign. I’m not saying that’s what they should have done. I’m saying that’s what having private posts as a feature would mean. Anything else is non-private posts that are pretending to be private posts.
Posts should be encrypted, this is what diaspora does. I agree with this. For emails though, pgp is used by no-one. Also, AP uses tls as well.
I was thinking that encrypted posts could work with multi key encryption (if my understanding of this post is correct https://stackoverflow.com/questions/597188/encryption-decryption-with-multiple-keys ).
The problem (imo) is mastodon being the internet explorer of the fediverse, and refusing to do any encryption.
Wait, are new instances federated by default?
I thought admins had to choose who they were federated with.
There’s easily over a thousand fediverse instances at this point, having to whitelist them all would be impractical.
Okay but this demonstrates why defaulting to federation is a bad idea, doesn’t it?
Defaulting to not federating is what the major email providers currently do, and is why email has now become a centralised service that you cannot practically self host.
The issue is that if you don’t default to federation, it becomes essentially impossible for new instances to join the fediverse. A potential new instance would have to go around to every single existing instance and ask to be allowlisted, which is onerous for both the new instances and for the large server admins who would be getting tons of requests. It would also essentially kill small-scale selfhosting as a result.
The entire point of the fediverse is to federate. Not federating by default kills discoverability and the potential for discoverability among other things
It demonstrates that nothing on the fediverse is private, and bad hacks that pretend otherwise are a terrible idea.
Imo it demonstrates that for certain threat models the fediverse simply doesn’t have the 100% secure answers.
The private account would still need to accept a follower from that rogue instance.
Yes, but account/instance would need to actively research which instances are rogue, and beware of them. It could be solved by creating tool which would automatically detect this
vulnerabilityfeature.If you have a private account, why would you accept a follow from a user on a rogue instance?
I guess you would need to trust your friend to vet whatever instance they join. And you’d have to vet that you aren’t getting catfished by a threat actor using a friends identity but those are all problems regardless of whether that’s fixed since a malicious admin would have access to your posts so your friend can subscribe to them in the first place, whether this is fixed or not
Edited to add: I got this around the wrong foot, see the reply to this. /edit
Not necessarily, as clearly stated in the linked article:
But sure enough, the toot was followers only and the person that had liked it was not following her Mastodon account. When I took a look at the other persons profile on pixelfed.social, I noticed that the instance was nevertheless claiming the account was following her.
When pixelfed assumes that an account is not locked, it immediately treats a follow attempt as completed. For the server on the other end it looks like a normal follow request. It could be rejected, and pixelfed would still be convinced that a follow relation exists.
Abolutely necessarily.
it works like this:
@privateuser@mastodon.example.comhas a “followers only account”.@someuser@pixelfed.example.comis a friend of above account, requested access and was granted. This now causesmastodon.example.comto push all messages of@privateusertopixelfed.example.com.@anotheruser@pixelfed.example.comrequests access, but gets ignored. But the pixelfed instance marks the user as “follows@privateuser”- In the interface of
@someuser, the messages are shown as expected. - In the interface of
@anotheruser, they are also shown. Because PF basically does a database “select messages of users that the user follows”, without checking if the access was ever granted.
Important to note, that this would not happen, if the messages weren’t already pushed to the server due to the “allowed” user
Yes, necessarily.
Importantly, your Mastodon or GoToSocial instance isn’t handing your private posts to any random server, just because it asks. The problem only becomes apparent when you have at least one legit accepted follower from a Pixelfed server
Ah, good catch. Thanks!
Yep, it’s cool for public stuff, but we still need private forums
if you deliver a letter to your cousin, and they leak it to all their friends, is it the post system’s fault? instances federate by default, but private posts require actual intention. if i make a private post, explicitly mark it as private, deliver it to your instance and then your instance leaks it, i’d blame the instance, not the system. even signal can leak if you send your stuff to unintended parties.
someone can create a rogue instance
you shouldn’t send private stuff to unreliable parties. big software and big instances have a reputation, and it’s constantly up to you whether sending them something or not. when @sus@totally.legit follows you, check where they’re from. if you just accept follows left and right, are your followers-only posts really private? and if you direct message someone on some sketchy instance, you still need to trust them to respect your privacy. it’s the same on signal, e2ee doesn’t make a difference
this is why i completely blame pixelfed here: it breaks trust in transit and that’s unacceptable because it makes the system untrustworthy. you can get followed by sketchy people on mastodon.social and they will only see what you send them. in this case, other people can see what you post, regardless of you sending it to them or not, and regardless of the target leaking it or not
Some more US war plans?
Whut. I mean, probably, but not in this thread?
I didn’t even know “private” posts were a thing on the fediverse but now I guess I know to watch out for that. Maybe I’ll post some privates after losing about 30 lbs
does it only effect privates? what about officers, like, say, captains?
Its like email, if a server decided that it would expose everyones emails, everyones emails are exposed.
well that’s not good
Nope. It looks like crash testing security in production, or “fuck around and find out” with other people’s privacy.
periodic reminder to not touch dansup software and to move away from pixelfed and loops
dansup is not competent and quite problematic and it’s not even over
developers with less funding (even 0) contributed way more to fedi, they’re just less vocal
dansup is all bark no bite, stop falling for it
It’s a failure on the part of mastodon. I don’t really care about whatever drama dansup is embroiled in. Mastodon shouldn’t imply a post is only readable by followers when it’s just a public post that doesn’t show by default in their frontend.
how is it a failure of mastodon that pixelfed doesn’t respect audience targeting? it’s not like it’s something that mastodon made up, this isn’t about unlisted/public
Periodic reminder that shitting on someone who’s making free software and giving it away is an entitled, counterproductive, selfish thing to do.
I have no interest in using Pixelfed or Loops, it’s just not my thing. But the idea of criticizing the person who’s making them because of a variety of made-up reasons is a bunch of crap.
Also, fedi developers should get paid. They’re doing work. They should get paid. The idea that someone who’s optimizing the video pipeline for the next ad network can make $150k a year and it’s a problem if Dansup fills up his fundraiser because people love the stuff he’s already done is, also, a bunch of crap.
variety of made up reasons
you are not engaging with the argument, just stating ideals
fedi developers should get paid? yes, look at gts and mastodon
fedi devs should also be held accountable of their fumbles
dansup showed quite some incompetence in handling security, delivering features, communicating clearly and honestly and treating properly third party devs
it’s fair for one person to not be able to handle a big software with big instance and big usercount. mastodon has a legal entity and a team, gts has no flagship instance, is aggressively open source and gathered a lot of contributors, dansup is winging it alone and failing
let’s just make a big fixed point of failure of dansup, what could go wrong … ?
check out mitra too, could probably use some funding because it’s transparent and delivers rather than promising the moon and delivering CVEs (but with a grant AND a kickstarter, maybe pay some other devs???)
like there are thousands of fedi projects, give 10 bucks to the little dev doing it for fun in their bedroom, more money will not make dansup more competent
you are not engaging with the argument, just stating ideals
Correct. I’ve engaged in the past with people who are convinced Dansup is committing some kind of horrible sins. I examined the arguments in detail and decided they were bullshit.
I don’t really feel like rehashing the arguments again, but you can read if you want to see them:
https://ponder.cat/post/1151008/1352919
https://ponder.cat/post/2151188
I actually wanted to find some more of the more transparently bullshit ones, but they had been removed by mods because they were transparently bullshit. Like I said, I’ve seen enough criticisms and had them turn out to be bullshit to reach my limit, there was one earlier today that I looked into a decent amount of detail, too.
