Registrations are back… Yes, this is the 2nd time now. The cause of registrations breaking this time was an issue with Prosody’s HTTP library not supporting SNI. I am unsure what changed or happened exactly as it was working fine on Debian 9. After the upgrade to Debian 10 it broke. Unfortunately the Prosody devs likely don’t have much time to work on the issue, so a generous contributor Nathaniel Suchy improved the default captcha. This is good because we no longer have to use Google’s captcha (privacy issue). Nathaniel obfuscated the captcha code to make it harder for bots to automatically solve. Thank you Nathaniel!
Nathaniel made numerous commits to the mod_register_web module code. Nathaniel also made some changes to our mod_register_web theme code.
Check out Nathaniel’s blog if you have time to spare!
Registrations are now back after a long period of being disabled. As you may have noticed, there was a large attack in which hundreds of thousands of accounts were registered in a couple days.
The abuser was able to bypass the terrible captcha that mod_web_register provides by default. It’s unfortunately easy to guess and as we saw, a person with enough dedication can make a script to spam register. As of now I’ve enabled Google’s recaptcha (begrudgingly) as a workaround for now. The public and private keys for that are injected via our prosody-secrets.sh script if you’re curious. The configuration on our GitHub did not need to be updated for this. We haven’t had much time to modify the Lua of the module, but plan to in the future with our git fork of the code github.com/cryptoworld-git/mod_register_web. If you’d like to contribute to that, we’d greatly appreciate it. If you have any questions don’t hesitate to contact!
Last night I performed maintenance to disable mod_mam archives by default (along with the few other things).
This means that messages are not archived by default on the server, and are only archived if your XMPP client specifies that they should be. The MAM module has one major flaw right now. It cannot purge archives fast enough. It seems to get stuck and it kept the messages for much longer than it was supposed to. Due to this, during the maintenance I have purged all MAM archives from the server. Security, privacy and transparency are all my number one priorities when it comes to the server. When I enabled MAM on the server I had to consider the benefits vs the trade-offs. I believe we’ll be better off with MAM disabled by default, because a lot of clients don’t even support it yet.
If you can have any questions, feel free to reach out!
I haven’t made a post in a while, so I figured I’d make one about what’s going on with XMPP.is. First of all, Happy New Year! 2018 has been a great year for the server and I’ve received $135 USD in donations via PayPal. Thank you to all the donors, you are what helps keep this server running. Thank you to the few who donated cryptocurrency as well! Since there hasn’t been many posts, here are some things I’ve accomplished last year…
- I made numerous improvements to the server’s configuration, adding support for many new XEPs and becoming 100% compliant according to this compliance tester. I’ve made several improvements to the server’s scripts and even added a few. You can see every change I’ve made on GitHub. Open source is the best 🙂
- I’ve updated a lot of pages on the site, adding more info and descriptions.
- I’ve tried to keep downtime to a bare-minimum. With the new hypervisor things have been more stable than ever. I’ve also improved on scheduling maintenance windows and giving notice beforehand.
Now onto 2019…
Recently I’ve been working on cleaning up registered users. We currently have over 37,000 registered users. Many years ago before I had web registrations and captchas in place, a nefarious individual/group registered over 35,000 accounts en-masse. A lot of the accounts follow a pattern (which I won’t disclose). I am working on cleaning up these users and deleting them, as they’ve never been used (as far as I know). This is a long and drawn out process as I have to make sure the accounts I’m deleting are not legitimate.
I’ve made a couple one-liner scripts in bash to find these accounts based on the pattern in their usernames that I’ve noticed. While it work 95% of the time, it also picks up legitimate users and I have to manually filter them out from the deletion lists. I’ve been going through the lists when I make them and taking out any users that look legitimate. As this is a manual process I might miss a few here and there… If your account gets deleted and you notice you can no longer login, please let me know. I can restore it from encrypted, off-site backups. Keep in mind that these usernames are very uncommon. They are probably taken from a word list and random numbers are added to them.
If you have any questions, feel free to reach out!
I’ve got the suggestion several times that we should ‘force the use of OTR!’ I don’t like the practice by other servers such as riseup.net (sends you warnings over and over) and calyxinstitute.org (specifies that they force it) for several reasons. Whether you can’t send messages if you don’t use OTR or get notices from the server every time you send a message without OTR, I believe it’s bad practice.
- It forces users into adhering to a specific plugin.
I feel like this is a bad idea. I believe the choice should be left up to the user like most things. If there are better alternatives than OTR already (OMEMO) or ones that come out in the future, it’s silly to force users to use something specific. It’s not built into every client by default like TLS is. And many users may want to use their own plugin that they develop, PGP or OMEMO.
Who wants to get spammed with messages from the server like, “you aren’t using OTR!!!!” or to just get their outgoing messages blocked simply because they don’t fit the OTR format? Being forced to use OTR, and when you don’t, getting punished via spam for it is annoying. Rather, users should be nudged to use end-to-end encryption through announcements or blog posts.
- OTR currently has some annoying downsides.
OTR, unlike OMEMO doesn’t seem to work well when you have multiple devices and doesn’t work with offline messages. Below is a great comparison of different plugins.