we think any amount of detail would make it very easy to come up with an exploit

People who would create exploits for this definitely can’t read the diffs and see what changed.

A little tweak to the max post length setting and you can do that with Mastodon too. I wish it was that way by default.

I did not know that it was possible to have root on GrapheneOS with a locked bootloader, but there have been ROMs with SU functionality built in, and adding their keys would be a straightforward way to have root and a locked bootloader.

There may be some other comments being unfair. People shouldn’t complain about free software someone else gives to them falling short of perfection, but we should be careful about granting random apps root permissions.

Having root is almost never a security benefit, it allows you to close one hole, but opens up 10 new more

I think it’s more like two:

• If an app granted root privileges is compromised, the damage it can cause is much greater
• The bootloader has to be unlocked for most approaches to gaining root; I consider it a design flaw that it isn’t easier for users to add signing keys and re-lock the bootloader

F-droid is not secure, some of the issues had been resolved, but it’s still not recommended for best practices

This is another very binary statement about security. The article addresses a number of design issues with F-Droid and concludes that most users are better off getting apps from Google Play. I don’t disagree with the design complaints in theory, but in practice it doesn’t hold up. I’ve seen people get malware from Google Play and read a number of documented cases. I have never heard of malware in the official F-Droid repository.

I’m reminded of comparing Windows to Linux 20 years ago. In theory, Windows had a more sophisticated permissions model and more reliable logging, making it potentially more secure. In practice, it took significant care to keep a Windows desktop clean, while Linux was very unlikely to be compromised.

Of course someone with high-value secrets on their device or who’s likely to be directly targeted by sophisticated threats should probably take a more conservative approach, install very few apps, and consider a hardened ROM like GrapheneOS.

I’m not complaining. I’m asking for some evidence this app is trustworthy.

Security is not binary. Having root can be bad for security, but it doesn’t have to be especially if you’re careful about what apps you grant root to, which is the point of my original comment. Having root can also be a security benefit because it offers more opportunities for detecting and blocking harmful and privacy-invasive apps, as this app does (if it’s trustworthy).

I don’t think F-Droid with the official repositories is a negative for security either; I suspect it’s less likely to contain outright malware than Google Play, and I’m sure the average app on F-Droid is less likely to be privacy-invasive. Adding random repositories suggested by strangers on the internet can be a different story, and asking who can vouch for the one suggested in this thread seems like a reasonable mitigation to me.

It’s reasonable for an app like this to need root, but also reasonable for everyone to ask for third-party verification of anything they’re granting administrative access to their devices.

Izzydroid’s security policy appears to be primarily based around automated scans that enumerate badness, and has far fewer users than the official F-Droid repository making it less likely that problems will be noticed, reported, and acted on.

Is there more reputation information about this app available?

This app wants root and despite being open source according to that link, isnt in the official F-Droid repo. I’m skeptical about trusting it.

Thanks for the explanation. Those do sound like significant issues for people at high risk for targeted harassment which wouldn’t be obvious to those of us fortunate enough not to have had that experience.

I understand the argument for servers blocking Threads/Meta. It doesn’t strike me as the right choice for every server, but it’s clearly a good choice for some servers. Threads doesn’t moderate the way many fediverse servers would like their peers to, and Meta is generally an ill-behaved company. Blocking it is appropriate for servers emphasizing protection for vulnerable users, and inappropriate for servers trying to be big and open. The fediverse is great because people can choose what’s right for them.

I do not, however understand the argument for blocking servers that do not block Threads and I think the article could be improved with a more thorough explanation. Maybe there’s something I’m missing about the mechanics at work here, but isn’t one’s own server blocking Threads enough to keep Threads users from being able to interact?

The ideal technical implementation is that when a client requests the post with an accept header of application/ld+json; profile="https://www.w3.org/ns/activitystreams", Wordpress sends the ActivityPub version of the post instead of HTML. It should have the same content as the items in the outbox. There may be limitations in the Wordpress plugin API that prevent this.

Another implementation allowed by the standard would be to have a different URL for the ActivityPub ID and put the post’s URL in the object’s URL property, or insert it in the content. Perhaps version 2 of the plugin will handle this better.

I’m not sure if any projects actually do automatic backfill, but they could and there does seem to be a desire to implement it.

