There was an ffmpeg drag-and-drop GUI that let you create ffmpeg commands visually instead of having to remember all the right arguments. Inputs, filters and outputs are all nodes in a graph, and then you connect them together. When done you would export it as an ffmpeg command to run.
As an occasional user this was a lot easier to use than having to remember all of the commands, and it did it all without hiding the complexity from the user.
Unfortunately it looks like they tried to monetize it but then later shut down. It doesn't look like they posted the source code anywhere.
I recently went looking for that site since I got into tdarr, and I was sad to see it go. It definitely isn't great for "prod" use, but I find that a GUI listing options makes it easier to understand the thought process behind software.
Kills me that they didn't even bother open sourcing it.
At the very least they should have excluded any chats with disappearing messages enabled from being included in backups.
With disappearing messages off it was already reasonable to assume that a compromise of a counterparty's phone would result in exposure of all previous messages, so enabling backups wouldn't expose you to new risk.
That would cater to those who want to keep their chat history forever without exposing those with disappearing messages enabled to new risk.
They conclude that there's no wireless component to the feature.
This feature is not at all related to wireless activity. The law enforcement document's conclusion that the reboot is due to phones wirelessly communicating with each other is implausible. The older iPhones before iOS 18 likely rebooted due to another reason, such as a software bug.
If you think about it, if the attacker is sophisticated enough to break the phone within a 72 hour window, then they are definitely sophisticated enough to use a faraday container. So communication between phones wouldn't help very much.
Moreover, you'd have to have some inhibitory signal to prevent everybody's phones restarting in a crowded environment, but any such signal could be spoofed.
Browsers could add the less severe warning before the certificate expires, for example 3 days before it expires have a "this certificate is about to expire, are you sure you want to continue?" warning. That would maintain the security guarantees around expiration while still getting the attention of users/administrators.
Isn’t that what happens now when the cert expires? Except when it’s expired it’s a lot harder for users to figure out how to bypass the warnings so they can visit the site to find a contact link to report the issue.
Remember not every site is actively checked by their maintainer every day.
In an ideal world it shouldn’t be needed (and likewise UX for expired certs wouldn’t be needed), but in practice I think it has merit.
I learned about this when I encountered a server with an aggressive fail2ban that wouldn't let me log in because I had too many ssh keys. It apparently counted every wrong key as an auth attempt, so it blocked me before my ssh client tried the right key. Since then I've used
IdentitiesOnly=yes
