I installed it with a caddy proxy, works like a charm. I’ve used the Converse.js web client, Modal on iOS and Conversations for Android. The installation was quick and easy, file and photo sharing works, audio and video calls.
Really the hardest part is getting friends to use it.
While I like it conceptually, the two times I tried to install it I felt it was far too opinionated for me to get it to work correctly, like other software “bundles” of its kind that want to take control of the entire process of setting up ports, networking, storage, certificates etc…, instead of just hanging down from stuff that I have already prepared for it (like my own domain with my own cert).
Like, as a piece of software it’s something I’d absolutely use… if someone else sets everything up for me.
You can, but honestly no idea how to handle stuff like the certs from that point on. Most other software on docker lets me eg.: just bind-mount the host’s directory with the certs I want to use - or just not even know about SSL in the first place and just let me reverse-proxy the access in (like, say, a simple static page web server).
But, like I said, the last times I tried to get into it, it tried its darnest to get in my way. If that’s changed since then, that’d be great.
Hmmm maybe that’s the one that tries to do everything on its own instead of using the stuff I’ve already set up. Had similar issues with eg.: Nextcloud.
I’ve been looking for an alternative “the actual XMPP service only, nothing else that can be sourced by the host” container setup but there doesn’t seem to be any.
I know, bit Snikket still uses ports 80/443 for its web interface and group file sharing service. It even has a page for Reverse Proxy configuration, but it doesn’t include Traefik and the configuration is non-trivial
Tested Snikket self-hosting in the past. If I recall correctly one advantage was that it has the option for admins to create invite links for on-boarding new users which seems useful to me for “normies”.
It has a very opinionated default configuration and many of the relevant settings are hard-coded in the containers and thus are not easy to change permanently.
It’s probably possible to get working with ConverseJS, but I think it is better to wait for an officially supported web-client to be added to Snikket or alternatively configure your own XMPP server without the ready made Snikket containers.
This is good news in the sense that Snikket is forced to promote the better repository (F-Droid). It’s also favorable when some good apps like Snikket are simply unavailable in Google Playstore. If every app is available in Playstore, that solidifies Google’s disproportionate power – which they abuse. We need more apps to be only available outside of Playstore.
Snikket is also a good app to have that excludes Playstore because of its nature as a communications app. Advanced users likely tend to push their more novice correspondents to install Snikket. So going forward they will have to do their duty in spreading F-Droid.
This is strong evidence that Google just assumes that if you have the permission (and presumably network permission too) then of course you must be uploading the user’s contacts somewhere.
It sounds like there are a lot of other issues or potential bad faith with Google’s process.
But this is an entirely reasonable stance to take. Merely touching the permission should be the bar to having extremely strong requirements in place to verify that you’re not doing anything bad.
But this is an entirely reasonable stance to take.
Snikket is FOSS. The source code is available to Google. The source code is also a more trustworthy source of evidence than Google simply running the code. How do they know from running the code whether it exports their contacts?
What are you missing? When Google has access to the source code, they have the ultimate most effective and simultaneously easy way to verify the criteria is met. Of course that’s relevant to the discussion. It’s how you know what the software does. Only closed-source projects have a problem demonstrating that they’ve satisfied the criteria.
FOSS isn’t magic. Reviewing the source code doesn’t guarantee that the version you get matches the code you were provided. You unconditionally should not get any exemptions to store policy because your code is open source. That’s a terrible idea.
Having actual written policies and meeting other criteria are the rules for a reason. If you’re unwilling to follow them, not being on the play store is 100% your fault. It’s not Google being mean.
FOSS isn’t magic. Reviewing the source code doesn’t guarantee that the version you get matches the code you were provided. You unconditionally should not get any exemptions to store policy because your code is open source. That’s a terrible idea.
No one has suggested exemptions. Otherwise you need to quote where you get that idea from. You’re not grasping the fact that code enables criteria to be verified. It therefore needs no exemption.
The terrible idea we are grappling with is the idea to not review source code that is available. If the code does not match the binary, that is Google’s problem. Google is the repository and has the sole responsibility for either ensuring reproducable builds are in play (to the extent that they care) or compiling it themselves. But I doubt Google genuinely cares as the Playstore is proven to have a quite poor quality standard relative to other repositories.
Having actual written policies and meeting other criteria are the rules for a reason.
Those policies are not above criticism. If Google’s policies fail to include code reviews as verification that criteria is satisfied, that’s on Google and they have no expectation of not being condemned for their incompetent policy.
Yes, you are. The issue they’re complaining about is that they’re being held to additional standards because they ask for a sensitive permission. They absolutely should be.
Being FOSS should literally not be considered in any way at any point in the app acceptance process. It’s terrible policy that’s much worse than the policy that you’re complaining about.
The issue they’re complaining about is that they’re being held to additional standards because they ask for a sensitive permission.
That’s not Snikket’s complaint. Snikket naturally satisfies the standards at hand because they do not export address book data, so they have no reason to object to the standards Google is failing to verify. Their complaint is rightfully about Google’s incompetence in evaluating their compliance. It’s clear from Snikket’s account what a shit show it is at Google who failed copious times to evaluate their software.
There’s nothing more terrible in the position of a software repository than the incompetence of neglecting to review code as part of the acceptance process. I can’t think of a more foolish policy than to ignore the code of software for which you are trying to endorse the quality of.
B. Code review takes a very large amount of highly qualified man hours to not work.
Not if a machine does it. And even if they use humans, it takes even more man hours to do the alternative dynamic analysis and traffic analysis. Code review saves countless man hours even if done 100% manually by humans.
C. Requiring review of proprietary code exposes Google to a crazy amount of antitrust and IP liability. Again, to not work.
Not applicable to FOSS code.
Code review doesn’t happen because it’s a laughably stupid idea that has virtually no chance of being beneficial in any way. It’s not an oversight.
Code reviews happen at every organisation I have worked for to catch unwanted code before deployment and testing. The reason we review code before testing is because it’s cheaper to review code than to test it. It’s laughably stupid to think code review doesn’t work only to then to spend more money on verification tests.
An organization reviewing its own code is not the same, or similar in any way, to an organization reviewing a large volume of external code for malicious intent. And it doesn’t work for a wide variety of reasons (including the one I already gave you that binaries don’t provide you any guarantees that they’re from the source). Onboarding is universally slow because new people take weeks to months to actually meaningfully understand big projects.
Again, you’re asking for FOSS code to get some special treatment and bypass the requirements already in place. It’s completely absurd, because every single one of those tests would still be unconditionally mandatory to get any kind of actual confidence in security. Choosing to skip them because someone in India skimmed the code would be way past gross negligence.
An organization reviewing its own code is not the same, or similar in any way, to an organization reviewing a large volume of external code for malicious intent.
This is neither of those cases. This is trivially searching the code for where the address book API is called, and inspecting only the relevant code to that object for a specific usage. If you review the whole volume of code for the entire application, you’re doing it wrong. It’s trivial and for the reasons I’ve already explained, less effort than dynamic analysis and traffic analysis.
And it doesn’t work for a wide variety of reasons (including the one I already gave you that binaries don’t provide you any guarantees that they’re from the source).
And you apparently missed the response because you’ve neglected to address it. It was a defeated claim.
Onboarding is universally slow because new people take weeks to months to actually meaningfully understand big projects.
You’re thinking about hiring heads to work on code they need to understand in depth in order to edit the code. That’s not the case here. Code reviews are much cheaper than onboarding developers.
Again, you’re asking for FOSS code to get some special treatment and bypass the requirements already in place.
Again, no exemption has been requested. Google is either smart enough to make use of info at their disposal, or they are not. (answer: they are not).
It’s completely absurd, because every single one of those tests would still be unconditionally mandatory to get any kind of actual confidence in security.
Only if you do it wrong. A code review gives more confidence about what happens with the address book than testing. Only a fool would needlessly spend money on the more costly and redundant black box approach which yields results (guesswork!) with less confidence¹. Sure you can also do the black box analysis but that’s just wasting money when the bar has already been cleared. You would do both if lives depended on the code, but such standards are far above Google’s standards.
Choosing to skip them because someone in India skimmed the code would be way past gross negligence.
You’re still not getting it. No one advocates for an exemption. You need to get that out of your head. A code review is a way to more cheaply do the verification with higher confidence, not to bypass it.
¹ Hence why Google failed many times to get it right.
“Just searching the code where the address book API is used” most certainly does not give you increased confidence. Obfuscation is not that difficult. You can only possibly gain confidence if you fully understand every single line of code.
I ignored it because it’s idiotic. Google isn’t and shouldn’t be building code for you unless you pay for it.
Not doing literally every single test every other app is required to is an exemption.
One more time: a company having people review specific code for a specific purpose does not in any way resemble an adversarial code review against bad actors. There are no parallels. A code review gives you literally zero confidence that the writer isn’t malicious unless you comprehensively understand every single line. Open source project security is entirely and exclusively reputational.
“Just searching the code where the address book API is used” most certainly does not give you increased confidence.
That’s the starting point. It only takes 5 minutes to get there and find the object of interest. If you don’t spend 10-30 minutes more to see how the object is used, you’re doing it wrong. And if you try to read every single line of code in the project, you’re also doing it wrong.
Obfuscation is not that difficult.
Obfuscation is even easier to spot than to create, which on that basis alone would be good grounds to reject a package.
You can only possibly gain confidence if you fully understand every single line of code.
As I said, you need not read every single line of code. Just the code touching the address book.
I ignored it because it’s idiotic. Google isn’t and shouldn’t be building code for you unless you pay for it.
It’s looking more clear that English is not your first language. You continually fail to comprehend what I’ve said, which was the complete opposite of this comment, after you suggested yourself that a code review effort is that of a new hire onboarding effort.
One more time: a company having people review specific code for a specific purpose does not in any way resemble an adversarial code review against bad actors.
Again, that is not the purpose of the code review. If the purpose is to generally find malicious code, that’s a very different criteria than /not exporting an address book/. And if you move the goal posts to that mission, you have no fucking chance to do that with the simple black box analysis you’re advocating.
There are no parallels. A code review gives you literally zero confidence that the writer isn’t malicious
A code review is the absolute cheapest most effective way to find malicious code, if that’s your new goal. You will not find malicious code with any confidence by looking at a TLS traffic tunnel and playing with the app as a user. You can see that the app connects to the Snikket server and you can see that blobs are passed back and forth, which is expected anyway. From there, you have to guess from the timing and payload sizes that something is off, at which point you still really know fuck all. It’s a lot of effort to reach insufficient confidence to condemn the app.
unless you comprehensively understand every single line.
Clearly you’ve never written software. Malicious code does not affect every single line nor does finding malice need an understanding of every single line. Bugs would never be found on any large project if that were true. Every code review I’ve performed has been narrow in scope and yet I still find non-conformant code. A developer can work on a project for ~10-20 years of their life and still only see a small fraction of the code. Yet they still discover bugs in very little time. If you think you need to look at every single line, I suggest avoiding the software career path.
Open source project security is entirely and exclusively reputational.
Reputation matters whether a project is FOSS or not. But if it’s closed-source, reputation is all you have. Of course it’s nonsense to claim FOSS code cannot be reviewed by anyone who cares to step beyond reputation.
I feel like we maybe just learned some kind of lesson about malicious code being included in FOSS projects on blind faith that someone out there would catch it if it was there.
Ironically, Signal is about to move user IDs towards something unattached to telephone numbers and it had not been able to do so yet. Meanwhile, the slow moving XMPP has never made the wrong decision of using phone numbers because it was developed in an era when phones where a whole other thing than today’s pocket computers. Instead, XMPP accounts are federated like Lemmy or email…
There’s a beta you can try using a test branch app on their staging servers, you’ll need to make a new account with your number again and there has been issues where its leaked your number
I mean, XMPP did get uptake. Google Talk used federated XMPP at one point in time. But…there’s not much money for a service provider in an open, competitive market. If you can get enough users, you want to put up walls, leverage network effect. Then you get to have a monopoly on access to your users, and there’s more money to be had. So there’s always going to be people trying to get everyone into a single provider.
I think that with email, the magic factor was that there was no one entity large enough to pull that off at the time that email became common. Today, there are actually startlingly few email service providers of the “pay me a fee, I give you a couple mailboxes” variety – I was amazed when I went looking this year. I’m wondering whether email might become a walled garden before messaging stops being a walled garden.
That sounds roughly correct, though I don’t see the connection with the article? Unless you’re saying that “products” (like Signal) will always exist, which is probably true but is orthogonal to whether or not other models will succeed.
As for email, I think posteo does a pretty good job, but you’re right options are few and far between. But self hosting email is just as viable as ever? Perhaps less so since e.g. gmail will instantly flag your incoming mail as spam if you’re sending it from randomsite.tld, but honestly that issue hasn’t gotten that bad (yet). Yes, whenever there’s a protocol like email or xmpp, companies will create gmails and signals and turn them into walled gardens, but that doesn’t spoil the protocol for everyone else. It just causes frustration that companies build closed products on top of open technologies, but not much to be done about that.
That sounds roughly correct, though I don’t see the connection with the article?
It’s saying that XMPP didn’t take off. I’m saying that there was some uptake (well, of federated XMPP…that’s an important distinction, because a business running an in-house XMPP server that can’t talk to the outside world doesn’t really address the same issues), but that services shifted away from it because they didn’t want to have the kind of open ecosystem.
I think that that’s a problem for anyone trying to encourage adoption of an open ecosystem. I don’t care about XMPP as a protocol versus some other messaging protocol much, but I care a fair bit about the wdespread adoption of federated XMPP.
That is, IIRC it was Meta that talked about linking up to the Fediverse a while back. But…one would want to understand what their end game is. If it’s to do a Google Talk, to help bootstrap a new walled garden, that may be a problem.
I’m not accusing the author here of aiming to do that either, but it’d be a concern that would be in the back of my mind – if this service using this protocol becomes very popular, will the service seek to eliminate the open role of the protocol.
self hosting email is just as viable as ever?
I used to do that, but anti-spam mechanisms finally reached the point where I wasn’t willing to hassle with it – running your own mail server tends to trip a number of anti-spam mechanisms in various mail servers.
I don’t care about XMPP as a protocol versus some other messaging protocol much, but I care a fair bit about the wdespread adoption of federated XMPP
I don’t quite understand what this means, could you elaborate?
if this service using this protocol becomes very popular, will the service seek to eliminate the open role of the protocol
That is a valid concern, though the point of the article is to try and convince people why it won’t happen like it did with Google or might with Meta for structural reasons (rather than “oh but we’re different” reasons).
The main difference I see with Snikket vs Google Talk is that Snikket is not only libre client software, but libre server software as well. The point of Snikket is that individual people host it themselves, not that the Snikket devs run a bunch of Snikket servers which require their Snikket client for connection and just so happen to use xmpp to power it. Really all Snikket is (right now) is a prosody server with some pre-configurations and easy install, as well as an android/ios app which are general xmpp clients that are designed to work well when connected with Snikket servers.
Now it could still go south in a similar way to Google Talk, in that maybe a bunch of people start running Snikket servers and using Snikket clients, and then the Snikket devs start wall gardening the implementation. That would be bad, but the users (both server runners and client users) would be in a much stronger position to pivot away from those decisions.
I think it’s at least an interesting idea (hence why I posted it) for the reasons the author mentions: striking a balance between trustless freedom and interface stability/agility.
I don’t care about XMPP as a protocol versus some other messaging protocol much, but I care a fair bit about the wdespread adoption of federated XMPP
I don’t quite understand what this means, could you elaborate?
For me, what is interesting about XMPP is that – if federated – it permits for the kind of open environment that email has traditionally has. An open market, where one can choose a provider, and there aren’t walled gardens.
It’s not that I’ve sat down and reviewed the different messaging protocols and decided that there are fundamental, unfixable issues in other messaging protocols. That is, it’s not specifically XMPP that’s valuable, but the fact that XMPP (can be) deployed in a federated matter, like email.
You could hypothetically even add federation to other protocols, or gateway among them. Gatewaying is doable if various providers are willing. I’ve run bitlbee on my Linux system before; that’s a server that locally acts like an IRC server, permitting the use of IRC clients, but gateways messages to a number of other protocols and services; gatewaying writ small. From my standpoint, that’d also solve the problem, if all the messaging providers were willing to gateway to other systems. Early-on, when the walled email gardens opened up to Internet email – Compuserve, AOL, etc – they did gateway to the Internet.
And you can layer protocols on top of that, like OTR, to provide communication security.
I think that the problem isn’t “XMPP as a protocol” is interesting, because if there was one big messaging provider and it internally used non-federated XMPP, we wouldn’t really notice a difference.
And it doesn’t even, honestly, require use of a single, explicitliy-federated protocol. That’s useful for things like addressing handling routing – it creates a single convention, that username@xmpp-host is a way to reach a user. If you used gateways, you might have user@xmpp-host.external@traditionally-nonfederated-messaging-system. We had stuff like UUCP that did that some decades back, and you could build some sort of system for looking up a route to a user. Hell, I’m not even convinced that XMPP has that necessarily right – maybe it’d be better to be user@pubkey-signature, to permit for cross-host account portability. We could have ICQ and Matrix and Signal and SMS all co-existing with gateways, and that’d work okay from my standpoint.
Federated XMPP is designed to work like email, to have global interoperability, but even a shift to XMPP doesn’t guarantee that that happens – or that, over the long term, that’s where we wind up, even if we start there.
I don’t think that the issue is really one of protocol, but of interoperability. Moving to XMPP won’t (necessarily) solve it, though I wouldn’t be sad to see things move in that direction. And it’s a problem that can be solved without moving to XMPP; we could even do it with multiple messaging protocols.
I think that the issue is one of business incentives. If you have a good chance to be a walled garden, you don’t want a competitive market, because competition kills your ability to make money. If you are big enough, you can leverage network effect to gain an advantage – your users provide value to the network, and you control access the outside world can have to your users – and lock-in. You are disincentivized from decoupling from other services in that you want your users to have access to those other users, but as one provider becomes a relatively-larger share of the network, their incentive to leverage access to their userbase grows and the disincentive of cutting off the outside world decreases; they tend more towards trying to be the new walled garden.
That is, I think that the core problem is one of incentives surrounding interoperability among providers. As a user, I would like to have a competitive market. As a provider – at least one with a chance to be The One Walled Garden – I don’t want a competitive market. Interoperability makes for a competitive market; it tends to commoditize a provider’s service insofar as they can’t leverage access to their users any more.
That is a valid concern, though the point of the article is to try and convince people why it won’t happen like it did with Google or might with Meta for structural reasons (rather than “oh but we’re different” reasons).
I’m not really trying to beat up on Snikket here in particular. They may be just fine (or are today). I’m just trying to provide a broader take on the problem that the author is talking about – the walled garden versus open system problem.
A TTL of 64 supeficially suggests to me that the attack occurred on the server / in the hosting location. Network hardware is supposed to decrease it on every hop, is it not?
18 July 2023 issuing time is about the same when Hetzner server has lost network link for several seconds.
Seems to support a hypothesis that the attack occurred at the hosting location.
The attacker managed to issue multiple SSL/TLS certificates via Let’s Encrypt for jabber.ru and xmpp.ru domains since 18 Apr 2023
The Man-in-the-Middle attack for jabber.ru/xmpp.ru client XMPP traffic decryption confirmed to be in place since at least 21 July 2023 for up to 19 Oct 2023, possibly (not confirmed) since 18 Apr 2023, affected 100% of the connections to XMPP STARTTLS port 5222 (not 5223)
The attacker failed to reissue TLS certificate and MiTM proxy started to serve expired certificate on port 5222 for jabber.ru domain (Hetzner)
Too bad they didn’t discover how the forged certificate was obtained.
My guess, since those were .ru domains and that’s a hot topic: spooks from three letter agencies spooking around. Either Russian agencies trying to catch dissidents or other agencies trying to catch someone working for Russian agencies.
snikket.org
Hot