Follow

any objection to me merging the latest upstream changes?

The most disruptive changes are:
- an antispam feature (that you can disable)
- dropping support for OStatus and Atom feeds
- signing every fetch with an instance actor (you don't really have to care about it for now, it'll just use slightly more CPU but shouldn't change compatibility in any way)

(I'll probably merge that tomorrow if there's no objection)

Show thread

@Thib

Je ne comprends pas trop les conséquences d'abandonner Atom et Ostatus en fait...

@LienRag ben du coup tu pourra plus intéragir avec les trucs qui parlent que OStatus, et les outils qui dépendent des flux Atom vont plus fonctionner, c'est tout

@Thib

ça j'avais compris, c'est juste que je sais pas qui ne parle que Ostatus de nos jours (Diaspora* c'est ça?) ni quels sont les outils qui dépendent des flux Atom...

S'abonner à un compte par RSS c'est plutôt utile, ça peut se faire sans Atom?

@LienRag bah, des flux RSS, y en a toujours, c'est justement pas du Atom

Aucune idée pour Diaspora*. Y a GNU Social qui ne parle toujours pas ActivityPub, je crois que c'est à peu près tout.

Aucune idée des outils qui dépendent d'Atom.

@Thib

OK.
Y'a pas tant de monde que ça sur GNU Social mais c'est quand même dommage de se couper d'eux non?

@LienRag bah oui, mais bon, ça simplifie grandement le code de drop le support de ce dinosaure

Et on étais déjà coupé d'eux pour les pouets privés et messages directs, pour la participation aux sondages, etc.

@Thib I think I've made it pretty clear that I'm objecting? :X

@Thib I really think the "signing every request" stuff, once combined with "requiring every request be signed" is going to cause a huge problem, and is going to block off a more secure path

@Thib If Mastodon is going to go ahead with it, maybe I don't need to be trying to be pouring all my energy into gitlab.com/spritely/ocappub/bl because maybe the situation is hopeless :(

Once Mastodon requires this, it will pressure the entire network into taking this route. As I'm trying to lay out, it won't work in the long run anyway, and it *actively* blocks off another and better path.

@cwebber @Thib

no. we see the signing situation as a temporary mitigation. the plan is to replace it with OCAP later once it finishes cooking.

@kaniini @Thib Okay, I guess that's hopeful at least that that's the plan. I'm nervous about what the transition plan would look like.

I guess servers could suddenly "stop caring" about the signed requests, and stop mandating them. Still, it's going to be an awkward transition.

@cwebber @Thib

yeah it's not going to be an easy transition but nobody wants to burn CPU signing things if we can do better.

tech, salty, slightly shitpost 

@kaniini @cwebber well, about burning CPU, we're still using RoR

tech, salty, slightly shitpost 

@Thib @kaniini @cwebber Which is a great framework with an astounding set of pre-existing libraries to perform many common tasks, that enables individuals and small teams to create software that scarcely would have been possible at all if it didn't exist, and certainly not without significantly more expertise in a wide array of specializations. Can we please stop shitting on it like this because it's an easy target?

@cwebber also, while I currently can't see how using object capabilities would provide a better solution to the one we have in the code for the problem at hand (making it hard for identified bad actors from getting a hold on messages otherwise considered public and shareable), I have no doubt they can be useful for a host of other situations we may be interested in

And I believe I have already stated it, but I am very curious to see what you come up with exactly for this particular issue and for other ones as well

Your work is appreciated and not ignored

@Thib I appreciate the "work is not being ignored" comment.

Though FWIW, does the suggested request signing stuff actually in any way prevent bad actors get ahold of the stuff? It doesn't seem like it does to me, and is easily worked around: a newbie hacker with python, the requests library, and the beautifulsoup library could extract all that stuff.

It seems like we're giving users the illusion that their stuff is protected when it isn't.

@cwebber it prevents them from getting a hold on the AS representation. Of course they can scrape it. We could also ban the HTTP stuff though.

Anyway, we repeatedly brought that issue up, and it has always been met with the expectation that the machine-readable representation should be blocked if possible.

@Thib It only really is useful with whitelisting though, right? Here's a trivial workaround:

- Create a secret "slurper" instance. Nobody needs to know what this is. Nothing bad is posted from this instance.
- That one reads all the data.
- Secretly feed that to the sites that can't read it.

You're done! Workaround in-place. If you're only blocklisting, anyone can do this trivially.

If you go to a whitelist, see the re-centralization part from my paper.

@Thib And again, even without that, writing a scraper is only of minor annoyance. Probably enough metadata is exposed where the equivalent json-ld can be constructed without too much difficulty. I used to write these things (html scraper->structured data) for one of my first ever programming jobs, it was easy.

@Thib I guess it's already upstream in mastodon as you say, so maybe I misunderstood the PR. But I guess the network hasn't been "convinced" to move over to this as a "mitigation" yet.

I'm not convinced it's a mitigation... it seems to me like an extra mess with the illusion of security which is trivially broken.

@cwebber so my understanding is that you don't intend to address that particular issue (denying access to otherwise public toots) with ocaps?

@Thib I mean, we absolutely could address the issue of public-only-html but not-public-json-ld with ocaps, but I'm not sure if it's a real improvement. It seems like it actually won't protect users, and will give them the illusion of being protected?

@Thib I doubt that this will mitigate much once rolled out anyway; most users can just "right-click-view-in-[private-]tab" to see the content if they want to while not logged in anyway, right?

The quote from MarkM is apt here: "By leading users and programmers to make decisions under a false sense of security about what others can be prevented from doing, [we] seduce them into actions that compromise their own security."

Is that what we want to do?

@Thib In other words, instead of convincing users to take actions where they believe they are safe but they aren't, wouldn't it be better to encourage users to actually take actions where they really are safe?

And isn't doing the inverse, in many ways, putting our users at risk?

I think it is. It seems irresponsible to me to convince users they might be protected when they easily and blanketly aren't.

@Thib This is partly why I say I think this is a lot like when Mastodon rolled out "private messages" to OStatus that weren't private messages at all, and instead people who shouldn't have seen the messages started seeing them, and it caused a big ruckus. Sounds to me like this is that, volume 2.

It's *worse* to tell users they're having direct messages that don't resemble such at all. Similarly, it's *worse* to tell users that nazis can't see their public posts, when they easily can.

@cwebber this is the arguments we defended for a while. But there is value in making it harder for people to fetch the toots. And yes, whitelisting might also be worthwhile in some situations, and it would benefit from such mechanisms.

@cwebber more crucially, people already expect instance blocks to do that, and when they are told how it works, that's still how they request it to work.
You could say something like “if you do not want your messages to be passed between bad actors, make them private” but that's not how people want it to work, those are tradeoffs people are not willing to make.

@cwebber @Thib I've recently been writing AP stuff in Python, and I can confirm that writing a "slurper" instance would be trivial for anyone with minimal knowledge of the language.

Another factor to consider is that the kinds of adversaries which the fediverse has now are more sophisticated than a few years back.

@skarabrae @cwebber making a slurper instance requires a domain name. That's relatively cheap, but that's still one more step for the attacker.

(Obviously, a slurper instance might be kinda hard to detect, but we can try to single them out, e.g. by listing instances that have fetched stuff and have no known followers/followed people)

@skarabrae @cwebber making a slurper instance requires a domain name. That's relatively cheap, but that's still one more step for the attacker.

(Obviously, a slurper instance might be kinda hard to detect, but we can try to single them out, e.g. by listing instances that have fetched stuff and have no known followers/followed people)

@Thib @skarabrae Domain names are indeed cheap, and one slurper instance can feed many.

I guess this is moving forward, and I've warned enough, so we can see what happens on the other side. I am guessing it will cause a bunch of unhappiness while also not effectively blocking anything over the next few months, but we'll see.

@cwebber @skarabrae that doesn't mean we shouldn't also use ocaps, obviously

(and I'm trying to find something lighter than signing and verifying every fetch to achieve exactly the same purpose, and that is likely to resemble object capabilities a lot, so I'm interested in what you're coming up with anyway, to make sure it ends up being consistent)

@cwebber it's an extra step that not everyone attacker will take. And ocaps won't be any better for that.

@Thib Right, though I've been warning that the public stuff is really public for some time and that we shouldn't be giving the illusion that it isn't.

As for followers, it's at least possible to lock that stuff down so that it's *really* followers-only. Of course, that would mean that such links would suddenly stop being readable. But that at least seems more useful to do.

@cwebber followers-only toots are already really followers-only though?

@cwebber Mastodon has been signing some fetches since forever, and has known how to handle signed fetches since forever as well

The changes with that regard are:
- all requests are now signed by a specific actor
- there is a mode, undocumented and discouraged, to require signatures

Those changes are already upstream (but not in any release). This is about merging them (and other changes) in glitch-soc (which doesn't have releases).

I do not think having this code in would make migrating to an ocaps-based system any more difficult.

As I repeatedly stated wrt my involvement in both Mastodon and glitch-soc is that I'm very open to working on an ocaps-based solution when that turns out to be satisfying, and that I don't consider the sign fetches/require signatures to necessarily be the solution I am going for in the end. But that shouldn't stop us from making sure it could work.

@Thib merge it. Otherwise it will be just harder to merge stuff in the future

@Thib why no more atom feeds? (there were atom feeds?)

@bram there were atom feeds, but mainly meant for OStatus, since OStatus is based on them
The decision to remove atom feeds was mainly because there's RSS for user needs, and atom is mainly used for OStatus, with OStatus-specific stuff, and we don't want to keep them around to have half-broken compatibility with OStatus

@bram (I would have prefered clean user-facing Atom feeds, but I weren't the one to make the decision, and I'm not going to bother supporting a third format)

@Thib ah yeah, make sens, thx ❤️

(and thx again and again for your work ❤️)

Sign in to participate in the conversation
Mastodon (instance perso)

This is a small personal instance running on a couple small ARM servers at home.