• 5 Posts
  • 29 Comments
Joined 9 months ago
cake
Cake day: July 18th, 2024

help-circle

  • I mean, if I am more qualified at recognizing horseshit than The Guardian is, that’s a problem. It’s weird to me that you are classifying this view of how Trump operates with respect to things like tariffs and whether or not he is a total moron as a matter of opinion.

    I’ve seen them get other things about him wrong before, too. They were super happy about how Trump was finally going to lay the hammer down on the Israelis and create peace in Gaza:

    https://ponder.cat/post/1323549

    There were a bunch of Lemmy commentators in there, too, saying more or less that it was super easy, Trump had made progress with his tough negotiating, and this was just evidence that Biden hadn’t been trying to do it. Since that happened, Isarel’s occupied roughly half of Gaza and resumed killing at scale, and also starting doing the same a little bit in the West Bank. They’re also not letting any food in.


  • For example, think about the sheer amount of executive orders he has put out in his first few days of his second term. This must have been planned and prepared.

    Absolutely true.

    It was not just some random sh*t.

    Also true. They put together a detailed plan about it, it was published. Some of it was his own ideas but there was also a lot that was coordinated and coherent, put together by smarter people.

    You may be underestimating him a lot if you only think of “insane” etc. It was for a purpose.

    Now you’re switching back to talking about tariffs. Those were not for a purpose. He literally thinks (or thought, at one point, I don’t know if he still does) that the country doing the exporting pays the tariff. He put 50% tariffs on Lethoso. That’s not underestimating, that’s just facts.

    Other more coherent people have written about his motivations, the source of his tariff ideas, all kinds of stuff. You can do analysis of any of his ideas and the goals (if any) behind them without agreeing with any of it. But this article’s thesis is more or less “he’s trying to devalue the dollar to set right the balance of trade, and it might work” and that is a bunch of sanewashing and horseshit with some additional fantasies about how well Reagan’s stuff worked out thrown in for good measure.

    The world is much more than “pro or against trump”. They want diversity and they are doing well.

    You don’t need to have diversity between horseshit and non-horseshit. I’m fine with many many points of view, including pro-Trump ones if they make sense (one random example from recently being that he seems genuinely surprised and angry that Russia broke the cease-fire instantly). My complaint with this article is not that it’s pro-Trump, it’s that it is horseshit.


  • This is one of the weirdest goddamned articles I have ever read.

    The US dollar being devalued so people could accept our exports more readily would make some sense if we had manufacturing capacity to make some exports people will buy. We don’t. What will happen is we’ll lose the ability to buy everyone else’s stuff, and the history of where global capital chooses to site factories argues strongly against them moving them back to the US even with a cheaper dollar. It’s just suffering with no upside, short term or long term.

    Other insane things he says, like that defaulting on T-bills would be sort of a good thing or that Reagan’s people made “the economy” boom in the 1980s, are sort of side notes. And the idea that Trump is competently executing on plans that can be laid out coherently is also laughable. The whole thing is just insane in multiple overlapping respects. Why are they putting this in the newspaper? This is not the first totally insane pro-Trump story I have seen in The Guardian.



  • if you assume the network is badly behaved, fedi breaks down. it makes no sense to me that everything is taken for granted, except privacy.

    This is backwards in my opinion.

    What you described is exactly how it works. Everything in the network is potentially badly behaved. You need to put on rate limits, digital signatures for activities back to actors, blocks for particular instances, and so on, specifically because whenever you are talking with someone else on the network, they might be badly behaved.

    In general, it’s okay in practice to be a little bit loose with it. If you get some spam from a not-yet-blocked instance, or you send some server a message which it has a bug and it doesn’t deliver, then it is okay. But, if you’re sending a message which can compromise someone’s privacy if mishandled, then all of a sudden you have to care on a stricter level. Because it’s not harmless anymore if the server which is receiving the message is broken (or malicious).

    So yes, privacy is different. In practice it’s usually okay to just let users know that nothing they’re sending is really private. Email works that way, Lemmy DMs work that way, it’s okay. But if you start telling people their stuff is really private, and you’re still letting it interact with untrusted servers (which is all of them), you have to suddenly care on this whole other level and do all sorts of E2EE and verification stuff, or else you’re lying to your users. In my opinion.





  • Because it is transparently obvious that it’s going to happen.

    If you’re sending your users’ private statuses to an ActivityPub server, and just hoping that it’s going to choose to keep them private according to certain parameters even though that’s not what the spec stays it needs to do, then you’re fucking up. The fact that we know that particular instances of particular software are exposing them is a nice demonstration of the harm, a confirmation that you’re fucking up when you’re doing that, but it’s not really needed. It is the absolutely predictable result of some basic principles of security which, as a security researcher, you should absolutely be aware of.

    I’ve repeatedly explained this. You’ve repeatedly explained your position. We’ve both had our say. You seem addicted to the concept of “winning” the conversation and wanting to just go back and forth. In that case I would really encourage you to state your position again, and I can state mine again, and we can both have fun doing that for a while. Want to? It sounds like a productive use of both of our time. It’s fun, too.

    Edit: Actually, I didn’t even realize you are on fedia.io when I was typing this. You can test for yourself whether mbin does this, too, by coordinating with @Irelephant@lemm.ee. Follow his user, then have him post one of those private statuses, then fetch his user profile via fedia.io from an incognito window and see whether the private statuses show up. I have no idea whether they will, but if I had to guess, I would say it’s better than even odds.


  • Are you hoping to restart our disagreement through sheer passive-aggressiveness? Okay, sure.

    In my view, this is a Mastodon design flaw (or a user-expectation issue or whatever you want to call it.) I already said that, and you’re involved in the unproductive-arguer’s pastime of pretending not to understand that that’s my position, and just aggressively repeatedly reframing things according to your position and hoping I’ll knuckle under to it through sheer force of repetition.

    I’m not super invested in trying to track down each and every software that might manage to expose the “private” statuses in this way. I just know that as things come and go there are guaranteed to be some. If you have an mbin account and Mastodon account, though, we can try a little experiment. I don’t know the outcome, I’m just curious after taking a quick look down the FediDB list and a quick grep through mbin’s source code. You can be the one to responsibly disclose to mbin how their ActivityPub-conforming behavior is a problem, if indeed it turns out that it is, since you seem to be extremely committed to the idea that the model of “vulnerability” needs to be applied to this particular ActivityPub-conforming behavior. Since you’re a security researcher, having that as a CVE you discovered can be an achievement for you. It’s all yours, you can have it.


  • Hm… maybe. The exact nature of the problem in Pixelfed means that anyone with a Pixelfed account on a server which is getting private statuses can choose to follow someone who’s set to “approve followers” and then read all the private statuses. I do see how that’s significantly worse than just the normal lay-of-the-land of the problem, which is a little more random, and laying that out as a little roadmap to read someone else’s private statuses before there’s been a nice responsible length of time for things to get fixed could be seen as worsening the problem.

    The point that I’m making is that anyone who’s posting private statuses to Mastodon and expecting them to stay private is making a bad mistake already. The structure of the protocol is such that they can’t be assured of staying private regardless of what Pixelfed did or even if Pixelfed didn’t exist. They’re getting federated to servers whose behavior is not assured, in a way where a conformant ActivityPub implementation can expose them. People who are posting private statuses need to understand that.

    That whole blog post where the person is talking about her partner writing private statuses, and then the gut-wrenching realization that they were being exposed on Pixelfed… but then the resolution being “Pixelfed fucked up I hate Dansup now” and then continuing to post the private statuses, is wrong. That person’s partner needs to stop treating their private posts on Mastodon that way. The timer for responsible disclosure started circa 2017 or whenever Mastodon decided on how to implement their private statuses. It’s been and gone.

    Like I say, I get the harm-reduction aspect of saying it would have been better if Dansup was a little more discreet about this particularly bad attack vector until a few more days went by for everyone to upgrade. But it hardly matters. There are still server softwares our there that are going to be exposing people’s private Mastodon posts. It’s just how federation between untrusted servers works. Giving people the illusion that if Dan had just been more discreet then this harm would have been reduced is lulling them into a false sense of security, in my view.


  • Maybe I’m wrong, but shouldn’t posts only be insecure if they’re propagated to the insecure instance?

    “Insecure” in this case simply means any server that doesn’t implement Mastodon’s custom handling for “private” posts. With that definition, the answer to your question is yes. It has been mentioned by Mastodon people that this is a significant problem for the ability to actually keep these private posts private in the real world. The chance of it going wrong is small (depending on your follower count) but the potential for harm is very large. I would therefore go further, and say that it’s a very bad thing that Mastodon is telling people that these posts are “private” when the mechanism which is supposed to keep them private is so unreliable.

    https://marrus-sh.github.io/mastodon-info/everything-you-need-to-know-about-privacy-v1.3-020170427.html

    https://github.com/mastodon/mastodon/issues/712

    Is any private post visible to people on servers that the poster doesn’t have followers on?

    It is not. If you’re sufficiently careful with approving your followers, making sure that each of them is on an instance that’s going to handle private posts the way you expect, then you’re probably fine.

    Could I curl the uri of a post thats “private” and get the post’s content?

    If it’s been federated to an insecure server then yes. If not then I think no.



  • 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.




  • 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.


    1. This is nothing to do with ActivityPub. It’s to do with Mastodon’s custom implementation of “private” posts.
    2. 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.

  • Yeah, there’s also this:

    A more recent issue came about when Pixelfed’s creator, Daniel Supernault made the details of a vulnerability public before server operators had a chance to update, which would have left the fediverse vulnerable to bad actors, she says. (Supernault has already apologized publicly for his handling of the issue that had affected private accounts.)

    In the case of the Pixelfed issue, for instance, the Hachyderm Mastodon server, which has over 9,500 members, decided it needed to defederate (or disconnect from) other Pixelfed servers that hadn’t been updated in order to protect their users.

    It is weird to spend almost half the words in this, pretending that something in Pixelfed that wasn’t a problem on Pixelfed’s side was. This is the weirdest “vulnerability” in the world to pick if you want to pick one to hold up extensively as an example.