This is your ActivityPub outbox (as JSON). The part it doesn’t seem to handle nicely is pasting an object ID/post URL into some other fediverse software to fetch the post manually, which is how someone would interact with an old post from a new follow on Mastodon.

I want to enable comments via ActivityPub (and only via ActivityPub) for a site I use Wordpress on, but I’m not sure I’m sufficiently motivated to try to debug the Friends plugin myself.

I’ve been largely disappointed with my attempts to use ActivityPub with Wordpress. I do revisit it every now and then.

Because of how federation works, you will not see any old posts. There is no mechanism for pulling up the history of posts and displaying them.

That’s not true. Reading the ActivityPub outbox is the way to do that. Mastodon doesn’t and I’m not entirely sure why (though I could probably find out).

I have also had poor results trying to use the Friends plugin with ActivityPub. Incoming replies result in high CPU usage for many seconds, and outgoing replies didn’t show up last time I tried it.

We, by which I mean some loose group of people who want decentralized tools to thrive should also be building things for secure, private communication, and we are. Matrix, for example offers strongly end-to-end encrypted federated chat rooms and private messages. It also has a kind of rough UX and, IIRC resource-intensive server software. We should work toward improving that.

I’m not advocating against privacy at all. I want people to understand as clearly as possible that Mastodon, Lemmy, and anything that works like them isn’t private and can’t be private when part of an open federated network so they can decide whether that’s a good fit for how they’re using it. The block evasion described in the link is just run a server on a domain that isn’t blocked, and I imagine any other mitigations bolted onto Mastodon that don’t break open federation will be little better.

What I think a lot of conversations about privacy and security on the Fediverse miss is that the Fediverse is radically public.

A protocol that sends everything you share to a long list of servers that haven’t been pre-screened and could be anything from a professionally-managed instance of vanilla Mastodon to an ad hoc, informally-specified, bug-ridden, slow implementation of half of ActivityPub running on a jailbroken smart light bulb can only ever be radically public. It’s possible to block most interactions with someone you don’t want to talk to, but not to reliably prevent them from seeing content you share to anything more than a short list of vetted followers.

There probably isn’t any reasonable way to change that while keeping the open federation model, though it’s possible to build closed networks on top of ActivityPub for those who want the formats it supports for a curated group. This isn’t a problem to be solved in my view, but an inherent reality: the Fediverse is for things you want to make public.

How would this be done? Like you mentioned, anyone can run a modified instance of Lemmy that does not honor delete requests.

Delete currently renders posts invisible to most users. Delete should actually delete the post from the server.

It’s impossible to ensure that the post is deleted from federated servers, web caches, clients that cache things, etc…

While I didn’t find any factual issues in a quick skim of that article, I really don’t agree with its tone.

The Fediverse is radically public. That’s the nature of a protocol like ActivityPub, not a bug to be fixed. Using it for anything you’re not comfortable with being public forever is a mistake.

It gets worse: everything you post to Lemmy is sent to multiple other servers automatically. Those servers may be in jurisdictions that have very different privacy laws than the server you post from, or that hosts the community you’re posting to. You have no legal agreement with those servers.

We’re not done though. The ActivityPub standard makes delete optional, and other servers could be running anything, not just Lemmy. Some of them are probably running somebody’s janky pet project that implements half of ActivityPub, poorly, on a jailbroken smart light bulb or something.

Lemmy should implement proper post deletion, possibly with a delay to allow moderators and admins to inspect deleted posts, but expect anything you share via ActivityPub to follow the once on the internet, always on the internet rule even more than in the past.

Fedibird, a Mastodon fork I’m surprised they’re counting separately.

There are lots of hypotheticals here.

I expect the lemmy.world admins to block servers that are frequent sources of hate and extremism. I don’t expect them to speculatively block servers because some people guess they might be. I’m pretty skeptical that a majority of users want preemptive blocking. I don’t, and the votes and comments I see in most conversations on the subject suggest that’s a position held by a very loud minority.

I’m not sure Threads users will be all that interested in interacting with Lemmy. It’s an awkward UX to participate in Lemmy conversations from Mastodon, and I believe Threads has essentially the same format. Threads is likely to have a bigger impact on Mastodon servers, and I don’t think any of us can reliably predict what that impact will be yet.

An account is required to post on Threads. It is not required to view content posted on Threads, which is different from Facebook and Instagram.

ActivityPub means that servers other than Threads will receive content from Threads which they can serve to visitors.