You're very wrong, because account takeover can still happen due to a compromised email account. People can and do permanently lose access to their email account to a third party.
Having worked in security on a fairly high profile, highly visible, largely used product — one of the fundamental decisions that paid off very well was intentionally including mechanisms to prevent issues with other businesses (like Google) from impacting user abilities for us.
Not having email change functionality would have been a huge usability, security, and customer service nightmare for us.
Regardless of anything else, not enabling users to change their email address effectively binds them to business with a single organization. It also ignores the fact that people can and do change emails for entirely opaque reasons from the banal to the authentically emergent.
ATO attacks are a fig leaf for such concerns, because you, as an organization, always have the power to revert a change to contact information. You just need to establish a process. It takes some consideration and table topping, but it’s not rocket science for a competent team.
What logical fallacy, exactly? I think you're perhaps misunderstanding the conversation. This translates just fine to your proposed analogy.
In your analogy, the claim would be that some online account is tied to a laptop and whoever possesses the laptop has access to that account. The online service does not permit the account owner to revoke access from that laptop and move the account to a different laptop. I stand by my statement that this would be a serious security hazard. Because yes, laptops can and do get hacked or stolen, just like email addresses.
Where your analogy isn't quite as strong is that at least you can generally add additional anti-theft protections such as full-disk encryption to a laptop, while with an email account generally 2FA is the best you can do.
One of my favourite small features we added in the latest release is a 'prosodyctl check features' command which will validate that your configuration is up to date with current best practices in various ways.
Although we like to curate the default configuration with care, people tend to keep their existing configuration file when they upgrade (we generally recommend this, as we aim for backwards compatibility). The new command makes it easier for folk who upgrade to ensure they are still getting the expected experience as the recommendations evolve.
Obviously that has to be somewhat opinionated. One thing many people appreciate about Prosody is that you can customize it however you want to, even if it's not following the mainstream. E.g. if you really don't care about synchronizing to multiple devices, you can totally disable that message cache. Don't need audio/video calls? Fine!
I'm curious which aspect(s) became a time sink for you? I self-host a bunch of stuff myself. I can't say I never spend time on it, but it's measured in hours per year. Once stuff is set up, it just runs.
Also curious about the time sinks! Fingers crossed no issues with my services so far. The initial setup was tedious: configuring multiple services with their own configuration intricacies, and having proper backups. I am looking for something that would help reduce the setup toil, maybe something like nix?
Part of it is the fact that I'm using USB storage for my RAID, which is a little finicky. Another part is that I'm using this server as my router as well, which means that when things break I kind of have to fix them immediately, and since my network cards are thunderbolt I have to rely on the finicky Linux thunderbolt support.
For reasons not clear to me, if a system update requires compiling a large thing (e.g. Immich + TritonLLVM), 95% of the time it will break the internal LAN's network interface. I think updating is important (especially for a router), this means that a few times a week I have to babysit the system update to be there to reboot the server manually.
That's unusual that you struggled to build Lua. Lua is primarily C89, and used on non-POSIX microcontrollers for example. There are some optional bits of the standard library you would have to leave out - module loading uses dlopen(). This is done simply by defining the right feature macros for your target environment: https://www.lua.org/source/5.4/luaconf.h.html
I see these comments a lot from people who have very old deployments and didn't keep up with changing best practices. The users of these deployments also tend to be using out-of-date software such as Pidgin to access their account.
There is zero reason for long delays or lost messages in XMPP.
As an open-source XMPP project, we tried hard to find iOS developers willing to help with development (as volunteers, or even paid) and it's just so hard to find people in this intersection of interests.
If anyone reading this thread has iOS dev skills and cares about improving open-source messaging on iOS, feel free to get in touch.
The default ports are often blocked on such networks (public wifi, corporate firewalls, etc.), but also often open. 5222 is used by e.g. WhatsApp, 5223 is used by e.g. Apple push notifications. So it's not as bad as it could be.
But it's also totally possible to run XMPP over 443, and this is a feature of many popular XMPP deployments. If you're self-hosting, there are some guides for different deployment approaches here: https://wiki.xmpp.org/web/Tech_pages/XEP-0368
I left in 2019, but when I was there, WhatsApp used port 5222, but the client would try port 443 if port 5222 didn't work. After it had tried those enough, it would try on port 80 with HTTP wrappers.
Really, the right model for a public service is what AOL did for AIM. Listen on all the ports. Clients should try on the 'proper' port, then 443, then 80, then random permutation. Skip certain ports because nobody likes it if you probe on smtp, smb, or chargen (etc)
Yeah. I'd be surprised if Apple didn't use similar logic. XMPP can do multiple ports (a deployment can specify the recommended order in DNS). I've not heard of an all-ports deployment, but it does sound like an interesting experiment :)
Apple has a bit of an easier time, because they can (and do) lean on cellular carriers that restrict access to their push servers. And they have 17.0.0.0/8
But they say port 5223 and 2197 with fallback to 443 [1]. Google says 5228-5230 and 443, with a couple outliers [2].
ejabberd should work fine, it won't care. But you're right - whether apps will allow you to accept self-signed certificates can vary. Some are strict and don't allow bypass, others may just issue a warning prompt that you can dismiss. I haven't personally tried aTalk.
