Thanks to these attacks I think creds got to all move to physical security keys so there’s nothing to (digitally) steal any more.This tool is a good idea for the short term.
IanTwenty
- 1 Post
- 5 Comments
- IanTwenty@piefed.socialtoOpensource@programming.dev•AntennaPod – The Open Podcast PlayerEnglish14·7 days ago
When Antennapod requests the episode the server can inject the ads and geolocate you based on your IP. Thus they can tailor them at the point of delivery to your region (and anything else they know/guess about your IP). Antennapod does not inject ads itself, it is at the mercy of what the podcast server returns.
- IanTwenty@piefed.socialtoSelfhosted@lemmy.world•Help with MonicaHQ notificationsEnglish1·10 days ago
I’m not familiar with Pikapods but Monica v4 has trouble with notifications. First you need to ensure it’s been configured right to even send a test email, this can be triggered with a command if you have access:
php artisan monica:test-emailVarious Monica environment variables must be set to configure this, it should be in the docs somewhere if not I can fish my config out for you.
Even once that’s working you’ll need Monica to run its regular jobs for sending notifications, there’s config for that too. Finally the code has bugs and will often miss reminders in my experience. There are some open bugs still on this and I guess the devs have moved onto their rewritten version (chandler):
- IanTwenty@piefed.socialtoSelfhosted@lemmy.world•Where did the dust settle on Syncthing Fork?English3·1 month ago
F-droid themselves gave an update in April:
https://f-droid.org/en/2026/04/03/twif.html
If you’ve been holding off updating Syncthing-Fork we have two pieces of news for you. First, the original dev continues to collaborate still, we know this was a pain point back then. Second, we’ve just added BasicSync, A simple app for running Syncthing, which just controls Syncthing’s running behaviour as hands off as possible, while the original service hums in the background.
So it seems since the handover things have settled but there is also a new fork which takes a more bare-bones approach.
I think the desktops need to better protect users’ secrets by accepting rogue user processes are part of the threat model now. There are lots of mechanism to lock known future user processes into a protected area (containers, chroot, etc), but none to lock existing and future unknown user processes out of a protected area.
Your idea of a yubikey access protected file area makes a lot of sense and I don’t think it exists yet. Then a user could throw their existing ssh keys in there and immediately get physical protection on them.
It would need to be carefully controlled. Something like gocryptfs on FUSE as you suggest but with a stronger threat model layered on top as theirs is short: https://nuetzlich.net/gocryptfs/threat_model/