Thanks for the explanation. I’m considering Matrix but will hold off, at least until v1.11 or v1.12 solves the unintended CDN issue described in another comment here, cf https://matrix.org/blog/2024/06/20/matrix-v1.11-release/#continue-reading

Neat. I wish OpenSSH better support this use case. The instruction involve multiple moving parts on top of OpenSSH (s6-ipcserver, socat or custom scripts) and a number of extra options for the client. That probably adds overhead. It would probably be easier and more efficient if OpenSSH would directly support Unix sockets.

I’m interested into the technical details, not actual URLs. How come servers cited in the video keep hosting/seeding chatrooms despite closing corresponding accounts? Is this impossible due to Matrix’s design, or is it poor moderation from server admins?

About URLs: the author is absolutely right to blur these. The only people he should be sharing this is police, or maybe admins if they’re not aware of the abuse on their server.

That’s the first time I hear of Matrix having this issue.

I’m curious to know more, but the video only cite an anonymous source. Are there evidence or more technical details available regarding this?

Scams, identity thefts, manipulation through targeted ads (eg Cambridge Analytica), malware delivered via ads

This is a common issue in software, not limited to scripting. Software are getting more and more layers of wrappers/adapter code, like a Russian doll. It contributes to dependency hell, as each layer brings new dependencies.

Developers often find it easier to wrap existing apps and software, and add another layer on top, rather than improving or replacing what exists.

That’s the solution I picked at work. Refused to install that Microsoft software on my personal phone, but instead provided a phone number.

If you have a VoIP provider you could even try to the VoIP number for MFA instead of providing your real mobile number.

If IT make a comment about you not having the app, ask if they intend to provide a company device for that.

If the company cared, they would provide MFA hardware like Yubikeys to their employees.

Okay, I misinterpreted your comment.

Having a backup at a cloud provider is fine, as long as there is at least one other backup that isn’t with this provider.

Cloud provider seems to do a good job protecting against hardware failure, but can do poorly with arbitrary account bans, and sometimes have mishaps due to configuration problems.

Whereas a DIY backup solution is often more subject to hardware problems (disk failure, fire, flooding, theft, …), but there’s no risk of account problem.

A mix is fine to protect against different kind of issues.

That would indeed be a good backup strategy, but better be specific. “Offsite” may be interpreted in different ways.

They had backups at multiple locations, and lost data at multiple (Google Cloud) locations because of the account deletion.

They restored from backups stored at another provider. It may have been more devastating if they relied exclusively on google for backups. So having an “offsite backup” isn’t enough in some cases, that offsite location need to be at a different provider.

That’s a cute tiny predator

This reminds me of Glootie.

Glootie is a character that first appeared in Introducing: Glootie! […] He has DO NOT DEVELOP MY APP tattooed on his forehead.

Someone like Glootie once once asked me to develop his app. I expertly dodged the bullet by referring him to an organization that coordinates freelance developments. Someone explained to him that he’d need 1 or 2 developers plus a project manager, and probably told him typically hourly rate and number of hours for such projects. Never heard him again speak about the app.