From cc9deba6ebe2d93ebc57f1cfe57ad9950c107618 Mon Sep 17 00:00:00 2001 From: tmolitor-stud-tu Date: Thu, 15 Aug 2024 22:10:51 +0000 Subject: [PATCH] deploy: 3f66671899951b3c6ec5d18b2d5b7d588e8f86ac --- site/index.json | 2 +- site/index.xml | 20 ++++++++++---------- site/install/index.html | 2 +- site/supportedxeps/index.html | 2 +- 4 files changed, 13 insertions(+), 13 deletions(-) diff --git a/site/index.json b/site/index.json index 9421562..dde0142 100644 --- a/site/index.json +++ b/site/index.json @@ -1 +1 @@ -[{"content":"We are pleased to announce that we got selected in another funding round by the EU’s NGI via the NLnet Foundation NGI0 Entrust Fund to work on some important features in Monal.\nIn short this consists of the following tasks (in no special order).\nImplement Dialpad: Add Dialpad to our Call-UI and backend code to be able to send DTMF tones in A/V calls. This will make Monal fully compatible with jmp.chat, like Snikket is already. Rewrite Chat UI: Our current chat UI is still UIKit-based and it\u0026rsquo;s hard to improve it or fix some UI glitches. We want to rewrite and modernize the whole chat UI using SwiftUI. This will not only simplify maintenance a lot and allow us to fix these UI glitches, but also enable us to implement modern XMPP features like message reactions, message styling, message replies or mentions. UI work: Implement Message Reactions, Rich Replies and Stickers: Implement UI and backend for message reactions (XEP-0444), rich replies (XEP-0461) and Stickers, once the chat UI is ported to SwiftUI XSF work: After having successfully worked on the SASL2 XEP-suite, I want to modernize XEP-0389: Extensible In-Band Registration to also send only password hashes instead of cleartext passwords (similar to password upgrades specced in XEP-0480: SASL Upgrade Tasks) Write documentation of Monal internals: After having started to publish a blog series and wiki articles about Monal\u0026rsquo;s internals (beginning with the Handlers Framework), I want to publish blog and wiki articles on our XML query-language (intentionally based on the XPath-like syntax of Prosody\u0026rsquo;s query language), the PubSub/PEP framework, Model-Classes used as data sources for our UI (MLContact, MLMessage etc.) and possibly more. Thanks again to NLNet for fund this!\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00013-nlnet-funding2/","summary":"We are pleased to announce that we got selected in another funding round by the EU’s NGI via the NLnet Foundation NGI0 Entrust Fund to work on some important features in Monal.\nIn short this consists of the following tasks (in no special order).\nImplement Dialpad: Add Dialpad to our Call-UI and backend code to be able to send DTMF tones in A/V calls. This will make Monal fully compatible with jmp.","title":"New NLNet Funding"},{"content":"Our current development iPhone 8, which we bought in 2020, is getting on in years, is not able to run iOS 17 and the battery is broken.\nSo it\u0026rsquo;s that time again: we are launching a new fundraising campaign for 350 EUR to finance a new development iPhone capable of running iOS 17 and several upcoming iOS versions. Currently we are aiming for an iPhone 13.\nYou can view our donation options over here: Donate\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00012-funding-iphone13/","summary":"Our current development iPhone 8, which we bought in 2020, is getting on in years, is not able to run iOS 17 and the battery is broken.\nSo it\u0026rsquo;s that time again: we are launching a new fundraising campaign for 350 EUR to finance a new development iPhone capable of running iOS 17 and several upcoming iOS versions. Currently we are aiming for an iPhone 13.\nYou can view our donation options over here: Donate","title":"New fundraising campaign"},{"content":"Radically Open Security (ROS) kindly performed a security audit of some parts of Monal.\nSpecifically they audited the usage of our XML query language and the implementations of SASL2, SCRAM and SSDP.\nThe results in a nutshell: no security issues found, read the full report here: Monal IM penetration test report 2024 1.0 .\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00011-security-audit-1/","summary":"Radically Open Security (ROS) kindly performed a security audit of some parts of Monal.\nSpecifically they audited the usage of our XML query language and the implementations of SASL2, SCRAM and SSDP.\nThe results in a nutshell: no security issues found, read the full report here: Monal IM penetration test report 2024 1.0 .","title":"ROS Security Audit"},{"content":"Some may have predicted it, but now it happened: the chinese government banned Monal from the chinese appstore. Below is the complete email we got from Apple regarding this ban. We got that mail twice, once on Wed, 27 Mar 2024 15:46:18 +0100 and a second time on Thu, 28 Mar 2024 17:01:19 +0100.\nThe macOS version of Monal is still available in the appstore and with homebrew, though.\nHere is the full mail, a translation of the CAC articles can be found over here for reference.\nHello,\nWe are writing to notify you that your application, per demand from the CAC (Cyberspace Administration of China), will be removed from the China App Store because it includes content that is illegal in China, which is not in compliance with the App Review Guidelines:\nLegal Apps must comply with all legal requirements in any location where you make them available (if you’re not sure, check with a lawyer). We know this stuff is complicated, but it is your responsibility to understand and make sure your app conforms with all local laws, not just the guidelines below. And of course, apps that solicit, promote, or encourage criminal or clearly reckless behavior will be rejected. According to the CAC, your app violates Articles 3 of the Provisions on the Security Assessment of Internet-based Information Services with Attribute of Public Opinions or Capable of Social Mobilization (具有舆论属性或社会动员能力的互联网信息服务安全评估规定).\nIf you need additional information regarding this removal or the laws and requirements in China, we encourage you to reach out directly to the CAC (Cyberspace Administration of China).\nWhile your app has been removed from the China App Store, it is still available in the App Stores for the other territories you selected in App Store Connect. The TestFlight version of this app will also be unavailable for external and internal testing in China and all public TestFlight links will no longer be functional.\nBest regards,\nApp Review\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00010-ios-banned/","summary":"Some may have predicted it, but now it happened: the chinese government banned Monal from the chinese appstore. Below is the complete email we got from Apple regarding this ban. We got that mail twice, once on Wed, 27 Mar 2024 15:46:18 +0100 and a second time on Thu, 28 Mar 2024 17:01:19 +0100.\nThe macOS version of Monal is still available in the appstore and with homebrew, though.\nHere is the full mail, a translation of the CAC articles can be found over here for reference.","title":"iOS app banned from chinese appstore"},{"content":"It came to light that our publications previously linked in a section under About were not that discoverable. Now we moved the whole publications list to its own top level menu entry unter Publications.\nEnjoy watching the talk recordings and reading the slides and XEPs.\nAnd last but not least: Happy new year!\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00009-publications/","summary":"It came to light that our publications previously linked in a section under About were not that discoverable. Now we moved the whole publications list to its own top level menu entry unter Publications.\nEnjoy watching the talk recordings and reading the slides and XEPs.\nAnd last but not least: Happy new year!","title":"Publications moved"},{"content":"After several month of hard work we just released Monal 6.0. This version comes with new artwork by Ann-Sophie Zwahlen, support for Audio-Calls funded by the EU’s NGI Assure via the NLnet Foundation and many other improvements and bugfixes. The full list of changes can be seen below:\nNEW: Audio-call support (This feature will not be available to users in China and macOS users!)\nOther changes:\nNew Logo and new placeholder images by Ann-Sophie Zwahlen New \u0026ldquo;Add Contact\u0026rdquo; and \u0026ldquo;Contact Requests\u0026rdquo; UI Complete rewrite of OMEMO code Speed up app start Add support for SASL2 (XEP-0388) Implement XEP-0424: Message Retraction Add support for creating invitations (button only displayed if your server supports it, see https://docs.modernxmpp.org/client/invites/) Add timestamp when quoting older messages Always show a \u0026ldquo;Notes to self“ chat Overhaul implementation of last interaction display Show scroll-down button in groupchats OMEMO keys are copyable now (double tap) Add OSS based crash reporting (KSCrash), reports can be voluntarily sent via mail Fix logfile handling Add XEP-0215 (external services) to server details ui Only show contacts in contacts panel if they are in our roster Implement invitations using qr codes in addition of xmpp: uris Implement new image viewer compatible with iOS 17 Implement gif support in image viewer Bugfixes:\nMany bugfixes Fix bookmarks2 handling Fix XEP-0333 in private groups Fix url preview for sites not having oc: tags Set notifications to \u0026ldquo;mention only\u0026rdquo; when joining public channels Show per-resource last interaction timestamp in resource list Fix file uploading and sharing Fix timer when recording audio messages Fix muc avatar fetching ","permalink":"https://monal-im.github.io/monal-im.org/site/post/00008-monal-6.0-released/","summary":"After several month of hard work we just released Monal 6.0. This version comes with new artwork by Ann-Sophie Zwahlen, support for Audio-Calls funded by the EU’s NGI Assure via the NLnet Foundation and many other improvements and bugfixes. The full list of changes can be seen below:\nNEW: Audio-call support (This feature will not be available to users in China and macOS users!)\nOther changes:\nNew Logo and new placeholder images by Ann-Sophie Zwahlen New \u0026ldquo;Add Contact\u0026rdquo; and \u0026ldquo;Contact Requests\u0026rdquo; UI Complete rewrite of OMEMO code Speed up app start Add support for SASL2 (XEP-0388) Implement XEP-0424: Message Retraction Add support for creating invitations (button only displayed if your server supports it, see https://docs.","title":"Monal 6.0 released"},{"content":"In this new series, I want to shine some light onto specific parts of Monal\u0026rsquo;s internals. It\u0026rsquo;s dedicated to programmers or people curious about how Monal works internally. If you want to give some feedback, feel free to send an email to thilo@monal-im.org\nHandlers Handlers in Monal are something like serializable callbacks. In iOS the app can get frozen or even killed any time and the push implementation requires the complete app state to frequently transition between the Main App and the Notification Service App Extension (NSE). Using normal callbacks (called blocks in ObjC) is not possible because blocks are not serializable which means they could not survive an app kill or transition to / from the NSE.\nShort overview:\nSimple generalized concept usable throughout the app Leverages dynamic language features of ObjC \u0026ldquo;Serializable callbacks\u0026rdquo; to class / instance methods of ObjC classes Bind values (not vars) when creating a handler (e.g. to bind state to handler that can be serialized together with the handler) Bind vars when calling handler (overwriting creation-time bound values having the same name) Used in various places throughout the app like the IQ or PubSub framework (see Code examples found in the wild) Jump directly to list of supported data types Usage description with examples Define handler method This will be a static class method and doesn\u0026rsquo;t have to be declared in any interface to be usable. The argument number or order does not matter, feel free to reorder or even remove arguments you don\u0026rsquo;t need. Arguments declared with $$-prefix are mandatory and can not be removed, though. Arguments with $_-prefix are optional and can be removed. Primitive datatypes like BOOL, int, NSINTEGER (aka $$INTEGER) etc. can not be imported as optional and are always mandatory.\n$$class_handler(myHandlerName, $_ID(xmpp*, account), $$BOOL(success)) // your code comes here // variables defined/imported: account (optional), success (mandatory) $$ Instance handlers are instance methods instead of static methods. You need to specify on which instance these handlers should operate. The instance extraxtion statement (the second argument to $$instance_handler() can be everything that returns an objc object. For example: account.omemo or [account getInstanceToUse] or just account.\n$$instance_handler(myHandlerName, instanceToUse, $$ID(xmpp*, account), $$BOOL(success)) // your code comes here // \u0026#39;self\u0026#39; is now the instance of the class extracted by the instanceToUse statement. // instead of the class instance as it would be if $$class_handler() was used instead of $$instance_handler() // variables defined/imported: account, success (both mandatory) $$ Call defined handlers Calling a defined handler is simple, just create a handler object using $newHandler() and $call() it.\nMLHandler* h = $newHandler(ClassName, myHandlerName); $call(h); Bind variables when creating a handler You can bind variables to MLHandler objects when creating them and when invoking them. Variables supplied on invocation overwrite variables supplied when creating the handler if the names are equal. Variables bound to the handler when creating it have to conform to the NSCoding protocol to make the handler serializable.\nNSString* var1 = @\u0026#34;value\u0026#34;; MLHandler* h = $newHandler(ClassName, myHandlerName, $ID(var1), $BOOL(success, YES) })); xmpp* account = nil; $call(h, $ID(account), $ID(otherAccountVarWithSameValue, account)) Usable shortcuts to create MLHandler objects: $newHandler(ClassName, handlerName, boundArgs...) $newHandlerWithInvalidation(ClassName, handlerName, invalidationHandlerName, boundArgs...) Using invalidation handlers You can add an invalidation method to a handler when creating the MLHandler object (after invalidating a handler you can not call or invalidate it again!). Invalidation handlers can be instance handlers or static handlers, just like with \u0026ldquo;normal\u0026rdquo; handlers:\n// definition of normal handler method as instance_handler $$instance_handler(myHandlerName, [account getInstanceToUse], $_ID(xmpp*, account), $$BOOL(success)) // your code comes here // \u0026#39;self\u0026#39; is now the instance of the class extracted by [account getInstanceToUse] // instead of the class instance as it would be if $$class_handler() was used instead of $$instance_handler() $$ // definition of invalidation method $$class_handler(myInvalidationHandlerName, $$BOOL(done), $_ID(NSString*, var1)) // your code comes here // variables imported: var1, done // variables that could have been imported according to $newHandler and $call below: var1, success, done $$ MLHandler* h = $newHandlerWithInvalidation(ClassName, myHandlerName, myInvalidationHandlerName, $ID(var1, @\u0026#34;value\u0026#34;), $BOOL(success, YES) })); // call invalidation method with \u0026#34;done\u0026#34; argument set to YES $invalidate(h, $BOOL(done, YES)) Available data types The following datatypes can be bound to a handler defining them using the corresponding definitions having either the $$ or $_ prefix. If the single argument binding is used, the value is bound using the same name like the var the value is coming from (in this example: name).\ndefine: $$ID(NSObject*, name), $_ID(NSObject*, name), bind: $ID(name), $ID(name, value) define: $$HANDLER(name), $_HANDLER(name), bind: $HANDLER(name), $HANDLER(name, value) define: $$BOOL(name), bind: $BOOL(name), $BOOL(name, value) define: $$INT(name), bind: $INT(name), $INT(name, value) define: $$DOUBLE(name), bind: $DOUBLE(name), $DOUBLE(name, value) define: $$INTEGER(name), bind: $INTEGER(name), $INTEGER(name, value), this corresponds to the NSInteger type alias define: $$UINTEGER(name), bind: $UINTEGER(name), $UINTEGER(name, value), this corresponds to the NSUInteger type alias Code examples found in the wild Enabling carbons if([features containsObject:@\u0026#34;urn:xmpp:carbons:2\u0026#34;]) { DDLogInfo(@\u0026#34;got disco result with carbons ns\u0026#34;); if(!account.connectionProperties.usingCarbons2) { DDLogInfo(@\u0026#34;enabling carbons\u0026#34;); XMPPIQ* carbons = [[XMPPIQ alloc] initWithType:kiqSetType]; [carbons addChildNode:[[MLXMLNode alloc] initWithElement:@\u0026#34;enable\u0026#34; andNamespace:@\u0026#34;urn:xmpp:carbons:2\u0026#34;]]; [account sendIq:carbons withHandler:$newHandler(self, handleCarbonsEnabled)]; } } $$class_handler(handleCarbonsEnabled, $$ID(xmpp*, account), $$ID(XMPPIQ*, iqNode)) if([iqNode check:@\u0026#34;/\u0026lt;type=error\u0026gt;\u0026#34;]) { DDLogWarn(@\u0026#34;carbon enable iq returned error: %@\u0026#34;, [iqNode findFirst:@\u0026#34;error\u0026#34;]); [HelperTools postError:[NSString stringWithFormat:NSLocalizedString(@\u0026#34;Failed to enable carbons for account %@\u0026#34;, @\u0026#34;\u0026#34;), account.connectionProperties.identity.jid] withNode:iqNode andAccount:account andIsSevere:YES]; return; } account.connectionProperties.usingCarbons2 = YES; $$ Fetching OMEMO bundles NSString* bundleNode = [NSString stringWithFormat:@\u0026#34;eu.siacs.conversations.axolotl.bundles:%@\u0026#34;, deviceid]; [self.account.pubsub fetchNode:bundleNode from:jid withItemsList:nil andHandler:$newHandler(self, handleBundleFetchResult, $ID(rid, deviceid))]; $$instance_handler(handleBundleFetchResult, account.omemo, $$ID(xmpp*, account), $$ID(NSString*, jid), $$BOOL(success), $_ID(XMPPIQ*, errorIq), $_ID(NSString*, errorReason), $_ID((NSDictionary\u0026lt;NSString*, MLXMLNode*\u0026gt;*), data), $$ID(NSString*, rid)) if(!success) { if(errorIq) DDLogError(@\u0026#34;Could not fetch bundle from %@: rid: %@ - %@\u0026#34;, jid, rid, errorIq); else DDLogError(@\u0026#34;Could not fetch bundle from %@: rid: %@ - %@\u0026#34;, jid, rid, errorReason); } else { // check that a corresponding buddy exists -\u0026gt; prevent foreign key errors MLXMLNode* receivedKeys = [data objectForKey:@\u0026#34;current\u0026#34;]; if(!receivedKeys \u0026amp;\u0026amp; data.count == 1) { // some clients do not use \u0026lt;item id=\u0026#34;current\u0026#34;\u0026gt; receivedKeys = [[data allValues] firstObject]; } else if(!receivedKeys \u0026amp;\u0026amp; data.count \u0026gt; 1) { DDLogWarn(@\u0026#34;More than one bundle item found from %@ rid: %@\u0026#34;, jid, rid); } if(receivedKeys) { [self processOMEMOKeys:receivedKeys forJid:jid andRid:rid]; } } $$ ","permalink":"https://monal-im.github.io/monal-im.org/site/post/00007-monal-internals-handlers/","summary":"In this new series, I want to shine some light onto specific parts of Monal\u0026rsquo;s internals. It\u0026rsquo;s dedicated to programmers or people curious about how Monal works internally. If you want to give some feedback, feel free to send an email to thilo@monal-im.org\nHandlers Handlers in Monal are something like serializable callbacks. In iOS the app can get frozen or even killed any time and the push implementation requires the complete app state to frequently transition between the Main App and the Notification Service App Extension (NSE).","title":"Monal Internals - Handlers framework"},{"content":"Axel Reimer recently created some good video tutorials about Monal and XMPP in general.\nThese video tutorials can be found over here: https://www.eversten.net/videotutorials/.\nCurrently the audio of these videos is German only.\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00006-eversten-xmpp-videos/","summary":"Axel Reimer recently created some good video tutorials about Monal and XMPP in general.\nThese video tutorials can be found over here: https://www.eversten.net/videotutorials/.\nCurrently the audio of these videos is German only.","title":"XMPP Tutorials"},{"content":" Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies\nReleases Privacy Policy 6.0 and newer Privacy Policy Rev 003 5.2.0 up to 5.4.x Privacy Policy Rev 002 before 5.2.0 Privacy Policy Rev 001 Privacy Monal App ≥ 6.0.0 TLDR We never see your messages. We do not know who you are chatting with. We can not identify a user. We can see your XMPP domain and a Monal specific unique device id every time you receive a push message We see your IP addresses if you are on a call and your XMPP server does not provide a STUN or TURN server. We may see your contact\u0026rsquo;s IP address if you are using our TURN server. Structure The App Monal may interact with Monal servers to support Push messages or if you are establishing a call with a contact but your XMPP Server does neither provide a STUN nor a TURN server.\nOur privacy details are structured as follows. First, we would like to give you a short introduction how Monal is handling push messages to ensure a pleasant user experience. We will then briefly explain VoIP calls and its privacy implications. Afterwards we like to inform you how we are using crash and usage reports, logs and GDPR Subject Access Requests (SAR).\nPush App Resources are very limited on iOS and macOS. Monal for example can only run a limited time in the background after a user either locked the screen or switched the app. Hence, apps on iOS and macOS can not simply keep a connection to your XMPP server open 24/7 to inform you about new messages. To overcome these limitations your XMPP server can request our push server to send push messages to your device through Apple. With these push messages we can request Apple to wake up Monal on your device. Once it is woken up it has about 30 seconds to connect to your XMPP server, fetch all new messages and show a push notification for these new messages, if needed.\nHow push works Every time that Monal loggs in at your XMPP servers, it asks your server to inform our push server once you receive an XMPP message while Monal is closed/disconnected. To do this, we request a Monal specific push token from Apple and provide this token to your XMPP server. Using this Monal specific push token your XMPP server can instruct our push server to send push messages via Apples push system to wake up the app on your device.\nOnce push messages are enabled for your Monal instance on all your XMPP servers, your XMPP servers will open a encrypted server to server (s2s) connection to one of our push servers. Using this s2s connection your XMPP servers will then be able to talk to our push servers. To wake up your Monal instance your XMPP servers send us:\nYour unique Monal specific push token that was generated by Apple The domain of the XMPP server that you are using Push We never see your messages. We do not know who you are chatting with. We could only ever track what XMPP domains a push token is/was using. We can not identify a user. Push-Servers We currently provide the following independent push server regions:\nEurope Alpha (based in Europe, only used for debugging with higher log levels, not for production use) Note: Our previously used US push region was unfortunately shutdown due to fosshost ceasing operation.\nHow to change the push region Open Monal Open up the settings menu in the upper left corner (gearwheel) Open the Notifications menu Scroll down Select a region Push server regions If you are an XMPP server administrator, and you restricted s2s connections, please allow s2s to all our regions.\nRegion Hostname Notice Europe eu.prod.push.monal-im.org Push server locations Name Region Hoster Location Notice s1.eu.prod.push.monal-im.org Europe Hetzner Finland s2.eu.prod.push.monal-im.org Europe PHP-Friends Germany VoIP (STUN / TURN) With Monal 6.0 we introduced VoIP support. To establish the connection between you and the remote party (the remote contact) Monal utilizes STUN and TURN. In general STUN (Session Traversal Utilities for NAT) is used to allow a VoIP call even when you are behind firewalls.\nCalls established using only STUN will directly exchange packets (P2P) between you and your contact. Hence, your contact may see your IP address. If you do not want your contact to see your IP Address while being on a call, disable P2P connection in Monal\u0026rsquo;s privacy settings. Once disabled Monal tries to establish the call using a TURN (Traversal Using Relays around NAT) server.\nNote: Not all XMPP servers currently provide STUN and TURN servers. If your XMPP server does not provide STUN and TURN servers, Monal may use our fallback servers. These fallback servers provide both STUN and TURN. You can disable Monal to use these fallback turn servers. Please note, that we may disable our fallback STUN and TURN servers at any time, if too many users are using them.\nIf you use our fallback servers we will see:\nYour IP Addresses The IPs of your contact or the IPs of their TURN-Server The duration of the call We will not see the contents of that call, because these are E2E encrypted.\nCrash reports and app usage Monal does track crashes and usage data anonymously using the tools provided by Apple. This is opt-in only and controlled by iOS and macOS global settings. If a user decides not to send any data to developers, no crash logs are sent to Monal developers.\nLogs Your local device will contain a log file with all sent and received raw XMPP messages as well as debug logs. It does contain sensitive personal data! This file will never be transferred to us, except if you explicitly (manually) send it to us (e.g., via mail).\nGDPR Subject Access Requests (SAR) European GDPR allows users to request a copy of all data retained about them. Starting with Monal 5.2.0 we no longer see your JIDs (username@domain.tld) in our push servers. We therefore are not able to send you retained data related to your JID. We furthermore are unable to provide your retained data related to your unique push token because we have no way to verify that Apple issued you a provided token. If you have questions regarding GDPR, please send us a mail to info@monal-im.org.\n","permalink":"https://monal-im.github.io/monal-im.org/site/privacyarchive/monal_app_rev_003/","summary":"Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies","title":"Privacy Monal App ≥ 6.0.0"},{"content":"I recently wrote a summary about push on iOS in the xmpp.org wiki.\nSee over here for all the technical details and links to the documentation. I also talked about that topic in my talk \u0026ldquo;Modern XMPP - A story based on Monal\u0026rdquo; linked on the About page over here.\nFor convenience I\u0026rsquo;d like to summarize some parts of that wiki entry in this blog-post, too.\nUPDATE: This post describes the way Monal implements push as well as the pitfalls of implementing it in another way. I tried to make this clearer in the text now.\nBackground knowledge: Push on iOS On iOS there are several push modes having different properties. All modes, except VoiIP pushes, have in common, that they only provide 30 seconds of background time.\nVoIP pushes: MUST always make the device ring via Apple\u0026rsquo;s CallKit framework. You can\u0026rsquo;t use these pushes to silently retrieve messages or other XMPP stanzas in the background. Low priority pushes: These pushes don\u0026rsquo;t show any user-visible notification, but they can be dropped or arbitrarily delayed by Apple. They grant 30 seconds of background time. High priority pushes: These MUST show a user-visible notification. They grant 30 seconds of background time. But: Since iOS 13.3, apps having the com.apple.developer.usernotifications.filtering entitlement are allowed to suppress the user-visible notification. To cite Apple: This entitlement is intended for certain types of apps — such as messaging apps or location sharing apps — that use notification service extensions to receive push notifications without delivering notifications to the user.\nHigh priority pushes in combination with the com.apple.developer.usernotifications.filtering entitlement are not only used by Monal, but some other popular messaging apps, too (links to the source):\nWhatsApp Signal Threema Telegram (binary) Monal Monal is using this entitlement to wake up background processing without sending any message data through Apple\u0026rsquo;s servers (not even ecrypted data). When iOS grants the app it\u0026rsquo;s 30 seconds background time because of the incoming push, Monal then connects to the XMPP server over the network to retrieve the actual message and display a notification to the user, if needed.\nSignal does exactly the same: It uses push only to wake up the app and then fetches the messages using a dedicated network connection: Example in Signal\u0026rsquo;s code\nThis way Monal avoids all of the pitfalls depicted below!\nDiving deeper: Some more details about iOS push and XMPP The following explanations and thoughts are a bit more technical and require some understanding of the XMPP protocol and it\u0026rsquo;s inner workings.\nPush server implementations and iOS time limits Pushes of all types (see above) can only wake up the iOS app for 30 seconds. But in most cases that\u0026rsquo;s more than enough to connect to the xmpp server and retrieve pending stanzas (if using the entitlement mentioned above and XEP-0198, it is even possible to get pushes for iq stanzas etc., thus behaving like being permanently connected while still sleeping most of the time because of CSI). Even if the 30 seconds don\u0026rsquo;t suffice, the client can disconnect and both, Prosody and eJabberd, will send another push if there are still unacked stanzas in the XEP-0198 queue. This will give the app another 30 seconds. Even longer catchups lasting for \u0026gt; 5 minutes can be done completely in the background this way (observed in the wild with Monal stable).\nThis means that even with the 30 second time limit in place, it usually is possible to do a longer lasting catchup completely in the background, effectively extending the time limit to several minutes. This obviously only holds, if you use the com.apple.developer.usernotifications.filtering entitlement and connect directly to the xmpp server and is hardly possible if you try to transport stanzas through the push sent through Apple (see below).\nPitfalls: Transporting (encrypted) xmpp message stanzas through push (out of band) When using the iOS push infrastructure provided by apple for transporting (encrypted) stanzas out of band, multiple things have to be considered. First of all, pushes can get lost. That frequently happens if the device was in flight mode while the push was sent. Second, xmpp is a streaming protocol, strongly relying on the ordering of stanza (even inter-type ordering like the ordering of message and iq stanzas for mam). The order of message stanza matters for other XEPs, too (for example message retraction or last message correction). Using the iOS push service which is loosing pushes or even only sending pushes for a particular type of stanza (message stanzas having a body for example) breaks this ordering of events that every XEP implicitly relies upon. The payload sizes allowed for each push are also somewhat low (~4kb including some of the push metadata). OMEMO\u0026rsquo;s self-healing through key-transport-elements requires the client to send those key-transport message stanzas once a broken session gets detected. But using the push service for data transport is a one way channel only.\nLast but not least the UX can be really degraded if a user does not open the app for some hours (while still receiving push notifications). Once they open the app, a long mam catchup has to be waited for until the ui does reflect what the user already saw in notifications. If the device has no connectivity when the user opens it, they might even be really confused why those messages they alread saw a notification for are not displayed in the app at all). Writing incoming messages to the database to solve this will only make the ordering problem depicted above harder. The client not being able to execute the OMEMO self-healing stuff mentioned above will degrade UX further.\nNOT using the entitlement mentioned above will prevent the client from receiving push notifications for XEP-0333 read markers and remove already displayed notifications instead of posting a new one (because apps not having that entitlement are forced to show a notification for each incoming high priority push, even if the push was only for a XEP-0333 read marker). To be clear: without that entitlement neither message retraction nor XEP-0333 read markers can be implemented reliably!\nAnd if an app has the entitlement: why bother delivering some stanzas out of band and running into the ordering problem if the app could as well connect to the xmpp server in the background and retrieve all pending stanzas in the right order?\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00005-push-on-ios/","summary":"I recently wrote a summary about push on iOS in the xmpp.org wiki.\nSee over here for all the technical details and links to the documentation. I also talked about that topic in my talk \u0026ldquo;Modern XMPP - A story based on Monal\u0026rdquo; linked on the About page over here.\nFor convenience I\u0026rsquo;d like to summarize some parts of that wiki entry in this blog-post, too.\nUPDATE: This post describes the way Monal implements push as well as the pitfalls of implementing it in another way.","title":"Push on iOS"},{"content":"SASL (Simple Authentication and Security Layer) as used in XMPP is broken. In this blog post I\u0026rsquo;ll try to explain why and propose some fixes.\nUpdate (2023-04-21): Since I originally wrote this blog post, I\u0026rsquo;ve had the ability to discuss several of my ideas with Dave (the original author of XEP-0388 dubbed SASL2), MattJ (one of the authors of the prosody xmpp server) and others. Most, if not all, of my issues are now addressed in a bunch of updates to existing XEPs as well as new XEPs:\nUpdate of XEP-0388 (SASL2): https://xmpp.org/extensions/xep-0388.html New SASL2- and SCRAM-upgrade XEP: https://xmpp.org/extensions/xep-0480.html New XEP for downgrade protection when using SCRAM: https://xmpp.org/extensions/xep-0474.html Already existing XEP that only now gets adopted by server developers: XEP-0440 The rest of this blog post remains as is and can be used for a deeper introduction into the material and as explanation of some of the rationale behind the SASL2 updates and my ProtoXEP.\nA Modern Authentication Protocol In my opinion a modern authentication protocol should have at least the following properties. Of course that can be subject to debate, but I think most of us will agree on the following list.\nallow for protocol agility (e.g. adding new authentication mechanisms, like adding new cipher suites in TLS) prevent downgrade attacks on authentication mechanisms (we don\u0026rsquo;t want an active attacker to be able to force us to use a weak mechanism) prevent storage of plaintext passwords on the server (that\u0026rsquo;s obvious: we don\u0026rsquo;t want a hacker to be able to steal our plaintext passwords once he hacked the database) prevent replay attacks (we don\u0026rsquo;t want a MITM (man in the middle) be able to steal a (possibly hashed) password and use it to authenticate herself) (possibly) prevent/detect MITM altogether How SASL tries to fulfill these properties First of all: XMPP Core mandates the use of TLS for everything, including authentication. Keep that in mind, when reading the rest of this blog post.\nProperty 1 SASL as defined for XMPP allows the server to present a list of authentication methods. The client then picks the one having the highest perceived strength (see XMPP-Core 6.3.3) among the ones it implements. XEP-0438: Best practices for password hashing and storage lists some common authentication methods and how they should be ordered. Currently, the methods PLAIN (plaintext password), EXTERNAL (using client certificates to authenticate the user) and SCRAM (Salted Challenge Response Authentication Mechanism) are common.\n(I will not talk about SASL EXTERNAL in this blog post, because it does not use passwords and seems to be super uncommon in the XMPP world.)\nThis generally allows adding new mechanisms in the future, protocol agility seems to be fulfilled, right?\nProperty 3 Current mandatory SASL methods include SCRAM-SHA-1 and SCRAM-SHA-1-PLUS (if possible). SCRAM generally allows the server to store a salted hash instead of plaintext passwords.\nEven if the client uses the PLAIN method, the server could store the password as salted hash.\nAnd EXTERNAL usually does not use any form of password.\nSo that\u0026rsquo;s another property of our list that is fulfilled, right?\nProperty 4 Using SCRAM it is even possible to prevent replay attacks because of the used challenge-response scheme. That\u0026rsquo;s even possible if no TLS channel is used.\nCool, another property that\u0026rsquo;s fulfilled by SCRAM as well, right?\nProperty 5 SCRAM is even cooler because it allows for TLS channel-binding.\nThis allows both entities (client and server) taking part in the SCRAM authentication to bind the authentication to the TLS channel using a HMAC (Hash-Based Message Authentication Code) to sign a unique data blob tied to the TLS session in use.\nIf the TLS channel is intercepted by a MITM, the attacker would have to use two separate TLS channels, one to the server and one to the client.\nBinding the authentication to the TLS channel allows the server and client to detect such an attacker and fail the authentication.\nTo indicate, that a server supports channel-binding, it appends the string -PLUS to the advertised SCRAM methods.\nIf the client supports channel-binding, it picks SCRAM-SHA-1-PLUS instead of SCRAM-SHA-1.\nIn case the client supports channel-binding, but only received methods without channel-binding, the client uses the SCRAM method without -PLUS, but also indicates that it would have used the PLUS varriant if offered by the server (SCRAM Channel Binding).\nThis allows for the server to detect downgrade attacks and fail the authentication.\nBecause there are multiple different kinds of channel-binding to TLS possible, the client also specifies which binding it uses during the SCRAM flow (protocol agility).\nChannel binding prevents MITM altogether, right? Another property that\u0026rsquo;s fulfilled!\nWhat\u0026rsquo;s broken with SASL in XMPP Cautious readers will have noticed, that I left out property 2 (downgrade attack prevention) in my above explanation. That\u0026rsquo;s because SASL does not prevent downgrade attacks regarding the method negotiation at all. And that\u0026rsquo;s one of the main reasons why the whole SASL in XMPP stuff is so horribly broken.\nDowngrade of SASL methods The XMPP Core RFC even mentions downgrade attacks and suggests using TLS to mitigate them. But that\u0026rsquo;s not enough. If we assume the TLS channel to always be secure and MITM-free, we don\u0026rsquo;t even need SCRAM but could solely use PLAIN. The TLS channel already ensures no replay attacks can happen and storing the passwords securely using salted hashes on the server is still possible. We don\u0026rsquo;t need any channel-binding either, because that\u0026rsquo;s only needed if we assume someone has tampered with the TLS channel in the first place. In this scenario MITM-Prevention (property 5) is simply out of scope for SASL, because we assume TLS to always be MITM-free. That means our properties mentioned above are all fulfilled (property 5 by definition, the other ones by use of TLS) even if we abandon SCRAM and solely use PLAIN.\nIf we, on the other hand, don\u0026rsquo;t assume to always have a MITM-free TLS channel, then the above listed properties 2, 4 and 5 are all not fulfilled (that means: no downgrade prevention, no replay attack prevention and no MITM detection/prevention). The attacker could simply remove every advertised SASL method except PLAIN and thus get the plaintext password which is replayable and neither the server nor the client will detect this MITM. Supporting SCRAM in clients and servers does not help at all with this, because it simply will not be negotiated.\nWell, okay, but XEP-0438: Best practices for password hashing and storage (and some RFC I don\u0026rsquo;t remember) says, we should pin the last used SASL mechanism in the client to prevent downgrade attacks in further SASL sessions. That way the client won\u0026rsquo;t use SASL mechanisms having a perceived lower strength than the pinned one. Using a stronger one is still possible. That\u0026rsquo;s right, but it makes matters worse in regard to protocol agility while still not preventing the downgrade attack for the first connection of a client to the XMPP server.\nBroken protocol agility Protocol agility means we can specify new authentication methods later on and our client will always use the best one advertised by the server. That\u0026rsquo;s important because it allows us to gradually upgrade the security strength of our authentication while still maintaining backwards compatibility with older clients, eventually removing an old authentication method once most/all clients use a newer one (like replacing DIGEST-MD5 or CRAM-MD5 with SCRAM-SHA-XXX).\nSCRAM without PLUS variants Because of SCRAM fulfilling property 3 (preventing storage of plaintext passwords on the server), we can not upgrade the stored password hashes in the server\u0026rsquo;s database to a new SCRAM-based SASL mechanism. The obvious partial solution is to store new user\u0026rsquo;s passwords using the newer SCRAM algorithm and leave the old user\u0026rsquo;s passwords like they are. That way at least some of your users get to use the new SCRAM algorithm, slowly phasing out the old one eventually. An example would be a server that previously only supported SCRAM-SHA-1 now advertising support for SCRAM-SHA-256.\nOh, no! That doesn\u0026rsquo;t work either! The current specification of SASL in XMPP does send the list of supported SASL methods to the client before knowing which username the client wants to authenticate for. That means the server will always advertise SCRAM-SHA-256, even if the hash in the database is still SHA-1. If the client supports SCRAM-SHA-256 as well, it will happily pick that one and the server, only having the SHA-1 hash at hand, won\u0026rsquo;t be able to authenticate the user. The client on the other hand will have no way to detect why the authentication failed and switch to a percieved lower strength SASL algorithm (and even if that would be possible, it could possibly be used as a downgrade vector if done wrong).\nWell, method pinning to the rescue! We already talked about SASL method pinning. The client obviously knows which SASL method it used the last time it authenticated successfully and can always use just this method, no other, even if it implements some having a higher strength. That extends the pinning described in XEP-0438: Best practices for password hashing and storage to algorithms having a higher strength as well, something that, to my knowledge, isn\u0026rsquo;t specified anywhere. Additionally, that means we completely loose protocol agility after our first authentication. And newly offering SCRAM-SHA-256 on a server not storing plaintext passwords after it previously only advertised SCRAM-SHA-1 will likely still break authentication for all clients not doing this exact \u0026ldquo;always use the mechanism used on first auth\u0026rdquo; pinning.\nThe only way to advertise support for a new SCRAM hash algorithm and make clients use it is to upgrade your complete password database on the server by forcing a password reset upon all of your existing users. This must presumably be done out of band for XMPP. Clients implementing the strict pinning outlined above will have to reset the pinning once a new password gets entered by the user. If they don\u0026rsquo;t do so, this strict pinning to the old algorithm will still be in place and this client won\u0026rsquo;t be able to authenticate the user after the password reset.\nAnd I\u0026rsquo;ve not even started to talk about a user having two clients, one that only supports an old SCRAM algorithm (say SCRAM-SHA-1) and one that supports a new one (say SCRAM-SHA-256). The server obviously must store both hashes in its database to allow logins for both clients.\nSounds all pretty bad, right? How come, that hasn\u0026rsquo;t been discovered yet? Well, someone already identified these problems back in 2019. See this thread on the standards@xmpp.org mailinglist. But no attempt was made to fix them. Even the new XEP-0388: Extensible SASL Profile still uses the same protocol flow with no fix, albeit allowing for additional handshakes during the authorization phase like pipelining a bind request or resumption via XEP-0198: Stream Management onto the authorization.\nSidenote: One could solve this mess by sacrificing property 3 (not storing plaintext passwords on the server). If the plaintext password is stored on the server, every SCRAM algorithm can be used by the client. But do we really want that? At least that would allow the server to advertise new SCRAM algorithms without having to force a password reset.\nSCRAM with PLUS variants When looking at the channel-binding situation we already saw that the client specifies the type of channel-binding it wants to use. That allows for protocol agility, right?\nNo! The client does not have any way to detect which channel-binding type the server supports (appending -PLUS to the advertised SCRAM algorithm does not in any way specify which channel-binding to use). And if the client uses the wrong channel-binding the server does not support, the server will simply fail the authentication. The client will have no way to detect if the authentication failed because of the wrong channel-binding type used or if the actual password was wrong, like with using the \u0026ldquo;wrong\u0026rdquo; SASL algorithm above.\nThis renders the whole channel-binding protocol agility completely useless. And protocol agility is needed even for channel-binding!\nSome Solutions Well, that\u0026rsquo;s pretty bad news, right? But I don\u0026rsquo;t want to simply rant and leave the shard for someone else to collect, but propose fixes instead. And to my knowledge some of these problems are really fixable.\nIn this section I want to propose fixes to at least some of these problems. These fixes are open to debate and if we come up with even better solutions during this debate, that\u0026rsquo;d be great.\nRestoring protocol agility for channel-binding The server must not use -PLUS to indicate SCRAM algorithms with channel-binding, but use the name of the concrete channel-binding type as SCRAM algorithm suffix. That way the client will be able to determine if it supports that type of channel-binding and only select those SCRAM algorithms having a channel-binding it supports. The server is only allowed to advertise channel binding methods supported by the currently used channel (e.g. don\u0026rsquo;t advertise tls-unique on a TLS 1.3 channel, but only tls-exporter (if implemented)). Clients and servers may choose to still support the -PLUS SCRAM method names in addition to these new ones containing the concrete channel-binding type, but I don\u0026rsquo;t think that gets us anywhere.\nSome examples: SCRAM-SHA-1_TLS-UNIQUE or SCRAM-SHA-512_TLS-EXPORTER. That, of course, does not help at all, if channel-binding support can be rendered useless by a downgrade attack.\nPreventing downgrade of SASL methods Downgrades can be prevented by only allowing SASL EXTERNAL and SCRAM methods (or something similar to SCRAM that then mutual authenticates the whole protocol flow). The SCRAM client-final message must contain a client proof built using a HMAC not only covering the client-first-message-bare, server-first-message and client-final-message-without-proof, but also the (sorted) SASL method list. That allows the server to verify if the client used the correct list and this could not be manipulated, because it is ultimately signed with the client password, a MITM attacker can not know.\nWe can achieve this by adding an optional SCRAM attribute to client-first-message-bare which will be ignored by non-supporting servers, but secure the handshake against downgrades on supporting servers. This attribute (let\u0026rsquo;s name it d) will contain a base64-encoded hash of the sorted SASL method list as received by the client (using the same hash method as used in the whole SCRAM stuff). The server then checks if that hash matches the one it calculated itself by hashing the sorted SCRAM method list it advertised and fail the authentication, if these hashes don\u0026rsquo;t match.\nThe sorting can be done alphabetical in ascending order and the individual SASL methods be separated by \u0026lt; like done in XEP-0115: Entity Capabilities before the whole string is hashed.\nWe now have a working downgrade attack prevention that\u0026rsquo;s even backwards compatible with existing SCRAM methods and servers not supporting this new SCRAM attribute.\nRestoring protocol agility for SASL methods part #1 First of all, the server will have to store SCRAM hashes (or something similar for non-scram methods) for all methods it does support. If the server operator later decides to not offer a specific SASL method anymore, they can delete the (hash) data stored for that method from their server.\nSecond, the server can only advertise those methods it has hashes for in its database. That means it needs to know the username before advertising which methods it supports. This requires a change in the protocol flow for mechanism negotiation, which is not codified in the SASL RFC and can be changed via XEP. A good candidate would be XEP-0388: Extensible SASL Profile (also dubbed SASL2) which is not yet in Final state and thus can be adjusted to our needs.\nLet\u0026rsquo;s assume a SASL2 protocol flow by advertising support for this protocol, but not simultaneously advertising which SASL methods the server supports. The client would then first send the desired username it wants to authenticate for, and the server would respond with a list of supported SASL mechanisms for exactly this user. The username is of course not safe from a MITM attacker, but it will be included in the SCRAM authentication flow and the server will fail the authentication if that user differs from the one given earlier.\nAn example protocol flow using a modified SASL2 might look as follows (resembling more or less a normal SCRAM flow):\n\u0026lt;!-- Server sends stream features indicating support for SASL2. --\u0026gt; \u0026lt;stream:features\u0026gt; \u0026lt;authentication xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;/\u0026gt; \u0026lt;/stream:features\u0026gt; \u0026lt;!-- Client intiates authentication by sending the base64 encoded username it wishes to authenticate for. --\u0026gt; \u0026lt;request xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; \u0026lt;user\u0026gt;dXNlcg==\u0026lt;/user\u0026gt; \u0026lt;/request\u0026gt; \u0026lt;!-- Server sends the list of supported mechanisms for this user. The sorted list will be \u0026#39;SCRAM-SHA-1\u0026lt;SCRAM-SHA-1_TLS-EXPORTER\u0026lt;SCRAM-SHA-256\u0026lt;SCRAM-SHA-256_TLS-EXPORTER\u0026#39;, the corresponding base64 encoded SHA-1 hash (SHA-1 will be used because negotiated below) is: \u0026#39;U3vZANxXbl1pMOMBAFPnTb5YXWk=\u0026#39; --\u0026gt; \u0026lt;mechanisms xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; \u0026lt;mechanism\u0026gt;SCRAM-SHA-1\u0026lt;/mechanism\u0026gt; \u0026lt;mechanism\u0026gt;SCRAM-SHA-1_TLS-EXPORTER\u0026lt;/mechanism\u0026gt; \u0026lt;mechanism\u0026gt;SCRAM-SHA-256\u0026lt;/mechanism\u0026gt; \u0026lt;mechanism\u0026gt;SCRAM-SHA-256_TLS-EXPORTER\u0026lt;/mechanism\u0026gt; \u0026lt;/mechanisms\u0026gt; \u0026lt;!-- Client sends the selected mechanism alogside the initial-response data. --\u0026gt; \u0026lt;authenticate xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39; mechanism=\u0026#39;SCRAM-SHA-1_TLS-EXPORTER\u0026#39;\u0026gt; \u0026lt;!-- Base64 of: \u0026#39;p=tls-exporter,,n=user,r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6,d=U3vZANxXbl1pMOMBAFPnTb5YXWk=\u0026#39; --\u0026gt; \u0026lt;initial-response\u0026gt;cD10bHMtZXhwb3J0ZXIsLG49dXNlcixyPTEyQzRDRDVDLUUzOEUtNEE5OC04RjZELTE1QzM4RjUxQ0NDNixkPVUzdlpBTnhYYmwxcE1PTUJBRlBuVGI1WVhXaz0=\u0026lt;/initial-response\u0026gt; \u0026lt;/authenticate\u0026gt; \u0026lt;!-- SCRAM-SHA-1 challenge issued by the server. Base64 of: \u0026#39;r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6a09117a6-ac50-4f2f-93f1-93799c2bddf6,s=QSXCR+Q6sek8bf92,i=4096\u0026#39; --\u0026gt; \u0026lt;challenge xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; cj0xMkM0Q0Q1Qy1FMzhFLTRBOTgtOEY2RC0xNUMzOEY1MUNDQzZhMDkxMTdhNi1hYzUwLTRmMmYtOTNmMS05Mzc5OWMyYmRkZjYscz1RU1hDUitRNnNlazhiZjkyLGk9NDA5Ng== \u0026lt;/challenge\u0026gt; \u0026lt;!-- The client responds with the base64 encoded client-final-message (password: \u0026#39;pencil\u0026#39;). Base64 of: \u0026#39;c=cD10bHMtZXhwb3J0ZXIsLMcoQvOdBDePd4OswlmAWV3dg1a1Wh1tYPTBwVid10VU,r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6a09117a6-ac50-4f2f-93f1-93799c2bddf6,p=icrRuoQBB0htw5+K/6RNEDJ0Q4Y=\u0026#39; The c-attribute contains the GS2-header and channel-binding data blob (32 bytes). --\u0026gt; \u0026lt;response xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; Yz1jRDEwYkhNdFpYaHdiM0owWlhJc0xNY29Rdk9kQkRlUGQ0T3N3bG1BV1YzZGcxYTFXaDF0WVBUQndWaWQxMFZVLHI9MTJDNENENUMtRTM4RS00QTk4LThGNkQtMTVDMzhGNTFDQ0M2YTA5MTE3YTYtYWM1MC00ZjJmLTkzZjEtOTM3OTljMmJkZGY2LHA9aWNyUnVvUUJCMGh0dzUrSy82Uk5FREowUTRZPQ== \u0026lt;/response\u0026gt; \u0026lt;!-- This completes, so the Server sends a success containing the base64 encoded server signature. A SASL2 success always includes the authorization identifier. --\u0026gt; \u0026lt;success xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; \u0026lt;authorization-identifier\u0026gt;user@example.org\u0026lt;/authorization-identifier\u0026gt; \u0026lt;!-- Base64 of: \u0026#39;v=Ax+ZEP5hf90z8+KnakwspK9mEhk=\u0026#39; --\u0026gt; \u0026lt;additional-data\u0026gt; dj1BeCtaRVA1aGY5MHo4K0tuYWt3c3BLOW1FaGs9 \u0026lt;/additional-data\u0026gt; \u0026lt;/success\u0026gt; Restoring protocol agility for SASL methods part #2 Activating a new SASL (SCRAM) method and saving new hashes for these methods for already known users on the server is a bit trickier. To solve this, the server offers new SASL mechanisms indicating that he allows for hash upgrades, if he doesn\u0026rsquo;t have all required hashes in its database yet. The ordering of these new upgrade mechanisms should use a stable sorting algorithm. First sorting by perceived strength of the algorithm updated to, then by the percieved strength of the algorithm used for authentication (e.g. use the highest strength for authentication and upgrade to the highest strength possible with this authentication).\nFor reference, the SCRAM flow as stated in RFC 5802 section 3 is as follows, with HMAC() and HASH() corresponding to the hash method used to authenticate (e.g. SHA-256 for SCRAM-SHA-256):\nSaltedPassword := Hi(Normalize(password), salt, i) ClientKey := HMAC(SaltedPassword, \u0026#34;Client Key\u0026#34;) StoredKey := H(ClientKey) AuthMessage := client-first-message-bare + \u0026#34;,\u0026#34; + server-first-message + \u0026#34;,\u0026#34; + client-final-message-without-proof ClientSignature := HMAC(StoredKey, AuthMessage) ClientProof := ClientKey XOR ClientSignature ServerKey := HMAC(SaltedPassword, \u0026#34;Server Key\u0026#34;) ServerSignature := HMAC(ServerKey, AuthMessage) The SaltedPassword is the hash saved in the database on the server alongside the salt. Using additional SASL2 tasks we can now require the client to perform an additional task which consists of sending the SaltedPassword for the hash algorithm to upgrade to. The server just provides the required salt (that must be a new random value not equal to the one used for the old hash) and iteration count. By providing the salted hash after the successful completion of our SCRAM authentication, server and client can be sure to talk to the right one and when channel-binding is used, both can be sure no MITM is involved that could intercept the new SaltedPassword. I strongly suggest to only support password upgrades if channel-binding is used.\nAn example protocol flow using a modified SASL2 might look as follows (resembling more or less the SCRAM flow used in part #1 above and adding a second task for the desired hash upgrade):\n\u0026lt;!-- Server sends stream features indicating support for SASL2. --\u0026gt; \u0026lt;stream:features\u0026gt; \u0026lt;authentication xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;/\u0026gt; \u0026lt;/stream:features\u0026gt; \u0026lt;!-- Client intiates authentication by sending the base64 encoded username it wishes to authenticate for. --\u0026gt; \u0026lt;request xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; \u0026lt;user\u0026gt;dXNlcg==\u0026lt;/user\u0026gt; \u0026lt;/request\u0026gt; \u0026lt;!-- Server sends the list of supported mechanisms for this user. The sorted list will be \u0026#39;SCRAM-SHA-1_TLS-EXPORTER\u0026lt;SCRAM-SHA-256_TLS-EXPORTER\u0026lt;UPGRADE-SCRAM-SHA-256_SCRAM-SHA-1\u0026lt;UPGRADE-SCRAM-SHA-256_SCRAM-SHA-1_TLS-EXPORTER\u0026#39;, the corresponding base64 encoded SHA-1 hash (SHA-1 will be used because negotiated below) is: \u0026#39;nKFUXQ7h9IL3eo17pKygmacnEsk=\u0026#39; --\u0026gt; \u0026lt;mechanisms xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; \u0026lt;mechanism\u0026gt;SCRAM-SHA-1\u0026lt;/mechanism\u0026gt; \u0026lt;mechanism\u0026gt;SCRAM-SHA-1_TLS-EXPORTER\u0026lt;/mechanism\u0026gt; \u0026lt;mechanism\u0026gt;UPGRADE-SCRAM-SHA-256_SCRAM-SHA-1\u0026lt;/mechanism\u0026gt; \u0026lt;mechanism\u0026gt;UPGRADE-SCRAM-SHA-256_SCRAM-SHA-1_TLS-EXPORTER\u0026lt;/mechanism\u0026gt; \u0026lt;/mechanisms\u0026gt; \u0026lt;!-- Client sends the selected mechanism alogside the initial-response data. --\u0026gt; \u0026lt;authenticate xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39; mechanism=\u0026#39;SCRAM-SHA-1_TLS-EXPORTER\u0026#39;\u0026gt; \u0026lt;!-- Base64 of: \u0026#39;p=tls-exporter,,n=user,r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6,d=nKFUXQ7h9IL3eo17pKygmacnEsk=\u0026#39; --\u0026gt; \u0026lt;initial-response\u0026gt;cD10bHMtZXhwb3J0ZXIsLG49dXNlcixyPTEyQzRDRDVDLUUzOEUtNEE5OC04RjZELTE1QzM4RjUxQ0NDNixkPVUzdlpBTnhYYmwxcE1PTUJBRlBuVGI1WVhXaz0=\u0026lt;/initial-response\u0026gt; \u0026lt;/authenticate\u0026gt; \u0026lt;!-- SCRAM-SHA-1 challenge issued by the server. Base64 of: \u0026#39;r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6a09117a6-ac50-4f2f-93f1-93799c2bddf6,s=QSXCR+Q6sek8bf92,i=4096\u0026#39; --\u0026gt; \u0026lt;challenge xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; cj0xMkM0Q0Q1Qy1FMzhFLTRBOTgtOEY2RC0xNUMzOEY1MUNDQzZhMDkxMTdhNi1hYzUwLTRmMmYtOTNmMS05Mzc5OWMyYmRkZjYscz1RU1hDUitRNnNlazhiZjkyLGk9NDA5Ng== \u0026lt;/challenge\u0026gt; \u0026lt;!-- The client responds with the base64 encoded client-final-message (password: \u0026#39;pencil\u0026#39;). Base64 of: \u0026#39;c=cD10bHMtZXhwb3J0ZXIsLMcoQvOdBDePd4OswlmAWV3dg1a1Wh1tYPTBwVid10VU,r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6a09117a6-ac50-4f2f-93f1-93799c2bddf6,p=UApo7xo6Pa9J+Vaejfz/dG7BomU=\u0026#39; The c-attribute contains the GS2-header and channel-binding data blob (32 bytes). --\u0026gt; \u0026lt;response xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; Yz1jRDEwYkhNdFpYaHdiM0owWlhJc0xNY29Rdk9kQkRlUGQ0T3N3bG1BV1YzZGcxYTFXaDF0WVBUQndWaWQxMFZVLHI9MTJDNENENUMtRTM4RS00QTk4LThGNkQtMTVDMzhGNTFDQ0M2YTA5MTE3YTYtYWM1MC00ZjJmLTkzZjEtOTM3OTljMmJkZGY2LHA9VUFwbzd4bzZQYTlKK1ZhZWpmei9kRzdCb21VPQ== \u0026lt;/response\u0026gt; \u0026lt;!-- This completes, so the Server sends a continue containing the base64 encoded server signature and the upgrade task to perform. --\u0026gt; \u0026lt;continue xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; \u0026lt;authorization-identifier\u0026gt;user@example.org\u0026lt;/authorization-identifier\u0026gt; \u0026lt;!-- Base64 of: \u0026#39;msVHs/BzIOHDqXeVH7EmmDu9id8=\u0026#39; --\u0026gt; \u0026lt;additional-data\u0026gt; dj1tc1ZIcy9CeklPSERxWGVWSDdFbW1EdTlpZDg9 \u0026lt;/additional-data\u0026gt; \u0026lt;tasks\u0026gt; \u0026lt;task\u0026gt;UPGRADE-SCRAM-SHA-256\u0026lt;/task\u0026gt; \u0026lt;/tasks\u0026gt; \u0026lt;/continue\u0026gt; \u0026lt;!-- The client provides the SaltedPassword hash for SCRAM-SHA-256 --\u0026gt; \u0026lt;next xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39; task=\u0026#39;UPGRADE-SCRAM-SHA-256\u0026#39;/\u0026gt; \u0026lt;!-- The server sends the required salt and iteration count encoded as base64 encoded SASL attributes. Base64 of: \u0026#39;s=A_SXCRXQ6sek8bf_Z,i=4096\u0026#39; --\u0026gt; \u0026lt;challenge xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; cz1BX1NYQ1JYUTZzZWs4YmZfWixpPTQwOTY= \u0026lt;/challenge\u0026gt; \u0026lt;!-- The client responds with the base64 encoded SaltedPassword. --\u0026gt; \u0026lt;response xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; BzOnw3Pc5H4bOLlPZ/8JAy6wnTpH05aH21KW2+Xfpaw= \u0026lt;/response\u0026gt; \u0026lt;!-- Finally, the server sends a success after adding the salted SHA-256 hash to it\u0026#39;s database. A SASL2 success always includes the authorization identifier. --\u0026gt; \u0026lt;success xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; \u0026lt;authorization-identifier\u0026gt;user@example.org\u0026lt;/authorization-identifier\u0026gt; \u0026lt;/success\u0026gt; If the server needs to upgrade to multiple new SCRAM algorithms, he can do so one at a time on every new authentication. This is no \u0026ldquo;do everything once\u0026rdquo; anyways, because not every client might support every upgrade possible.\nConclusion To conclude this, we now identified several improvements to regain the properties listed in the beginning. These improvements can mainly be achieved by updating the SASL2 XEP (XEP-0388: Extensible SASL Profile). The downgrade prevention (the additional SCRAM attribute d) should possibly be published as RFC, but a XEP could suffice, too.\nFeel free to comment on anything in here. I\u0026rsquo;m always open to feedback and improvements. Just contact me at thilo@monal-im.org.\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00004-sasl/","summary":"SASL (Simple Authentication and Security Layer) as used in XMPP is broken. In this blog post I\u0026rsquo;ll try to explain why and propose some fixes.\nUpdate (2023-04-21): Since I originally wrote this blog post, I\u0026rsquo;ve had the ability to discuss several of my ideas with Dave (the original author of XEP-0388 dubbed SASL2), MattJ (one of the authors of the prosody xmpp server) and others. Most, if not all, of my issues are now addressed in a bunch of updates to existing XEPs as well as new XEPs:","title":"On the state of SASL in XMPP"},{"content":"We are pleased to announce that we got funding by the EU’s NGI Assure via the NLnet Foundation to work on some important features in Monal.\nIn short this consists of the following tasks (in no special order).\n1. Implement more privacy-friendly push server The current push appserver (https://github.com/tmolitor-stud-tu/mod_push_appserver) saves more data than strictly needed to perform its task, let’s change that. On top of that, a possible HA-setup and load balancing should be strived for.\n2. Implement basic Audio calls using WebRTC Include WebRTC library into our codebase and wire it up to allow for simple audio calls not involving XMPP (maybe send SDP data through a Monal specific non-standardized XMPP stanza to make this work without hardcoded ip and port).\nThis is to test Audio Calls in the field first before wiring them up using correct XMPP XEPs.\n3. Implement all XEPs needed for Audio Calls To make Audio Calls for XMPP work, we need proper XMPP integration. This wires up the stuff implemented in (2) into the XMPP layer by implementing the proper XEPs listed below. This will add support for 1:1 audio calls to Conversations, Dino and many more XMPP clients.\n4. Implement Video calls using WebRTC On top of the work done in (2) and (3) we want to implement Video Call support as well. This will add support for 1:1 video calls to Conversations, Dino, and more.\n5. Security quickscan We want a security quickscan performed by Radically Open Security and implement mitigations for problems found by them.\n6. Implement MUC UI management (add/remove/promote users etc.) While Monal supports MUCs (multi user chats) in its flavours “channel” and “group”, the app is still lacking proper support for creating and managing group-type MUCs. We will implement that missing piece in this task.\n7. Port addContact UI to SwiftUI The existing UI to add a contact or show pending contact requests is not user-friendly. We will therefore port it to SwiftUI. Once contacts can be added using the new UI, a UI for creating MUCs will be added. Monal will then support the creation of new private MUCs. Additionally, the existing functionality to scan contact QR-Codes and open contact links from other apps / iOS camera will be refactored. After the refactoring the user can preview the action and select an appropriate account before adding the contact.\n8. Add SASL mechanism upgrade capability to XEP-0388 XEP-0388 (“Extensible SASL Profile”) modernizes the old XMPP SASL profile defined in RFC 6120 and reduces round-trips. But neither the old SASL profile nor the new one (dubbed SASL2) solve the problem of SASL mechanism upgrades. A server that saves the hashed password for SCRAM-SHA-1 authentication has no way of upgrading to SCRAM-SHA-256. It does not know the cleartext password to calculate the hash to store itself and no way to ask the client for it. We want to take the opportunity and update the SASL2 XEP before it gets widely deployed to provide a way for a smooth upgrade path that allows the servers to store multiple hashes and get new hashes provided by clients that support the new algorithm without the need of ever knowing the cleartext password.\n9. Implement SASL2 in Monal (including SCRAM SHA1, SHA256 and SHA512) Implement the updated SASL2 XEP and the accompanying XEP-0440 (“SASL Channel-Binding Type Capability”) in Monal which serves as foundation for the implementation of XEP-0397 (“Instant Stream Resumption”).\n10. Write new XEP for downgrade protection of channel-binding types and SASL mechanisms and implement it A Man-In-The-Middle capable of impersonating the XMPP server on the TLS level can use SASL Mechanism Stripping and/or strip channel-binding types to downgrade the security. Adding an optional SCRAM attribute containing the hash of all server-advertised SASL mechanisms and channel-binding types as seen by the client will enable the server to check if any downgrade took place and to abort the authentication, if so. Because the SCRAM attribute will be part of the mutual authentication between client and server, a MITM will not be able to forge it.\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00003-nlnet-funding/","summary":"We are pleased to announce that we got funding by the EU’s NGI Assure via the NLnet Foundation to work on some important features in Monal.\nIn short this consists of the following tasks (in no special order).\n1. Implement more privacy-friendly push server The current push appserver (https://github.com/tmolitor-stud-tu/mod_push_appserver) saves more data than strictly needed to perform its task, let’s change that. On top of that, a possible HA-setup and load balancing should be strived for.","title":"NLNet Funding"},{"content":"We recently started to migrate the App from Anu Pokharel‘s Apple account to Thilo Molitor‘s Apple account.\nAs part of this transition we also deployed some new push servers to not let an old retired developer pay for the infrastructure needed for Monal.\nComing along with this transition from the old developer team to the new one is our new clean website at https://monal-im.org/. From now on, the old blog at https://monal.im/ will not be used for Monal anymore.\nMany thanks to all users, contributors and followers so far.\nSpecial thanks goes to Anu. Without him and his passion, Monal would not have been possible. He developed and maintained Monal for more than 10 years, always ensuring compatibility with the latest iOS releases.\nWhen I (Thilo) gradually took over development, I was able to build upon an app with a decent codebase rather than writing my own app from scratch. That made it possible to improve Monal further while already being used by thousands of people. I can not stress enough how thankful I was and still am for all the work Anu put into the development of Monal. Thank you, Anu, for your wonderful work towards a modern XMPP client for iOS and macOS!\nThilo, Friedrich, Anu\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00002-project-moved/","summary":"We recently started to migrate the App from Anu Pokharel‘s Apple account to Thilo Molitor‘s Apple account.\nAs part of this transition we also deployed some new push servers to not let an old retired developer pay for the infrastructure needed for Monal.\nComing along with this transition from the old developer team to the new one is our new clean website at https://monal-im.org/. From now on, the old blog at https://monal.","title":"Monal IM - project moved"},{"content":"Implemented XEPs XEP Status Since . . . . xep-0004 complete 4.9 xep-0030 complete 4.6 xep-0045 partial 5.0 xep-0048 complete 5.0 xep-0054 Implemented only for MUC profiles complete 5.0 xep-0059 complete 4.8 xep-0060 Used mainly for Pep partial 4.9 xep-0066 Used to mark XEP-0363 filetransfers only partial 4.9 xep-0077 partial 4.7 xep-0084 complete 4.9 xep-0085 Only typing notifications, use XEP-0319 to publish interactions partial 4.7 xep-0092 complete 5.0 xep-0115 complete 4.7 xep-0153 XEP-0153: vCard-Based Avatars (implemented only for MUC profiles) partial 5.0 xep-0162 partial 5.4 xep-0163 complete 4.9 xep-0167 complete 6.0 xep-0176 complete 6.0 xep-0172 complete 4.9 xep-0184 complete 4.7 xep-0191 complete 5.0 xep-0198 complete 4.6 xep-0199 complete 4.7 xep-0215 complete 6.0 xep-0223 XEP-0223: Persistent Storage of Private Data via PubSub complete 4.9 xep-0237 complete 4.6 xep-0245 complete 4.9 xep-0249 XEP-0249: Direct MUC Invitations complete 5.0 xep-0280 complete 4.5 xep-0286 complete 4.7 xep-0293 complete 6.0 xep-0294 complete 6.0 xep-0305 complete 5.1.1 xep-0308 complete 4.8 xep-0313 complete 4.8 xep-0319 complete 4.7 xep-0320 complete 6.0 xep-0333 complete 4.8 xep-0338 complete 6.0 xep-0339 complete 6.0 xep-0352 complete 4.7 xep-0353 complete 6.0 xep-0357 complete 4.8 xep-0359 complete 4.8 xep-0363 complete 4.9 xep-0368 complete 4.6 xep-0379 No automatic approval if server does not support subscription pre-approval; No checking of tokens, if server does not do so (XEP-0401) partial 4.9 xep-0380 complete 5.1 xep-0384 complete 4.8 xep-0388 complete 6.0 xep-0392 complete 5.1 xep-0398 Used for MUC avatars complete 6.0 xep-0401 complete 6.0 xep-0402 complete 5.4 xep-0410 complete 5.0 xep-0423 Check this XEP to see what\u0026#39;s missing partial xep-0424 complete 6.3 xep-0425 complete 6.3 xep-0440 complete 6.0 xep-0441 Only to automatically turn on archiving if possible (setting: always) complete 4.8 xep-0445 complete 5.2 xep-0454 No support for embedded thumbnails partial 5.0 xep-0474 complete 6.0 xep-0480 complete 6.0 xep-0486 complete 5.0 xep-0490 complete 6.3 Planned XEPs XEP Status https://xmpp.org/extensions/xep-0158 planned https://xmpp.org/extensions/xep-0374 planned https://xmpp.org/extensions/xep-0386 XEP-0386: Bind 2.0 planned https://xmpp.org/extensions/xep-0420 planned https://xmpp.org/extensions/xep-0158 planned ","permalink":"https://monal-im.github.io/monal-im.org/site/supportedxeps/","summary":"Implemented XEPs XEP Status Since . . . . xep-0004 complete 4.9 xep-0030 complete 4.6 xep-0045 partial 5.0 xep-0048 complete 5.0 xep-0054 Implemented only for MUC profiles complete 5.0 xep-0059 complete 4.8 xep-0060 Used mainly for Pep partial 4.9 xep-0066 Used to mark XEP-0363 filetransfers only partial 4.9 xep-0077 partial 4.7 xep-0084 complete 4.9 xep-0085 Only typing notifications, use XEP-0319 to publish interactions partial 4.7 xep-0092 complete 5.0 xep-0115 complete 4.","title":"Supported XEPs"},{"content":" Monal Support Channel (XMPP MUC): monal@chat.yax.im Github Tickets: https://github.com/monal-im/Monal/issues Email: info[at]monal[minus]im[dot]org. Donate Monal is developed by volunteers and community collaboration. The work which has been done is usually not paid, and the developers ask for donations to keep up service costs and development in the future! Please consider giving a little back for the hard work which has been conducted. Currently, there are three ways for financial support of the Monal development:\nDonate via GitHub Sponsors Donate via Libera Pay EU citizens can donate via SEPA, too. IBAN: DE66 5007 0371 0856 0419 01 Here you can read about further support of the development!\nFind general information in the Monal Wiki.\nTranslations We host and manage translations via Weblate. Feel free to translate Monal to your language!\nReporting a Vulnerability It is highly appreciated reporting a vulnerability to the Monal developers. We ask you for disclosure until it has been fixed. This prevents abuse and exploitation in the current published releases. Please report issues directly to info[at]monal[minus]im[dot]org.\nPlease try to report\nin detail what you are concerned about if applicable, how to reproduce your contact details, if the sending email is not enough. That way we can ask questions back to you. You are also invited to make a recommendation on how to fix a potential security vulnerability.\nOnce a vulnerability has been announced and indicated we try our very best to provide a fix as soon as possible, at its best within days. However, dependent on the potential issue it can take longer if many code sections need to be changed.\nPlease be reminded that this is a non-commercial software project.\nThank you for considering reporting a security vulnerability. This improves the quality of the app significantly.\n","permalink":"https://monal-im.github.io/monal-im.org/site/support/","summary":"Monal Support Channel (XMPP MUC): monal@chat.yax.im Github Tickets: https://github.com/monal-im/Monal/issues Email: info[at]monal[minus]im[dot]org. Donate Monal is developed by volunteers and community collaboration. The work which has been done is usually not paid, and the developers ask for donations to keep up service costs and development in the future! Please consider giving a little back for the hard work which has been conducted. Currently, there are three ways for financial support of the Monal development:","title":"Support"},{"content":" iOS macOS macOS (homebrew) Stable App Store App Store brew install --cask monal Beta Testflight Invitation Testflight Invitation brew install --cask monal@beta Alpha upon request to info@monal-im.org\nThen download from our alpha download site brew tap monal-im/homebrew-monal-alpha\nbrew install --cask monal-alpha Features Monal currently covers the following chat features:\nDecentralised and federated chat standard XMPP Private and group messaging Privacy-respecting push notifications Encrypted private and group chats (state-of-the-art encryption (OMEMO) Message history Free selection of your XMPP account provider Voice messaging Message archiving Upload of files, videos and images (HTTP Upload) Audio and Video calls Many settings and a design to offer privacy settings in the app to the need of the user A detailed and technical listing of your supported features (so called XMPP Extensions) can be found in our DOAP file. Planned features User-interface overhaul Implemented XEPs XEP Status Since . . . . xep-0004 complete 4.9 xep-0030 complete 4.6 xep-0045 partial 5.0 xep-0048 complete 5.0 xep-0054 Implemented only for MUC profiles complete 5.0 xep-0059 complete 4.8 xep-0060 Used mainly for Pep partial 4.9 xep-0066 Used to mark XEP-0363 filetransfers only partial 4.9 xep-0077 partial 4.7 xep-0084 complete 4.9 xep-0085 Only typing notifications, use XEP-0319 to publish interactions partial 4.7 xep-0092 complete 5.0 xep-0115 complete 4.7 xep-0153 XEP-0153: vCard-Based Avatars (implemented only for MUC profiles) partial 5.0 xep-0162 partial 5.4 xep-0163 complete 4.9 xep-0167 complete 6.0 xep-0176 complete 6.0 xep-0172 complete 4.9 xep-0184 complete 4.7 xep-0191 complete 5.0 xep-0198 complete 4.6 xep-0199 complete 4.7 xep-0215 complete 6.0 xep-0223 XEP-0223: Persistent Storage of Private Data via PubSub complete 4.9 xep-0237 complete 4.6 xep-0245 complete 4.9 xep-0249 XEP-0249: Direct MUC Invitations complete 5.0 xep-0280 complete 4.5 xep-0286 complete 4.7 xep-0293 complete 6.0 xep-0294 complete 6.0 xep-0305 complete 5.1.1 xep-0308 complete 4.8 xep-0313 complete 4.8 xep-0319 complete 4.7 xep-0320 complete 6.0 xep-0333 complete 4.8 xep-0338 complete 6.0 xep-0339 complete 6.0 xep-0352 complete 4.7 xep-0353 complete 6.0 xep-0357 complete 4.8 xep-0359 complete 4.8 xep-0363 complete 4.9 xep-0368 complete 4.6 xep-0379 No automatic approval if server does not support subscription pre-approval; No checking of tokens, if server does not do so (XEP-0401) partial 4.9 xep-0380 complete 5.1 xep-0384 complete 4.8 xep-0388 complete 6.0 xep-0392 complete 5.1 xep-0398 Used for MUC avatars complete 6.0 xep-0401 complete 6.0 xep-0402 complete 5.4 xep-0410 complete 5.0 xep-0423 Check this XEP to see what\u0026#39;s missing partial xep-0424 complete 6.3 xep-0425 complete 6.3 xep-0440 complete 6.0 xep-0441 Only to automatically turn on archiving if possible (setting: always) complete 4.8 xep-0445 complete 5.2 xep-0454 No support for embedded thumbnails partial 5.0 xep-0474 complete 6.0 xep-0480 complete 6.0 xep-0486 complete 5.0 xep-0490 complete 6.3 Planned XEPs XEP Status https://xmpp.org/extensions/xep-0158 planned https://xmpp.org/extensions/xep-0374 planned https://xmpp.org/extensions/xep-0386 XEP-0386: Bind 2.0 planned https://xmpp.org/extensions/xep-0420 planned https://xmpp.org/extensions/xep-0158 planned ","permalink":"https://monal-im.github.io/monal-im.org/site/install/","summary":"iOS macOS macOS (homebrew) Stable App Store App Store brew install --cask monal Beta Testflight Invitation Testflight Invitation brew install --cask monal@beta Alpha upon request to info@monal-im.org\nThen download from our alpha download site brew tap monal-im/homebrew-monal-alpha\nbrew install --cask monal-alpha Features Monal currently covers the following chat features:\nDecentralised and federated chat standard XMPP Private and group messaging Privacy-respecting push notifications Encrypted private and group chats (state-of-the-art encryption (OMEMO) Message history Free selection of your XMPP account provider Voice messaging Message archiving Upload of files, videos and images (HTTP Upload) Audio and Video calls Many settings and a design to offer privacy settings in the app to the need of the user A detailed and technical listing of your supported features (so called XMPP Extensions) can be found in our DOAP file.","title":"Install"},{"content":" Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies\nReleases Privacy Policy 6.0 and newer Privacy Policy Rev 003 5.2.0 up to 5.4.x Privacy Policy Rev 002 before 5.2.0 Privacy Policy Rev 001 ","permalink":"https://monal-im.github.io/monal-im.org/site/privacy/","summary":"Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies","title":"Privacy"},{"content":" Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies\nReleases Privacy Policy 6.0 and newer Privacy Policy Rev 003 5.2.0 up to 5.4.x Privacy Policy Rev 002 before 5.2.0 Privacy Policy Rev 001 Privacy Monal App \u0026lt; 5.2.0 Monal for iOS and macOS will register for APNS push notifications via a server to server (s2s) connection from your XMPP server to our push server. Your XMPP JID alongside with a push identifier and secret token from Apple, that is only valid for this app, will be saved and logged in the push-server logs. We do not intend to track you. All server logs are purged every two weeks. Our logs allow us to see the following details:\nYour JID (including your server’s hostname) Time when you register for push notifications Your apple push node and push token that was generated for Monal by Apple Time when your XMPP server triggered a push notification to your Monal device To fulfill its duty, our push server has to hold some information associated with an Apple push token, until Apple marks the token a deleted, which usually means you have uninstalled the app (Info: Apple confirms if a token is still valid on every push). In detail these information consists of:\nThe Apple push token The timestamp of the last push error The timestamp of the last successful push The timestamp of the registration of your device with Monal’s push-server The timestamp when the registration was renewed A random UUID identifying your device A random secret used by your XMPP server to authenticate a push Push server locations Name Hoster Location Notice ios13push.monal.im AWS US Provided by Anurodh Pokharel\nIPv4 only push.monal.im AWS US Provided by Anurodh Pokharel\nIPv4 only\niOS 12 only Crash reports and app usage Monal does track crashes and usage data anonymously using the tools provided by Apple. This is opt-in only and controlled by iOS and macOS global settings. If a user decides not to send any data to developers, no crash logs are sent to Monal developers.\nLogs Your local device will contain a log file with all sent and received raw XMPP messages as well as debug logs. It does contain sensitive personal data! This file will never be transferred to us, except if you explicitly (manually) send it to us (e.g. via mail).\nGDPR Subject Access Requests (SAR) European GDPR allows users to request a copy of all data retained about them. Please send GDPR requests to info@monal-im.org. As by GDPR we need to validate your JID before answering to your inquiry. Therefore, we will provide you a JID you must send a confirmation to, before we can answer your request and send you all retained data related to your JID.\n","permalink":"https://monal-im.github.io/monal-im.org/site/privacyarchive/monal_app_rev_001/","summary":"Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies","title":"Privacy Monal App \u003c 5.2.0"},{"content":" Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies\nReleases Privacy Policy 6.0 and newer Privacy Policy Rev 003 5.2.0 up to 5.4.x Privacy Policy Rev 002 before 5.2.0 Privacy Policy Rev 001 Privacy Monal App 5.2.0 - 5.4.x App Resources are very limited on iOS and macOS. Monal for example can only run a limited time in the background after a user either locked the screen or switched the app. Hence, apps can not simply keep a connection to your xmpp server open 24/7 to inform you about new messages. To overcome these limitations your XMPP-Server can can request our push server to send push messages to Apple. With these push messages we can request Apple to wake up the app on your phone. Once it is woken up it has about 30 seconds to connect to your XMPP server, fetch all new messages and show a push notification for these new messages.\nHow push works Every time that Monal logins at your XMPP servers, it requests your server to inform us once your received an XMPP message while Monal was closed. We therefore requests a Monal specific push token from Apple. Using this Monal specific push token our push server can send push messages via Apples push system to wake up the app on your device.\nOnce push messages are enabled for your Monal instance on your XMPP servers, your XMPP servers will open a encrypted server to server (s2s) connection to one of our push servers. Using this s2s connection your XMPP servers will then request our push servers to wake up Monal every time that new messages should be processed. To wake up your instance your XMPP servers send us:\nyour unique Monal specific push token that was generated by Apple the domain of the XMPP server that you are using. Push We never see your messages. We do not know who you are chatting with. We could only ever track what XMPP domains a push token is/was using. We can not identify a user. Push-Servers We provide two independent push server regions at the moment: Europe and US. By default, each device will choose our Europe based push region unless the device local is set to the US.\nHow to change the push region Open Monal Open up the settings menu in the upper left corner (gearwheel) Open the Notifications menu Scroll down Select a region Push server regions If you are an XMPP server administrator, and you restricted s2s connections, please allow s2s to all our regions.\nRegion Hostname Notice Europe eu.prod.push.monal-im.org US us.prod.push.monal-im.org Push server locations Name Region Hoster Location Notice s1.eu.prod.push.monal-im.org Europe Hetzner Finland s2.eu.prod.push.monal-im.org Europe PHP-Friends Germany s1.us.prod.push.monal-im.org US Fosshost US IPv4 only s2.us.prod.push.monal-im.org US Fosshost US Crash reports and app usage Monal does track crashes and usage data anonymously using the tools provided by Apple. This is opt-in only and controlled by iOS and macOS global settings. If a user decides not to send any data to developers, no crash logs are sent to Monal developers.\nLogs Your local device will contain a log file with all sent and received raw XMPP messages as well as debug logs. It does contain sensitive personal data! This file will never be transferred to us, except if you explicitly (manually) send it to us (e.g. via mail).\nGDPR Subject Access Requests (SAR) European GDPR allows users to request a copy of all data retained about them. Starting with Monal 5.2.0 we no longer see your JIDs (username@domain.tld) in our push servers. We therefore are not able to send you retained data related to your JID. We furthermore are unable to provide your retained data related to your unique push token because we have no way to verify that Apple issued you a provided token. If you have questions regarding GDPR, please send us a mail to info@monal-im.org.\n","permalink":"https://monal-im.github.io/monal-im.org/site/privacyarchive/monal_app_rev_002/","summary":"Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies","title":"Privacy Monal App 5.2.0 - 5.4.x"},{"content":" Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies\nReleases Privacy Policy 6.0 and newer Privacy Policy Rev 003 5.2.0 up to 5.4.x Privacy Policy Rev 002 before 5.2.0 Privacy Policy Rev 001 Website Privacy A user’s IP address will be logged in the HTTP server logs. All server logs are purged every two weeks and there isn’t any way for us to associate this information with any particular individual. Our websites do not use or need any cookies. And of course it doesn\u0026rsquo;t use any third party/external (JS-CSS-Font) dependencies.\n","permalink":"https://monal-im.github.io/monal-im.org/site/privacyarchive/monal_website/","summary":"Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies","title":"Privacy Website"},{"content":" TLDR:\nInfo: Monal will stop support for iOS 12, iOS 13 and macOS Catalina!\nWe are searching for a SwiftUI developer.\nWe need a new simplified website.\nWith better continuous funding, our push servers will move from the US to Europe.\nWe have a new support mail: info@monal-im.org\nTwo years ago we decided to rewrite the Monal app almost entirely and improve it gradually in the process, instead of creating another XMPP Client for iOS and macOS. We successfully managed to transform Monal from an app that had flaws and issues with many functions to a level that promotes a user-friendly experience with working features such as push notification, group chat, and partially end-to-end encryption support (OMEMO). If you are selecting an XMPP client for Apple systems we think that Monal is a great choice nowadays. We have been investing more than a thousand hours and worked hard to overcome all the flaws, the legacy app had. We invite you to give the recent beta a try!\nThe development of Monal has not yet finished though, and many more features are hopefully to come. But due to our time constraints, it sometimes takes a bit longer than we and the community would like. We are at most two developers at the moment using our spare time to maintain Monal and develop new features. As we are developing Monal in our spare time without decent funding, it is sometimes hard to prioritize specific features. Please give this circumstance some credits.\nWhat should Monal look like in the future? To give you a bit of insight knowledge of our plans we tried to summarize the most important tasks.\nInterface (SwiftUI) In the future Monal should be easy to use. Therefore, the interface requires a proper rework and while we are at it, it should be ported to SwiftUI. While we are still improving in designing with SwiftUI, we would be glad if there is a SwiftUI \u0026amp; Open Source enthusiast who would like to help us with this.\nWith this transition we would like to improve the accessibility of the app as well. If you like to support an open source project, and you would like to be part of our SwiftUI journey please contact us.\nTask:\nAdd new MUC creation and management UI Port the chat view Finish contact Details List group chat (MUC) participants Display OMEMO encryption fingerprints for verification Port our settings Port all other remaining views Qualifications:\nGeneral knowledge around SwiftUI (iOS and Catalyst) Interest in improving a (XMPP) chat client Optional, but preferred: Some experience with XMPP (e.g. some weeks, or maybe months of usage of Monal or any other “modern” XMPP client) Optional: Experience in designing inclusive / accessible UI Website We need a modern (simplified) Hugo based website that is easier to understand, similar to Conversations, Dino or Gajim.\nIf you have some spare time, and you are a skilled in creating websites with Hugo please contact us.\nRequirements:\nSimple design nothing too fancy Privacy by design → No analytics, no external CSS, jss, … usage OMEMO Encryption in Group Chat (MUC) We started to integrate OMEMO for group chats (MUC) into our alpha build. The receiving and sending sides are already implemented, but there are a few more steps until we can release it into the beta.\nSwitching to our new Domain monal-im.org In late 2021 we decided that we would like to have a domain with DNSSEC as our current top level domain does not support it. This domain will mainly be used for our push servers and mail servers in the future. From now on you will be able to reach us via info@monal-im.org.\nBuild server Thanks to ~20 generous donors, we were able to buy a new build server that will be used to build our alpha, beta and stable releases. Furthermore, Thilo is now finally able to debug code with a proper debugger connected to his phone.\nRedundant Push Servers We are currently using an AWS US instance for our push server that is not redundant and failed in 2021 more frequently than we liked it to. For that reason we started an internal project to auto-deploy our push server with Ansible and looked into ways for running a redundant push server setup. The first tests look promising so far, but a few more things need to be sorted out before we can switch over to our new setup.\nBefore we can switch to the new push server setup, we need a stable funding each month. We estimate that renting a VM in Germany and one at a different hoster in Finland would cost us between 16€ to 32€ each month. Without a stable funding we might not be able to afford this new setup and our push servers would stay in the US.\nThanks to our generous build server donors, we have a few bucks left that will be used as a ~5 month buffer in case of fluctuant push server funding\nPrivacy improved push servers With our current push implementation our so-called “app servers” see your JID (username + server), a unique but otherwise opaque device id and an opaque token generated by apple, as well as your interaction times (when you register for push notifications, timestamps when your XMPP server triggers a push notification device).\nIf you use multiple accounts on one device, the unique device id is shared across all accounts. We don’t think that this is ideal, as we know all jid’s a user is using.\nIn the future we want to try to reduce our knowledge by hiding your username from our app servers. If our idea works, we would only see that a device is registered on one or more domains and the timestamps that a push message was triggered from each domain that is used.\nAudio and Video Calls Many clients such as Conversations and Dino support audio and video calls, so Monal should be next 🙂\nEnd-of-life: iOS 12, iOS 13 and macOS Catalina will not be supported anymore Our user group on iOS 12, iOS 13 as well as macOS Catalina has decreased in last years while the resources needed to maintain these old platforms increased. We therefore decided to focus on newer iOS versions and drop the old ones. The next stable release will only be supported on iOS 14 and higher and macOS Big Sur and higher. We are still unsure how long we will support iOS 14, as most of the devices also support iOS15.\nDonations and Support Monal is developed by volunteers and community collaboration. The work which has been done is usually not paid, and the developers need to keep up service costs and development in the future! Please consider giving a bit back for the hard work which has been conducted. Currently, there are three ways to financially support the Monal development:\nDonate via GitHub Sponsors Donate via Libera Pay EU citizens can donate via SEPA, too. Just contact Thilo Molitor via mail to info@monal-im.org to get his IBAN. Here you can read about further support of the development! Find general information in the Monal Wiki.\nTranslations We host and manage translations via Weblate.\nMany thanks! Of course, thank you very much to everyone who supported us in the past two years! 🙂\nYou can follow us via Mastodon.\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00001-monal-development/","summary":"TLDR:\nInfo: Monal will stop support for iOS 12, iOS 13 and macOS Catalina!\nWe are searching for a SwiftUI developer.\nWe need a new simplified website.\nWith better continuous funding, our push servers will move from the US to Europe.\nWe have a new support mail: info@monal-im.org\nTwo years ago we decided to rewrite the Monal app almost entirely and improve it gradually in the process, instead of creating another XMPP Client for iOS and macOS.","title":"Insights Into Monal Development"},{"content":"Monal is an XMPP instant messaging client for macOS and iOS which strives to be the go-to client for these platforms just like the app Conversations IM is for Android. XMPP in general is an open and standardized protocol for real time communication. Anyone can host their own server and communicate freely with each other, just like with email and just like email the used addresses are of the form \u0026ldquo;user@domain.tld\u0026rdquo;. The user can use different apps and services, such as Monal, from a single but also multiple accounts. This serves a decentral and sovereign infrastructure and digital communication on the internet but also offers many potential for innovation. The chat client for iOS and macOS involves implementing various XEP standards (XMPP extension protocols, adding modern functionality to the XMPP-core and XMPP-im RFCs, see XMPP Extensions).\nDesigned for iOS and Mac Things look and work the way you expect. iOS, iPadOS or macOS, there is a version of Monal for you.\nMonal is developed under an open-source BSD license that serves the user, while not selling or tracking information for external parties (nor for anyone else). This app exists because it is key to ensure usability on all platforms and within the XMPP network with all its positives aspects when it comes to decentral communication and infrastructure.\nFind the development on GitHub!\n","permalink":"https://monal-im.github.io/monal-im.org/site/home/","summary":"Monal is an XMPP instant messaging client for macOS and iOS which strives to be the go-to client for these platforms just like the app Conversations IM is for Android. XMPP in general is an open and standardized protocol for real time communication. Anyone can host their own server and communicate freely with each other, just like with email and just like email the used addresses are of the form \u0026ldquo;user@domain.","title":"Monal-IM. Privacy like it's 1999"},{"content":"Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies\nReleases Privacy Policy 6.0 and newer Privacy Policy Rev 003 5.2.0 up to 5.4.x Privacy Policy Rev 002 before 5.2.0 Privacy Policy Rev 001 ","permalink":"https://monal-im.github.io/monal-im.org/site/privacyarchive/privacyheader/","summary":"Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies","title":""},{"content":"Imprint Thilo Molitor Vogelsbergstr. 18 68642 Bürstadt Germany\neMail: info[at]monal[minus]im[dot]org\nAbout Monal originates in 2002 as fork of the SworIM app. Until 2019 it has been developed by Anu Pokharel. Since then Thilo Molitor took over the development and joined in 2020 with Friedrich Altheide. From initial rewrite of code in the backend the entire app has been upgraded with a modern XMPP engine, new features and future-proof setup. Monal challenges to be the go-to XMPP chat-app for the iOS and macOS platform.\nMonal Team Thilo Molitor - About me on wiki.xmpp.org\nFriedrich Altheide\n","permalink":"https://monal-im.github.io/monal-im.org/site/about/","summary":"Imprint Thilo Molitor Vogelsbergstr. 18 68642 Bürstadt Germany\neMail: info[at]monal[minus]im[dot]org\nAbout Monal originates in 2002 as fork of the SworIM app. Until 2019 it has been developed by Anu Pokharel. Since then Thilo Molitor took over the development and joined in 2020 with Friedrich Altheide. From initial rewrite of code in the backend the entire app has been upgraded with a modern XMPP engine, new features and future-proof setup. Monal challenges to be the go-to XMPP chat-app for the iOS and macOS platform.","title":"About"},{"content":"Talks and other documents Molitor, Thilo; Altheide, Friedrich. Modern XMPP - A story based on Monal Berlin XMPP Meetup, 13th April 2022, Recording, Slides Molitor, Thilo; Altheide, Friedrich. Privacy friendly push Berlin XMPP Meetup, 13th April 2022, Recording, Slides (starting after page 29) Molitor, Thilo. XMPP Push notifications on iOS Molitor, Thilo. Monal development recap 2019 - 2021 and open discussion Berlin XMPP Meetup, 13th October 2021, Recording XEP publications XEP-0353: Jingle Message Initiation Authors: Philipp Hancke, Peter Saint-Andre, Thilo Molitor This specification provides a way for the initiator of a Jingle session to propose sending an invitation in an XMPP message stanza, thus taking advantage of message delivery semantics instead of sending IQ stanzas to all of the responder\u0026rsquo;s online resources or choosing a particular online resource.\nXEP-0474: SASL SCRAM Downgrade Protection Authors: Thilo Molitor This specification provides a way to secure the SASL and SASL2 handshakes against method and channel-binding downgrades.\nXEP-0388: Extensible SASL Profile Authors: Dave Cridland, Thilo Molitor, Matthew Wild This document describes a replacement for the SASL profile documented in RFC 6120 which allows for greater extensibility.\nXEP-0480: SASL Upgrade Tasks Authors: Thilo Molitor This specification provides a way to upgrade to newer SASL mechanisms using SASL2 tasks.\n","permalink":"https://monal-im.github.io/monal-im.org/site/publications/","summary":"Talks and other documents Molitor, Thilo; Altheide, Friedrich. Modern XMPP - A story based on Monal Berlin XMPP Meetup, 13th April 2022, Recording, Slides Molitor, Thilo; Altheide, Friedrich. Privacy friendly push Berlin XMPP Meetup, 13th April 2022, Recording, Slides (starting after page 29) Molitor, Thilo. XMPP Push notifications on iOS Molitor, Thilo. Monal development recap 2019 - 2021 and open discussion Berlin XMPP Meetup, 13th October 2021, Recording XEP publications XEP-0353: Jingle Message Initiation Authors: Philipp Hancke, Peter Saint-Andre, Thilo Molitor This specification provides a way for the initiator of a Jingle session to propose sending an invitation in an XMPP message stanza, thus taking advantage of message delivery semantics instead of sending IQ stanzas to all of the responder\u0026rsquo;s online resources or choosing a particular online resource.","title":"Publications"}] \ No newline at end of file +[{"content":"We are pleased to announce that we got selected in another funding round by the EU’s NGI via the NLnet Foundation NGI0 Entrust Fund to work on some important features in Monal.\nIn short this consists of the following tasks (in no special order).\nImplement Dialpad: Add Dialpad to our Call-UI and backend code to be able to send DTMF tones in A/V calls. This will make Monal fully compatible with jmp.chat, like Snikket is already. Rewrite Chat UI: Our current chat UI is still UIKit-based and it\u0026rsquo;s hard to improve it or fix some UI glitches. We want to rewrite and modernize the whole chat UI using SwiftUI. This will not only simplify maintenance a lot and allow us to fix these UI glitches, but also enable us to implement modern XMPP features like message reactions, message styling, message replies or mentions. UI work: Implement Message Reactions, Rich Replies and Stickers: Implement UI and backend for message reactions (XEP-0444), rich replies (XEP-0461) and Stickers, once the chat UI is ported to SwiftUI XSF work: After having successfully worked on the SASL2 XEP-suite, I want to modernize XEP-0389: Extensible In-Band Registration to also send only password hashes instead of cleartext passwords (similar to password upgrades specced in XEP-0480: SASL Upgrade Tasks) Write documentation of Monal internals: After having started to publish a blog series and wiki articles about Monal\u0026rsquo;s internals (beginning with the Handlers Framework), I want to publish blog and wiki articles on our XML query-language (intentionally based on the XPath-like syntax of Prosody\u0026rsquo;s query language), the PubSub/PEP framework, Model-Classes used as data sources for our UI (MLContact, MLMessage etc.) and possibly more. Thanks again to NLNet for fund this!\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00013-nlnet-funding2/","summary":"We are pleased to announce that we got selected in another funding round by the EU’s NGI via the NLnet Foundation NGI0 Entrust Fund to work on some important features in Monal.\nIn short this consists of the following tasks (in no special order).\nImplement Dialpad: Add Dialpad to our Call-UI and backend code to be able to send DTMF tones in A/V calls. This will make Monal fully compatible with jmp.","title":"New NLNet Funding"},{"content":"Our current development iPhone 8, which we bought in 2020, is getting on in years, is not able to run iOS 17 and the battery is broken.\nSo it\u0026rsquo;s that time again: we are launching a new fundraising campaign for 350 EUR to finance a new development iPhone capable of running iOS 17 and several upcoming iOS versions. Currently we are aiming for an iPhone 13.\nYou can view our donation options over here: Donate\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00012-funding-iphone13/","summary":"Our current development iPhone 8, which we bought in 2020, is getting on in years, is not able to run iOS 17 and the battery is broken.\nSo it\u0026rsquo;s that time again: we are launching a new fundraising campaign for 350 EUR to finance a new development iPhone capable of running iOS 17 and several upcoming iOS versions. Currently we are aiming for an iPhone 13.\nYou can view our donation options over here: Donate","title":"New fundraising campaign"},{"content":"Radically Open Security (ROS) kindly performed a security audit of some parts of Monal.\nSpecifically they audited the usage of our XML query language and the implementations of SASL2, SCRAM and SSDP.\nThe results in a nutshell: no security issues found, read the full report here: Monal IM penetration test report 2024 1.0 .\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00011-security-audit-1/","summary":"Radically Open Security (ROS) kindly performed a security audit of some parts of Monal.\nSpecifically they audited the usage of our XML query language and the implementations of SASL2, SCRAM and SSDP.\nThe results in a nutshell: no security issues found, read the full report here: Monal IM penetration test report 2024 1.0 .","title":"ROS Security Audit"},{"content":"Some may have predicted it, but now it happened: the chinese government banned Monal from the chinese appstore. Below is the complete email we got from Apple regarding this ban. We got that mail twice, once on Wed, 27 Mar 2024 15:46:18 +0100 and a second time on Thu, 28 Mar 2024 17:01:19 +0100.\nThe macOS version of Monal is still available in the appstore and with homebrew, though.\nHere is the full mail, a translation of the CAC articles can be found over here for reference.\nHello,\nWe are writing to notify you that your application, per demand from the CAC (Cyberspace Administration of China), will be removed from the China App Store because it includes content that is illegal in China, which is not in compliance with the App Review Guidelines:\nLegal Apps must comply with all legal requirements in any location where you make them available (if you’re not sure, check with a lawyer). We know this stuff is complicated, but it is your responsibility to understand and make sure your app conforms with all local laws, not just the guidelines below. And of course, apps that solicit, promote, or encourage criminal or clearly reckless behavior will be rejected. According to the CAC, your app violates Articles 3 of the Provisions on the Security Assessment of Internet-based Information Services with Attribute of Public Opinions or Capable of Social Mobilization (具有舆论属性或社会动员能力的互联网信息服务安全评估规定).\nIf you need additional information regarding this removal or the laws and requirements in China, we encourage you to reach out directly to the CAC (Cyberspace Administration of China).\nWhile your app has been removed from the China App Store, it is still available in the App Stores for the other territories you selected in App Store Connect. The TestFlight version of this app will also be unavailable for external and internal testing in China and all public TestFlight links will no longer be functional.\nBest regards,\nApp Review\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00010-ios-banned/","summary":"Some may have predicted it, but now it happened: the chinese government banned Monal from the chinese appstore. Below is the complete email we got from Apple regarding this ban. We got that mail twice, once on Wed, 27 Mar 2024 15:46:18 +0100 and a second time on Thu, 28 Mar 2024 17:01:19 +0100.\nThe macOS version of Monal is still available in the appstore and with homebrew, though.\nHere is the full mail, a translation of the CAC articles can be found over here for reference.","title":"iOS app banned from chinese appstore"},{"content":"It came to light that our publications previously linked in a section under About were not that discoverable. Now we moved the whole publications list to its own top level menu entry unter Publications.\nEnjoy watching the talk recordings and reading the slides and XEPs.\nAnd last but not least: Happy new year!\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00009-publications/","summary":"It came to light that our publications previously linked in a section under About were not that discoverable. Now we moved the whole publications list to its own top level menu entry unter Publications.\nEnjoy watching the talk recordings and reading the slides and XEPs.\nAnd last but not least: Happy new year!","title":"Publications moved"},{"content":"After several month of hard work we just released Monal 6.0. This version comes with new artwork by Ann-Sophie Zwahlen, support for Audio-Calls funded by the EU’s NGI Assure via the NLnet Foundation and many other improvements and bugfixes. The full list of changes can be seen below:\nNEW: Audio-call support (This feature will not be available to users in China and macOS users!)\nOther changes:\nNew Logo and new placeholder images by Ann-Sophie Zwahlen New \u0026ldquo;Add Contact\u0026rdquo; and \u0026ldquo;Contact Requests\u0026rdquo; UI Complete rewrite of OMEMO code Speed up app start Add support for SASL2 (XEP-0388) Implement XEP-0424: Message Retraction Add support for creating invitations (button only displayed if your server supports it, see https://docs.modernxmpp.org/client/invites/) Add timestamp when quoting older messages Always show a \u0026ldquo;Notes to self“ chat Overhaul implementation of last interaction display Show scroll-down button in groupchats OMEMO keys are copyable now (double tap) Add OSS based crash reporting (KSCrash), reports can be voluntarily sent via mail Fix logfile handling Add XEP-0215 (external services) to server details ui Only show contacts in contacts panel if they are in our roster Implement invitations using qr codes in addition of xmpp: uris Implement new image viewer compatible with iOS 17 Implement gif support in image viewer Bugfixes:\nMany bugfixes Fix bookmarks2 handling Fix XEP-0333 in private groups Fix url preview for sites not having oc: tags Set notifications to \u0026ldquo;mention only\u0026rdquo; when joining public channels Show per-resource last interaction timestamp in resource list Fix file uploading and sharing Fix timer when recording audio messages Fix muc avatar fetching ","permalink":"https://monal-im.github.io/monal-im.org/site/post/00008-monal-6.0-released/","summary":"After several month of hard work we just released Monal 6.0. This version comes with new artwork by Ann-Sophie Zwahlen, support for Audio-Calls funded by the EU’s NGI Assure via the NLnet Foundation and many other improvements and bugfixes. The full list of changes can be seen below:\nNEW: Audio-call support (This feature will not be available to users in China and macOS users!)\nOther changes:\nNew Logo and new placeholder images by Ann-Sophie Zwahlen New \u0026ldquo;Add Contact\u0026rdquo; and \u0026ldquo;Contact Requests\u0026rdquo; UI Complete rewrite of OMEMO code Speed up app start Add support for SASL2 (XEP-0388) Implement XEP-0424: Message Retraction Add support for creating invitations (button only displayed if your server supports it, see https://docs.","title":"Monal 6.0 released"},{"content":"In this new series, I want to shine some light onto specific parts of Monal\u0026rsquo;s internals. It\u0026rsquo;s dedicated to programmers or people curious about how Monal works internally. If you want to give some feedback, feel free to send an email to thilo@monal-im.org\nHandlers Handlers in Monal are something like serializable callbacks. In iOS the app can get frozen or even killed any time and the push implementation requires the complete app state to frequently transition between the Main App and the Notification Service App Extension (NSE). Using normal callbacks (called blocks in ObjC) is not possible because blocks are not serializable which means they could not survive an app kill or transition to / from the NSE.\nShort overview:\nSimple generalized concept usable throughout the app Leverages dynamic language features of ObjC \u0026ldquo;Serializable callbacks\u0026rdquo; to class / instance methods of ObjC classes Bind values (not vars) when creating a handler (e.g. to bind state to handler that can be serialized together with the handler) Bind vars when calling handler (overwriting creation-time bound values having the same name) Used in various places throughout the app like the IQ or PubSub framework (see Code examples found in the wild) Jump directly to list of supported data types Usage description with examples Define handler method This will be a static class method and doesn\u0026rsquo;t have to be declared in any interface to be usable. The argument number or order does not matter, feel free to reorder or even remove arguments you don\u0026rsquo;t need. Arguments declared with $$-prefix are mandatory and can not be removed, though. Arguments with $_-prefix are optional and can be removed. Primitive datatypes like BOOL, int, NSINTEGER (aka $$INTEGER) etc. can not be imported as optional and are always mandatory.\n$$class_handler(myHandlerName, $_ID(xmpp*, account), $$BOOL(success)) // your code comes here // variables defined/imported: account (optional), success (mandatory) $$ Instance handlers are instance methods instead of static methods. You need to specify on which instance these handlers should operate. The instance extraxtion statement (the second argument to $$instance_handler() can be everything that returns an objc object. For example: account.omemo or [account getInstanceToUse] or just account.\n$$instance_handler(myHandlerName, instanceToUse, $$ID(xmpp*, account), $$BOOL(success)) // your code comes here // \u0026#39;self\u0026#39; is now the instance of the class extracted by the instanceToUse statement. // instead of the class instance as it would be if $$class_handler() was used instead of $$instance_handler() // variables defined/imported: account, success (both mandatory) $$ Call defined handlers Calling a defined handler is simple, just create a handler object using $newHandler() and $call() it.\nMLHandler* h = $newHandler(ClassName, myHandlerName); $call(h); Bind variables when creating a handler You can bind variables to MLHandler objects when creating them and when invoking them. Variables supplied on invocation overwrite variables supplied when creating the handler if the names are equal. Variables bound to the handler when creating it have to conform to the NSCoding protocol to make the handler serializable.\nNSString* var1 = @\u0026#34;value\u0026#34;; MLHandler* h = $newHandler(ClassName, myHandlerName, $ID(var1), $BOOL(success, YES) })); xmpp* account = nil; $call(h, $ID(account), $ID(otherAccountVarWithSameValue, account)) Usable shortcuts to create MLHandler objects: $newHandler(ClassName, handlerName, boundArgs...) $newHandlerWithInvalidation(ClassName, handlerName, invalidationHandlerName, boundArgs...) Using invalidation handlers You can add an invalidation method to a handler when creating the MLHandler object (after invalidating a handler you can not call or invalidate it again!). Invalidation handlers can be instance handlers or static handlers, just like with \u0026ldquo;normal\u0026rdquo; handlers:\n// definition of normal handler method as instance_handler $$instance_handler(myHandlerName, [account getInstanceToUse], $_ID(xmpp*, account), $$BOOL(success)) // your code comes here // \u0026#39;self\u0026#39; is now the instance of the class extracted by [account getInstanceToUse] // instead of the class instance as it would be if $$class_handler() was used instead of $$instance_handler() $$ // definition of invalidation method $$class_handler(myInvalidationHandlerName, $$BOOL(done), $_ID(NSString*, var1)) // your code comes here // variables imported: var1, done // variables that could have been imported according to $newHandler and $call below: var1, success, done $$ MLHandler* h = $newHandlerWithInvalidation(ClassName, myHandlerName, myInvalidationHandlerName, $ID(var1, @\u0026#34;value\u0026#34;), $BOOL(success, YES) })); // call invalidation method with \u0026#34;done\u0026#34; argument set to YES $invalidate(h, $BOOL(done, YES)) Available data types The following datatypes can be bound to a handler defining them using the corresponding definitions having either the $$ or $_ prefix. If the single argument binding is used, the value is bound using the same name like the var the value is coming from (in this example: name).\ndefine: $$ID(NSObject*, name), $_ID(NSObject*, name), bind: $ID(name), $ID(name, value) define: $$HANDLER(name), $_HANDLER(name), bind: $HANDLER(name), $HANDLER(name, value) define: $$BOOL(name), bind: $BOOL(name), $BOOL(name, value) define: $$INT(name), bind: $INT(name), $INT(name, value) define: $$DOUBLE(name), bind: $DOUBLE(name), $DOUBLE(name, value) define: $$INTEGER(name), bind: $INTEGER(name), $INTEGER(name, value), this corresponds to the NSInteger type alias define: $$UINTEGER(name), bind: $UINTEGER(name), $UINTEGER(name, value), this corresponds to the NSUInteger type alias Code examples found in the wild Enabling carbons if([features containsObject:@\u0026#34;urn:xmpp:carbons:2\u0026#34;]) { DDLogInfo(@\u0026#34;got disco result with carbons ns\u0026#34;); if(!account.connectionProperties.usingCarbons2) { DDLogInfo(@\u0026#34;enabling carbons\u0026#34;); XMPPIQ* carbons = [[XMPPIQ alloc] initWithType:kiqSetType]; [carbons addChildNode:[[MLXMLNode alloc] initWithElement:@\u0026#34;enable\u0026#34; andNamespace:@\u0026#34;urn:xmpp:carbons:2\u0026#34;]]; [account sendIq:carbons withHandler:$newHandler(self, handleCarbonsEnabled)]; } } $$class_handler(handleCarbonsEnabled, $$ID(xmpp*, account), $$ID(XMPPIQ*, iqNode)) if([iqNode check:@\u0026#34;/\u0026lt;type=error\u0026gt;\u0026#34;]) { DDLogWarn(@\u0026#34;carbon enable iq returned error: %@\u0026#34;, [iqNode findFirst:@\u0026#34;error\u0026#34;]); [HelperTools postError:[NSString stringWithFormat:NSLocalizedString(@\u0026#34;Failed to enable carbons for account %@\u0026#34;, @\u0026#34;\u0026#34;), account.connectionProperties.identity.jid] withNode:iqNode andAccount:account andIsSevere:YES]; return; } account.connectionProperties.usingCarbons2 = YES; $$ Fetching OMEMO bundles NSString* bundleNode = [NSString stringWithFormat:@\u0026#34;eu.siacs.conversations.axolotl.bundles:%@\u0026#34;, deviceid]; [self.account.pubsub fetchNode:bundleNode from:jid withItemsList:nil andHandler:$newHandler(self, handleBundleFetchResult, $ID(rid, deviceid))]; $$instance_handler(handleBundleFetchResult, account.omemo, $$ID(xmpp*, account), $$ID(NSString*, jid), $$BOOL(success), $_ID(XMPPIQ*, errorIq), $_ID(NSString*, errorReason), $_ID((NSDictionary\u0026lt;NSString*, MLXMLNode*\u0026gt;*), data), $$ID(NSString*, rid)) if(!success) { if(errorIq) DDLogError(@\u0026#34;Could not fetch bundle from %@: rid: %@ - %@\u0026#34;, jid, rid, errorIq); else DDLogError(@\u0026#34;Could not fetch bundle from %@: rid: %@ - %@\u0026#34;, jid, rid, errorReason); } else { // check that a corresponding buddy exists -\u0026gt; prevent foreign key errors MLXMLNode* receivedKeys = [data objectForKey:@\u0026#34;current\u0026#34;]; if(!receivedKeys \u0026amp;\u0026amp; data.count == 1) { // some clients do not use \u0026lt;item id=\u0026#34;current\u0026#34;\u0026gt; receivedKeys = [[data allValues] firstObject]; } else if(!receivedKeys \u0026amp;\u0026amp; data.count \u0026gt; 1) { DDLogWarn(@\u0026#34;More than one bundle item found from %@ rid: %@\u0026#34;, jid, rid); } if(receivedKeys) { [self processOMEMOKeys:receivedKeys forJid:jid andRid:rid]; } } $$ ","permalink":"https://monal-im.github.io/monal-im.org/site/post/00007-monal-internals-handlers/","summary":"In this new series, I want to shine some light onto specific parts of Monal\u0026rsquo;s internals. It\u0026rsquo;s dedicated to programmers or people curious about how Monal works internally. If you want to give some feedback, feel free to send an email to thilo@monal-im.org\nHandlers Handlers in Monal are something like serializable callbacks. In iOS the app can get frozen or even killed any time and the push implementation requires the complete app state to frequently transition between the Main App and the Notification Service App Extension (NSE).","title":"Monal Internals - Handlers framework"},{"content":"Axel Reimer recently created some good video tutorials about Monal and XMPP in general.\nThese video tutorials can be found over here: https://www.eversten.net/videotutorials/.\nCurrently the audio of these videos is German only.\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00006-eversten-xmpp-videos/","summary":"Axel Reimer recently created some good video tutorials about Monal and XMPP in general.\nThese video tutorials can be found over here: https://www.eversten.net/videotutorials/.\nCurrently the audio of these videos is German only.","title":"XMPP Tutorials"},{"content":" Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies\nReleases Privacy Policy 6.0 and newer Privacy Policy Rev 003 5.2.0 up to 5.4.x Privacy Policy Rev 002 before 5.2.0 Privacy Policy Rev 001 Privacy Monal App ≥ 6.0.0 TLDR We never see your messages. We do not know who you are chatting with. We can not identify a user. We can see your XMPP domain and a Monal specific unique device id every time you receive a push message We see your IP addresses if you are on a call and your XMPP server does not provide a STUN or TURN server. We may see your contact\u0026rsquo;s IP address if you are using our TURN server. Structure The App Monal may interact with Monal servers to support Push messages or if you are establishing a call with a contact but your XMPP Server does neither provide a STUN nor a TURN server.\nOur privacy details are structured as follows. First, we would like to give you a short introduction how Monal is handling push messages to ensure a pleasant user experience. We will then briefly explain VoIP calls and its privacy implications. Afterwards we like to inform you how we are using crash and usage reports, logs and GDPR Subject Access Requests (SAR).\nPush App Resources are very limited on iOS and macOS. Monal for example can only run a limited time in the background after a user either locked the screen or switched the app. Hence, apps on iOS and macOS can not simply keep a connection to your XMPP server open 24/7 to inform you about new messages. To overcome these limitations your XMPP server can request our push server to send push messages to your device through Apple. With these push messages we can request Apple to wake up Monal on your device. Once it is woken up it has about 30 seconds to connect to your XMPP server, fetch all new messages and show a push notification for these new messages, if needed.\nHow push works Every time that Monal loggs in at your XMPP servers, it asks your server to inform our push server once you receive an XMPP message while Monal is closed/disconnected. To do this, we request a Monal specific push token from Apple and provide this token to your XMPP server. Using this Monal specific push token your XMPP server can instruct our push server to send push messages via Apples push system to wake up the app on your device.\nOnce push messages are enabled for your Monal instance on all your XMPP servers, your XMPP servers will open a encrypted server to server (s2s) connection to one of our push servers. Using this s2s connection your XMPP servers will then be able to talk to our push servers. To wake up your Monal instance your XMPP servers send us:\nYour unique Monal specific push token that was generated by Apple The domain of the XMPP server that you are using Push We never see your messages. We do not know who you are chatting with. We could only ever track what XMPP domains a push token is/was using. We can not identify a user. Push-Servers We currently provide the following independent push server regions:\nEurope Alpha (based in Europe, only used for debugging with higher log levels, not for production use) Note: Our previously used US push region was unfortunately shutdown due to fosshost ceasing operation.\nHow to change the push region Open Monal Open up the settings menu in the upper left corner (gearwheel) Open the Notifications menu Scroll down Select a region Push server regions If you are an XMPP server administrator, and you restricted s2s connections, please allow s2s to all our regions.\nRegion Hostname Notice Europe eu.prod.push.monal-im.org Push server locations Name Region Hoster Location Notice s1.eu.prod.push.monal-im.org Europe Hetzner Finland s2.eu.prod.push.monal-im.org Europe PHP-Friends Germany VoIP (STUN / TURN) With Monal 6.0 we introduced VoIP support. To establish the connection between you and the remote party (the remote contact) Monal utilizes STUN and TURN. In general STUN (Session Traversal Utilities for NAT) is used to allow a VoIP call even when you are behind firewalls.\nCalls established using only STUN will directly exchange packets (P2P) between you and your contact. Hence, your contact may see your IP address. If you do not want your contact to see your IP Address while being on a call, disable P2P connection in Monal\u0026rsquo;s privacy settings. Once disabled Monal tries to establish the call using a TURN (Traversal Using Relays around NAT) server.\nNote: Not all XMPP servers currently provide STUN and TURN servers. If your XMPP server does not provide STUN and TURN servers, Monal may use our fallback servers. These fallback servers provide both STUN and TURN. You can disable Monal to use these fallback turn servers. Please note, that we may disable our fallback STUN and TURN servers at any time, if too many users are using them.\nIf you use our fallback servers we will see:\nYour IP Addresses The IPs of your contact or the IPs of their TURN-Server The duration of the call We will not see the contents of that call, because these are E2E encrypted.\nCrash reports and app usage Monal does track crashes and usage data anonymously using the tools provided by Apple. This is opt-in only and controlled by iOS and macOS global settings. If a user decides not to send any data to developers, no crash logs are sent to Monal developers.\nLogs Your local device will contain a log file with all sent and received raw XMPP messages as well as debug logs. It does contain sensitive personal data! This file will never be transferred to us, except if you explicitly (manually) send it to us (e.g., via mail).\nGDPR Subject Access Requests (SAR) European GDPR allows users to request a copy of all data retained about them. Starting with Monal 5.2.0 we no longer see your JIDs (username@domain.tld) in our push servers. We therefore are not able to send you retained data related to your JID. We furthermore are unable to provide your retained data related to your unique push token because we have no way to verify that Apple issued you a provided token. If you have questions regarding GDPR, please send us a mail to info@monal-im.org.\n","permalink":"https://monal-im.github.io/monal-im.org/site/privacyarchive/monal_app_rev_003/","summary":"Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies","title":"Privacy Monal App ≥ 6.0.0"},{"content":"I recently wrote a summary about push on iOS in the xmpp.org wiki.\nSee over here for all the technical details and links to the documentation. I also talked about that topic in my talk \u0026ldquo;Modern XMPP - A story based on Monal\u0026rdquo; linked on the About page over here.\nFor convenience I\u0026rsquo;d like to summarize some parts of that wiki entry in this blog-post, too.\nUPDATE: This post describes the way Monal implements push as well as the pitfalls of implementing it in another way. I tried to make this clearer in the text now.\nBackground knowledge: Push on iOS On iOS there are several push modes having different properties. All modes, except VoiIP pushes, have in common, that they only provide 30 seconds of background time.\nVoIP pushes: MUST always make the device ring via Apple\u0026rsquo;s CallKit framework. You can\u0026rsquo;t use these pushes to silently retrieve messages or other XMPP stanzas in the background. Low priority pushes: These pushes don\u0026rsquo;t show any user-visible notification, but they can be dropped or arbitrarily delayed by Apple. They grant 30 seconds of background time. High priority pushes: These MUST show a user-visible notification. They grant 30 seconds of background time. But: Since iOS 13.3, apps having the com.apple.developer.usernotifications.filtering entitlement are allowed to suppress the user-visible notification. To cite Apple: This entitlement is intended for certain types of apps — such as messaging apps or location sharing apps — that use notification service extensions to receive push notifications without delivering notifications to the user.\nHigh priority pushes in combination with the com.apple.developer.usernotifications.filtering entitlement are not only used by Monal, but some other popular messaging apps, too (links to the source):\nWhatsApp Signal Threema Telegram (binary) Monal Monal is using this entitlement to wake up background processing without sending any message data through Apple\u0026rsquo;s servers (not even ecrypted data). When iOS grants the app it\u0026rsquo;s 30 seconds background time because of the incoming push, Monal then connects to the XMPP server over the network to retrieve the actual message and display a notification to the user, if needed.\nSignal does exactly the same: It uses push only to wake up the app and then fetches the messages using a dedicated network connection: Example in Signal\u0026rsquo;s code\nThis way Monal avoids all of the pitfalls depicted below!\nDiving deeper: Some more details about iOS push and XMPP The following explanations and thoughts are a bit more technical and require some understanding of the XMPP protocol and it\u0026rsquo;s inner workings.\nPush server implementations and iOS time limits Pushes of all types (see above) can only wake up the iOS app for 30 seconds. But in most cases that\u0026rsquo;s more than enough to connect to the xmpp server and retrieve pending stanzas (if using the entitlement mentioned above and XEP-0198, it is even possible to get pushes for iq stanzas etc., thus behaving like being permanently connected while still sleeping most of the time because of CSI). Even if the 30 seconds don\u0026rsquo;t suffice, the client can disconnect and both, Prosody and eJabberd, will send another push if there are still unacked stanzas in the XEP-0198 queue. This will give the app another 30 seconds. Even longer catchups lasting for \u0026gt; 5 minutes can be done completely in the background this way (observed in the wild with Monal stable).\nThis means that even with the 30 second time limit in place, it usually is possible to do a longer lasting catchup completely in the background, effectively extending the time limit to several minutes. This obviously only holds, if you use the com.apple.developer.usernotifications.filtering entitlement and connect directly to the xmpp server and is hardly possible if you try to transport stanzas through the push sent through Apple (see below).\nPitfalls: Transporting (encrypted) xmpp message stanzas through push (out of band) When using the iOS push infrastructure provided by apple for transporting (encrypted) stanzas out of band, multiple things have to be considered. First of all, pushes can get lost. That frequently happens if the device was in flight mode while the push was sent. Second, xmpp is a streaming protocol, strongly relying on the ordering of stanza (even inter-type ordering like the ordering of message and iq stanzas for mam). The order of message stanza matters for other XEPs, too (for example message retraction or last message correction). Using the iOS push service which is loosing pushes or even only sending pushes for a particular type of stanza (message stanzas having a body for example) breaks this ordering of events that every XEP implicitly relies upon. The payload sizes allowed for each push are also somewhat low (~4kb including some of the push metadata). OMEMO\u0026rsquo;s self-healing through key-transport-elements requires the client to send those key-transport message stanzas once a broken session gets detected. But using the push service for data transport is a one way channel only.\nLast but not least the UX can be really degraded if a user does not open the app for some hours (while still receiving push notifications). Once they open the app, a long mam catchup has to be waited for until the ui does reflect what the user already saw in notifications. If the device has no connectivity when the user opens it, they might even be really confused why those messages they alread saw a notification for are not displayed in the app at all). Writing incoming messages to the database to solve this will only make the ordering problem depicted above harder. The client not being able to execute the OMEMO self-healing stuff mentioned above will degrade UX further.\nNOT using the entitlement mentioned above will prevent the client from receiving push notifications for XEP-0333 read markers and remove already displayed notifications instead of posting a new one (because apps not having that entitlement are forced to show a notification for each incoming high priority push, even if the push was only for a XEP-0333 read marker). To be clear: without that entitlement neither message retraction nor XEP-0333 read markers can be implemented reliably!\nAnd if an app has the entitlement: why bother delivering some stanzas out of band and running into the ordering problem if the app could as well connect to the xmpp server in the background and retrieve all pending stanzas in the right order?\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00005-push-on-ios/","summary":"I recently wrote a summary about push on iOS in the xmpp.org wiki.\nSee over here for all the technical details and links to the documentation. I also talked about that topic in my talk \u0026ldquo;Modern XMPP - A story based on Monal\u0026rdquo; linked on the About page over here.\nFor convenience I\u0026rsquo;d like to summarize some parts of that wiki entry in this blog-post, too.\nUPDATE: This post describes the way Monal implements push as well as the pitfalls of implementing it in another way.","title":"Push on iOS"},{"content":"SASL (Simple Authentication and Security Layer) as used in XMPP is broken. In this blog post I\u0026rsquo;ll try to explain why and propose some fixes.\nUpdate (2023-04-21): Since I originally wrote this blog post, I\u0026rsquo;ve had the ability to discuss several of my ideas with Dave (the original author of XEP-0388 dubbed SASL2), MattJ (one of the authors of the prosody xmpp server) and others. Most, if not all, of my issues are now addressed in a bunch of updates to existing XEPs as well as new XEPs:\nUpdate of XEP-0388 (SASL2): https://xmpp.org/extensions/xep-0388.html New SASL2- and SCRAM-upgrade XEP: https://xmpp.org/extensions/xep-0480.html New XEP for downgrade protection when using SCRAM: https://xmpp.org/extensions/xep-0474.html Already existing XEP that only now gets adopted by server developers: XEP-0440 The rest of this blog post remains as is and can be used for a deeper introduction into the material and as explanation of some of the rationale behind the SASL2 updates and my ProtoXEP.\nA Modern Authentication Protocol In my opinion a modern authentication protocol should have at least the following properties. Of course that can be subject to debate, but I think most of us will agree on the following list.\nallow for protocol agility (e.g. adding new authentication mechanisms, like adding new cipher suites in TLS) prevent downgrade attacks on authentication mechanisms (we don\u0026rsquo;t want an active attacker to be able to force us to use a weak mechanism) prevent storage of plaintext passwords on the server (that\u0026rsquo;s obvious: we don\u0026rsquo;t want a hacker to be able to steal our plaintext passwords once he hacked the database) prevent replay attacks (we don\u0026rsquo;t want a MITM (man in the middle) be able to steal a (possibly hashed) password and use it to authenticate herself) (possibly) prevent/detect MITM altogether How SASL tries to fulfill these properties First of all: XMPP Core mandates the use of TLS for everything, including authentication. Keep that in mind, when reading the rest of this blog post.\nProperty 1 SASL as defined for XMPP allows the server to present a list of authentication methods. The client then picks the one having the highest perceived strength (see XMPP-Core 6.3.3) among the ones it implements. XEP-0438: Best practices for password hashing and storage lists some common authentication methods and how they should be ordered. Currently, the methods PLAIN (plaintext password), EXTERNAL (using client certificates to authenticate the user) and SCRAM (Salted Challenge Response Authentication Mechanism) are common.\n(I will not talk about SASL EXTERNAL in this blog post, because it does not use passwords and seems to be super uncommon in the XMPP world.)\nThis generally allows adding new mechanisms in the future, protocol agility seems to be fulfilled, right?\nProperty 3 Current mandatory SASL methods include SCRAM-SHA-1 and SCRAM-SHA-1-PLUS (if possible). SCRAM generally allows the server to store a salted hash instead of plaintext passwords.\nEven if the client uses the PLAIN method, the server could store the password as salted hash.\nAnd EXTERNAL usually does not use any form of password.\nSo that\u0026rsquo;s another property of our list that is fulfilled, right?\nProperty 4 Using SCRAM it is even possible to prevent replay attacks because of the used challenge-response scheme. That\u0026rsquo;s even possible if no TLS channel is used.\nCool, another property that\u0026rsquo;s fulfilled by SCRAM as well, right?\nProperty 5 SCRAM is even cooler because it allows for TLS channel-binding.\nThis allows both entities (client and server) taking part in the SCRAM authentication to bind the authentication to the TLS channel using a HMAC (Hash-Based Message Authentication Code) to sign a unique data blob tied to the TLS session in use.\nIf the TLS channel is intercepted by a MITM, the attacker would have to use two separate TLS channels, one to the server and one to the client.\nBinding the authentication to the TLS channel allows the server and client to detect such an attacker and fail the authentication.\nTo indicate, that a server supports channel-binding, it appends the string -PLUS to the advertised SCRAM methods.\nIf the client supports channel-binding, it picks SCRAM-SHA-1-PLUS instead of SCRAM-SHA-1.\nIn case the client supports channel-binding, but only received methods without channel-binding, the client uses the SCRAM method without -PLUS, but also indicates that it would have used the PLUS varriant if offered by the server (SCRAM Channel Binding).\nThis allows for the server to detect downgrade attacks and fail the authentication.\nBecause there are multiple different kinds of channel-binding to TLS possible, the client also specifies which binding it uses during the SCRAM flow (protocol agility).\nChannel binding prevents MITM altogether, right? Another property that\u0026rsquo;s fulfilled!\nWhat\u0026rsquo;s broken with SASL in XMPP Cautious readers will have noticed, that I left out property 2 (downgrade attack prevention) in my above explanation. That\u0026rsquo;s because SASL does not prevent downgrade attacks regarding the method negotiation at all. And that\u0026rsquo;s one of the main reasons why the whole SASL in XMPP stuff is so horribly broken.\nDowngrade of SASL methods The XMPP Core RFC even mentions downgrade attacks and suggests using TLS to mitigate them. But that\u0026rsquo;s not enough. If we assume the TLS channel to always be secure and MITM-free, we don\u0026rsquo;t even need SCRAM but could solely use PLAIN. The TLS channel already ensures no replay attacks can happen and storing the passwords securely using salted hashes on the server is still possible. We don\u0026rsquo;t need any channel-binding either, because that\u0026rsquo;s only needed if we assume someone has tampered with the TLS channel in the first place. In this scenario MITM-Prevention (property 5) is simply out of scope for SASL, because we assume TLS to always be MITM-free. That means our properties mentioned above are all fulfilled (property 5 by definition, the other ones by use of TLS) even if we abandon SCRAM and solely use PLAIN.\nIf we, on the other hand, don\u0026rsquo;t assume to always have a MITM-free TLS channel, then the above listed properties 2, 4 and 5 are all not fulfilled (that means: no downgrade prevention, no replay attack prevention and no MITM detection/prevention). The attacker could simply remove every advertised SASL method except PLAIN and thus get the plaintext password which is replayable and neither the server nor the client will detect this MITM. Supporting SCRAM in clients and servers does not help at all with this, because it simply will not be negotiated.\nWell, okay, but XEP-0438: Best practices for password hashing and storage (and some RFC I don\u0026rsquo;t remember) says, we should pin the last used SASL mechanism in the client to prevent downgrade attacks in further SASL sessions. That way the client won\u0026rsquo;t use SASL mechanisms having a perceived lower strength than the pinned one. Using a stronger one is still possible. That\u0026rsquo;s right, but it makes matters worse in regard to protocol agility while still not preventing the downgrade attack for the first connection of a client to the XMPP server.\nBroken protocol agility Protocol agility means we can specify new authentication methods later on and our client will always use the best one advertised by the server. That\u0026rsquo;s important because it allows us to gradually upgrade the security strength of our authentication while still maintaining backwards compatibility with older clients, eventually removing an old authentication method once most/all clients use a newer one (like replacing DIGEST-MD5 or CRAM-MD5 with SCRAM-SHA-XXX).\nSCRAM without PLUS variants Because of SCRAM fulfilling property 3 (preventing storage of plaintext passwords on the server), we can not upgrade the stored password hashes in the server\u0026rsquo;s database to a new SCRAM-based SASL mechanism. The obvious partial solution is to store new user\u0026rsquo;s passwords using the newer SCRAM algorithm and leave the old user\u0026rsquo;s passwords like they are. That way at least some of your users get to use the new SCRAM algorithm, slowly phasing out the old one eventually. An example would be a server that previously only supported SCRAM-SHA-1 now advertising support for SCRAM-SHA-256.\nOh, no! That doesn\u0026rsquo;t work either! The current specification of SASL in XMPP does send the list of supported SASL methods to the client before knowing which username the client wants to authenticate for. That means the server will always advertise SCRAM-SHA-256, even if the hash in the database is still SHA-1. If the client supports SCRAM-SHA-256 as well, it will happily pick that one and the server, only having the SHA-1 hash at hand, won\u0026rsquo;t be able to authenticate the user. The client on the other hand will have no way to detect why the authentication failed and switch to a percieved lower strength SASL algorithm (and even if that would be possible, it could possibly be used as a downgrade vector if done wrong).\nWell, method pinning to the rescue! We already talked about SASL method pinning. The client obviously knows which SASL method it used the last time it authenticated successfully and can always use just this method, no other, even if it implements some having a higher strength. That extends the pinning described in XEP-0438: Best practices for password hashing and storage to algorithms having a higher strength as well, something that, to my knowledge, isn\u0026rsquo;t specified anywhere. Additionally, that means we completely loose protocol agility after our first authentication. And newly offering SCRAM-SHA-256 on a server not storing plaintext passwords after it previously only advertised SCRAM-SHA-1 will likely still break authentication for all clients not doing this exact \u0026ldquo;always use the mechanism used on first auth\u0026rdquo; pinning.\nThe only way to advertise support for a new SCRAM hash algorithm and make clients use it is to upgrade your complete password database on the server by forcing a password reset upon all of your existing users. This must presumably be done out of band for XMPP. Clients implementing the strict pinning outlined above will have to reset the pinning once a new password gets entered by the user. If they don\u0026rsquo;t do so, this strict pinning to the old algorithm will still be in place and this client won\u0026rsquo;t be able to authenticate the user after the password reset.\nAnd I\u0026rsquo;ve not even started to talk about a user having two clients, one that only supports an old SCRAM algorithm (say SCRAM-SHA-1) and one that supports a new one (say SCRAM-SHA-256). The server obviously must store both hashes in its database to allow logins for both clients.\nSounds all pretty bad, right? How come, that hasn\u0026rsquo;t been discovered yet? Well, someone already identified these problems back in 2019. See this thread on the standards@xmpp.org mailinglist. But no attempt was made to fix them. Even the new XEP-0388: Extensible SASL Profile still uses the same protocol flow with no fix, albeit allowing for additional handshakes during the authorization phase like pipelining a bind request or resumption via XEP-0198: Stream Management onto the authorization.\nSidenote: One could solve this mess by sacrificing property 3 (not storing plaintext passwords on the server). If the plaintext password is stored on the server, every SCRAM algorithm can be used by the client. But do we really want that? At least that would allow the server to advertise new SCRAM algorithms without having to force a password reset.\nSCRAM with PLUS variants When looking at the channel-binding situation we already saw that the client specifies the type of channel-binding it wants to use. That allows for protocol agility, right?\nNo! The client does not have any way to detect which channel-binding type the server supports (appending -PLUS to the advertised SCRAM algorithm does not in any way specify which channel-binding to use). And if the client uses the wrong channel-binding the server does not support, the server will simply fail the authentication. The client will have no way to detect if the authentication failed because of the wrong channel-binding type used or if the actual password was wrong, like with using the \u0026ldquo;wrong\u0026rdquo; SASL algorithm above.\nThis renders the whole channel-binding protocol agility completely useless. And protocol agility is needed even for channel-binding!\nSome Solutions Well, that\u0026rsquo;s pretty bad news, right? But I don\u0026rsquo;t want to simply rant and leave the shard for someone else to collect, but propose fixes instead. And to my knowledge some of these problems are really fixable.\nIn this section I want to propose fixes to at least some of these problems. These fixes are open to debate and if we come up with even better solutions during this debate, that\u0026rsquo;d be great.\nRestoring protocol agility for channel-binding The server must not use -PLUS to indicate SCRAM algorithms with channel-binding, but use the name of the concrete channel-binding type as SCRAM algorithm suffix. That way the client will be able to determine if it supports that type of channel-binding and only select those SCRAM algorithms having a channel-binding it supports. The server is only allowed to advertise channel binding methods supported by the currently used channel (e.g. don\u0026rsquo;t advertise tls-unique on a TLS 1.3 channel, but only tls-exporter (if implemented)). Clients and servers may choose to still support the -PLUS SCRAM method names in addition to these new ones containing the concrete channel-binding type, but I don\u0026rsquo;t think that gets us anywhere.\nSome examples: SCRAM-SHA-1_TLS-UNIQUE or SCRAM-SHA-512_TLS-EXPORTER. That, of course, does not help at all, if channel-binding support can be rendered useless by a downgrade attack.\nPreventing downgrade of SASL methods Downgrades can be prevented by only allowing SASL EXTERNAL and SCRAM methods (or something similar to SCRAM that then mutual authenticates the whole protocol flow). The SCRAM client-final message must contain a client proof built using a HMAC not only covering the client-first-message-bare, server-first-message and client-final-message-without-proof, but also the (sorted) SASL method list. That allows the server to verify if the client used the correct list and this could not be manipulated, because it is ultimately signed with the client password, a MITM attacker can not know.\nWe can achieve this by adding an optional SCRAM attribute to client-first-message-bare which will be ignored by non-supporting servers, but secure the handshake against downgrades on supporting servers. This attribute (let\u0026rsquo;s name it d) will contain a base64-encoded hash of the sorted SASL method list as received by the client (using the same hash method as used in the whole SCRAM stuff). The server then checks if that hash matches the one it calculated itself by hashing the sorted SCRAM method list it advertised and fail the authentication, if these hashes don\u0026rsquo;t match.\nThe sorting can be done alphabetical in ascending order and the individual SASL methods be separated by \u0026lt; like done in XEP-0115: Entity Capabilities before the whole string is hashed.\nWe now have a working downgrade attack prevention that\u0026rsquo;s even backwards compatible with existing SCRAM methods and servers not supporting this new SCRAM attribute.\nRestoring protocol agility for SASL methods part #1 First of all, the server will have to store SCRAM hashes (or something similar for non-scram methods) for all methods it does support. If the server operator later decides to not offer a specific SASL method anymore, they can delete the (hash) data stored for that method from their server.\nSecond, the server can only advertise those methods it has hashes for in its database. That means it needs to know the username before advertising which methods it supports. This requires a change in the protocol flow for mechanism negotiation, which is not codified in the SASL RFC and can be changed via XEP. A good candidate would be XEP-0388: Extensible SASL Profile (also dubbed SASL2) which is not yet in Final state and thus can be adjusted to our needs.\nLet\u0026rsquo;s assume a SASL2 protocol flow by advertising support for this protocol, but not simultaneously advertising which SASL methods the server supports. The client would then first send the desired username it wants to authenticate for, and the server would respond with a list of supported SASL mechanisms for exactly this user. The username is of course not safe from a MITM attacker, but it will be included in the SCRAM authentication flow and the server will fail the authentication if that user differs from the one given earlier.\nAn example protocol flow using a modified SASL2 might look as follows (resembling more or less a normal SCRAM flow):\n\u0026lt;!-- Server sends stream features indicating support for SASL2. --\u0026gt; \u0026lt;stream:features\u0026gt; \u0026lt;authentication xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;/\u0026gt; \u0026lt;/stream:features\u0026gt; \u0026lt;!-- Client intiates authentication by sending the base64 encoded username it wishes to authenticate for. --\u0026gt; \u0026lt;request xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; \u0026lt;user\u0026gt;dXNlcg==\u0026lt;/user\u0026gt; \u0026lt;/request\u0026gt; \u0026lt;!-- Server sends the list of supported mechanisms for this user. The sorted list will be \u0026#39;SCRAM-SHA-1\u0026lt;SCRAM-SHA-1_TLS-EXPORTER\u0026lt;SCRAM-SHA-256\u0026lt;SCRAM-SHA-256_TLS-EXPORTER\u0026#39;, the corresponding base64 encoded SHA-1 hash (SHA-1 will be used because negotiated below) is: \u0026#39;U3vZANxXbl1pMOMBAFPnTb5YXWk=\u0026#39; --\u0026gt; \u0026lt;mechanisms xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; \u0026lt;mechanism\u0026gt;SCRAM-SHA-1\u0026lt;/mechanism\u0026gt; \u0026lt;mechanism\u0026gt;SCRAM-SHA-1_TLS-EXPORTER\u0026lt;/mechanism\u0026gt; \u0026lt;mechanism\u0026gt;SCRAM-SHA-256\u0026lt;/mechanism\u0026gt; \u0026lt;mechanism\u0026gt;SCRAM-SHA-256_TLS-EXPORTER\u0026lt;/mechanism\u0026gt; \u0026lt;/mechanisms\u0026gt; \u0026lt;!-- Client sends the selected mechanism alogside the initial-response data. --\u0026gt; \u0026lt;authenticate xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39; mechanism=\u0026#39;SCRAM-SHA-1_TLS-EXPORTER\u0026#39;\u0026gt; \u0026lt;!-- Base64 of: \u0026#39;p=tls-exporter,,n=user,r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6,d=U3vZANxXbl1pMOMBAFPnTb5YXWk=\u0026#39; --\u0026gt; \u0026lt;initial-response\u0026gt;cD10bHMtZXhwb3J0ZXIsLG49dXNlcixyPTEyQzRDRDVDLUUzOEUtNEE5OC04RjZELTE1QzM4RjUxQ0NDNixkPVUzdlpBTnhYYmwxcE1PTUJBRlBuVGI1WVhXaz0=\u0026lt;/initial-response\u0026gt; \u0026lt;/authenticate\u0026gt; \u0026lt;!-- SCRAM-SHA-1 challenge issued by the server. Base64 of: \u0026#39;r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6a09117a6-ac50-4f2f-93f1-93799c2bddf6,s=QSXCR+Q6sek8bf92,i=4096\u0026#39; --\u0026gt; \u0026lt;challenge xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; cj0xMkM0Q0Q1Qy1FMzhFLTRBOTgtOEY2RC0xNUMzOEY1MUNDQzZhMDkxMTdhNi1hYzUwLTRmMmYtOTNmMS05Mzc5OWMyYmRkZjYscz1RU1hDUitRNnNlazhiZjkyLGk9NDA5Ng== \u0026lt;/challenge\u0026gt; \u0026lt;!-- The client responds with the base64 encoded client-final-message (password: \u0026#39;pencil\u0026#39;). Base64 of: \u0026#39;c=cD10bHMtZXhwb3J0ZXIsLMcoQvOdBDePd4OswlmAWV3dg1a1Wh1tYPTBwVid10VU,r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6a09117a6-ac50-4f2f-93f1-93799c2bddf6,p=icrRuoQBB0htw5+K/6RNEDJ0Q4Y=\u0026#39; The c-attribute contains the GS2-header and channel-binding data blob (32 bytes). --\u0026gt; \u0026lt;response xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; Yz1jRDEwYkhNdFpYaHdiM0owWlhJc0xNY29Rdk9kQkRlUGQ0T3N3bG1BV1YzZGcxYTFXaDF0WVBUQndWaWQxMFZVLHI9MTJDNENENUMtRTM4RS00QTk4LThGNkQtMTVDMzhGNTFDQ0M2YTA5MTE3YTYtYWM1MC00ZjJmLTkzZjEtOTM3OTljMmJkZGY2LHA9aWNyUnVvUUJCMGh0dzUrSy82Uk5FREowUTRZPQ== \u0026lt;/response\u0026gt; \u0026lt;!-- This completes, so the Server sends a success containing the base64 encoded server signature. A SASL2 success always includes the authorization identifier. --\u0026gt; \u0026lt;success xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; \u0026lt;authorization-identifier\u0026gt;user@example.org\u0026lt;/authorization-identifier\u0026gt; \u0026lt;!-- Base64 of: \u0026#39;v=Ax+ZEP5hf90z8+KnakwspK9mEhk=\u0026#39; --\u0026gt; \u0026lt;additional-data\u0026gt; dj1BeCtaRVA1aGY5MHo4K0tuYWt3c3BLOW1FaGs9 \u0026lt;/additional-data\u0026gt; \u0026lt;/success\u0026gt; Restoring protocol agility for SASL methods part #2 Activating a new SASL (SCRAM) method and saving new hashes for these methods for already known users on the server is a bit trickier. To solve this, the server offers new SASL mechanisms indicating that he allows for hash upgrades, if he doesn\u0026rsquo;t have all required hashes in its database yet. The ordering of these new upgrade mechanisms should use a stable sorting algorithm. First sorting by perceived strength of the algorithm updated to, then by the percieved strength of the algorithm used for authentication (e.g. use the highest strength for authentication and upgrade to the highest strength possible with this authentication).\nFor reference, the SCRAM flow as stated in RFC 5802 section 3 is as follows, with HMAC() and HASH() corresponding to the hash method used to authenticate (e.g. SHA-256 for SCRAM-SHA-256):\nSaltedPassword := Hi(Normalize(password), salt, i) ClientKey := HMAC(SaltedPassword, \u0026#34;Client Key\u0026#34;) StoredKey := H(ClientKey) AuthMessage := client-first-message-bare + \u0026#34;,\u0026#34; + server-first-message + \u0026#34;,\u0026#34; + client-final-message-without-proof ClientSignature := HMAC(StoredKey, AuthMessage) ClientProof := ClientKey XOR ClientSignature ServerKey := HMAC(SaltedPassword, \u0026#34;Server Key\u0026#34;) ServerSignature := HMAC(ServerKey, AuthMessage) The SaltedPassword is the hash saved in the database on the server alongside the salt. Using additional SASL2 tasks we can now require the client to perform an additional task which consists of sending the SaltedPassword for the hash algorithm to upgrade to. The server just provides the required salt (that must be a new random value not equal to the one used for the old hash) and iteration count. By providing the salted hash after the successful completion of our SCRAM authentication, server and client can be sure to talk to the right one and when channel-binding is used, both can be sure no MITM is involved that could intercept the new SaltedPassword. I strongly suggest to only support password upgrades if channel-binding is used.\nAn example protocol flow using a modified SASL2 might look as follows (resembling more or less the SCRAM flow used in part #1 above and adding a second task for the desired hash upgrade):\n\u0026lt;!-- Server sends stream features indicating support for SASL2. --\u0026gt; \u0026lt;stream:features\u0026gt; \u0026lt;authentication xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;/\u0026gt; \u0026lt;/stream:features\u0026gt; \u0026lt;!-- Client intiates authentication by sending the base64 encoded username it wishes to authenticate for. --\u0026gt; \u0026lt;request xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; \u0026lt;user\u0026gt;dXNlcg==\u0026lt;/user\u0026gt; \u0026lt;/request\u0026gt; \u0026lt;!-- Server sends the list of supported mechanisms for this user. The sorted list will be \u0026#39;SCRAM-SHA-1_TLS-EXPORTER\u0026lt;SCRAM-SHA-256_TLS-EXPORTER\u0026lt;UPGRADE-SCRAM-SHA-256_SCRAM-SHA-1\u0026lt;UPGRADE-SCRAM-SHA-256_SCRAM-SHA-1_TLS-EXPORTER\u0026#39;, the corresponding base64 encoded SHA-1 hash (SHA-1 will be used because negotiated below) is: \u0026#39;nKFUXQ7h9IL3eo17pKygmacnEsk=\u0026#39; --\u0026gt; \u0026lt;mechanisms xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; \u0026lt;mechanism\u0026gt;SCRAM-SHA-1\u0026lt;/mechanism\u0026gt; \u0026lt;mechanism\u0026gt;SCRAM-SHA-1_TLS-EXPORTER\u0026lt;/mechanism\u0026gt; \u0026lt;mechanism\u0026gt;UPGRADE-SCRAM-SHA-256_SCRAM-SHA-1\u0026lt;/mechanism\u0026gt; \u0026lt;mechanism\u0026gt;UPGRADE-SCRAM-SHA-256_SCRAM-SHA-1_TLS-EXPORTER\u0026lt;/mechanism\u0026gt; \u0026lt;/mechanisms\u0026gt; \u0026lt;!-- Client sends the selected mechanism alogside the initial-response data. --\u0026gt; \u0026lt;authenticate xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39; mechanism=\u0026#39;SCRAM-SHA-1_TLS-EXPORTER\u0026#39;\u0026gt; \u0026lt;!-- Base64 of: \u0026#39;p=tls-exporter,,n=user,r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6,d=nKFUXQ7h9IL3eo17pKygmacnEsk=\u0026#39; --\u0026gt; \u0026lt;initial-response\u0026gt;cD10bHMtZXhwb3J0ZXIsLG49dXNlcixyPTEyQzRDRDVDLUUzOEUtNEE5OC04RjZELTE1QzM4RjUxQ0NDNixkPVUzdlpBTnhYYmwxcE1PTUJBRlBuVGI1WVhXaz0=\u0026lt;/initial-response\u0026gt; \u0026lt;/authenticate\u0026gt; \u0026lt;!-- SCRAM-SHA-1 challenge issued by the server. Base64 of: \u0026#39;r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6a09117a6-ac50-4f2f-93f1-93799c2bddf6,s=QSXCR+Q6sek8bf92,i=4096\u0026#39; --\u0026gt; \u0026lt;challenge xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; cj0xMkM0Q0Q1Qy1FMzhFLTRBOTgtOEY2RC0xNUMzOEY1MUNDQzZhMDkxMTdhNi1hYzUwLTRmMmYtOTNmMS05Mzc5OWMyYmRkZjYscz1RU1hDUitRNnNlazhiZjkyLGk9NDA5Ng== \u0026lt;/challenge\u0026gt; \u0026lt;!-- The client responds with the base64 encoded client-final-message (password: \u0026#39;pencil\u0026#39;). Base64 of: \u0026#39;c=cD10bHMtZXhwb3J0ZXIsLMcoQvOdBDePd4OswlmAWV3dg1a1Wh1tYPTBwVid10VU,r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6a09117a6-ac50-4f2f-93f1-93799c2bddf6,p=UApo7xo6Pa9J+Vaejfz/dG7BomU=\u0026#39; The c-attribute contains the GS2-header and channel-binding data blob (32 bytes). --\u0026gt; \u0026lt;response xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; Yz1jRDEwYkhNdFpYaHdiM0owWlhJc0xNY29Rdk9kQkRlUGQ0T3N3bG1BV1YzZGcxYTFXaDF0WVBUQndWaWQxMFZVLHI9MTJDNENENUMtRTM4RS00QTk4LThGNkQtMTVDMzhGNTFDQ0M2YTA5MTE3YTYtYWM1MC00ZjJmLTkzZjEtOTM3OTljMmJkZGY2LHA9VUFwbzd4bzZQYTlKK1ZhZWpmei9kRzdCb21VPQ== \u0026lt;/response\u0026gt; \u0026lt;!-- This completes, so the Server sends a continue containing the base64 encoded server signature and the upgrade task to perform. --\u0026gt; \u0026lt;continue xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; \u0026lt;authorization-identifier\u0026gt;user@example.org\u0026lt;/authorization-identifier\u0026gt; \u0026lt;!-- Base64 of: \u0026#39;msVHs/BzIOHDqXeVH7EmmDu9id8=\u0026#39; --\u0026gt; \u0026lt;additional-data\u0026gt; dj1tc1ZIcy9CeklPSERxWGVWSDdFbW1EdTlpZDg9 \u0026lt;/additional-data\u0026gt; \u0026lt;tasks\u0026gt; \u0026lt;task\u0026gt;UPGRADE-SCRAM-SHA-256\u0026lt;/task\u0026gt; \u0026lt;/tasks\u0026gt; \u0026lt;/continue\u0026gt; \u0026lt;!-- The client provides the SaltedPassword hash for SCRAM-SHA-256 --\u0026gt; \u0026lt;next xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39; task=\u0026#39;UPGRADE-SCRAM-SHA-256\u0026#39;/\u0026gt; \u0026lt;!-- The server sends the required salt and iteration count encoded as base64 encoded SASL attributes. Base64 of: \u0026#39;s=A_SXCRXQ6sek8bf_Z,i=4096\u0026#39; --\u0026gt; \u0026lt;challenge xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; cz1BX1NYQ1JYUTZzZWs4YmZfWixpPTQwOTY= \u0026lt;/challenge\u0026gt; \u0026lt;!-- The client responds with the base64 encoded SaltedPassword. --\u0026gt; \u0026lt;response xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; BzOnw3Pc5H4bOLlPZ/8JAy6wnTpH05aH21KW2+Xfpaw= \u0026lt;/response\u0026gt; \u0026lt;!-- Finally, the server sends a success after adding the salted SHA-256 hash to it\u0026#39;s database. A SASL2 success always includes the authorization identifier. --\u0026gt; \u0026lt;success xmlns=\u0026#39;urn:xmpp:sasl:1\u0026#39;\u0026gt; \u0026lt;authorization-identifier\u0026gt;user@example.org\u0026lt;/authorization-identifier\u0026gt; \u0026lt;/success\u0026gt; If the server needs to upgrade to multiple new SCRAM algorithms, he can do so one at a time on every new authentication. This is no \u0026ldquo;do everything once\u0026rdquo; anyways, because not every client might support every upgrade possible.\nConclusion To conclude this, we now identified several improvements to regain the properties listed in the beginning. These improvements can mainly be achieved by updating the SASL2 XEP (XEP-0388: Extensible SASL Profile). The downgrade prevention (the additional SCRAM attribute d) should possibly be published as RFC, but a XEP could suffice, too.\nFeel free to comment on anything in here. I\u0026rsquo;m always open to feedback and improvements. Just contact me at thilo@monal-im.org.\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00004-sasl/","summary":"SASL (Simple Authentication and Security Layer) as used in XMPP is broken. In this blog post I\u0026rsquo;ll try to explain why and propose some fixes.\nUpdate (2023-04-21): Since I originally wrote this blog post, I\u0026rsquo;ve had the ability to discuss several of my ideas with Dave (the original author of XEP-0388 dubbed SASL2), MattJ (one of the authors of the prosody xmpp server) and others. Most, if not all, of my issues are now addressed in a bunch of updates to existing XEPs as well as new XEPs:","title":"On the state of SASL in XMPP"},{"content":"We are pleased to announce that we got funding by the EU’s NGI Assure via the NLnet Foundation to work on some important features in Monal.\nIn short this consists of the following tasks (in no special order).\n1. Implement more privacy-friendly push server The current push appserver (https://github.com/tmolitor-stud-tu/mod_push_appserver) saves more data than strictly needed to perform its task, let’s change that. On top of that, a possible HA-setup and load balancing should be strived for.\n2. Implement basic Audio calls using WebRTC Include WebRTC library into our codebase and wire it up to allow for simple audio calls not involving XMPP (maybe send SDP data through a Monal specific non-standardized XMPP stanza to make this work without hardcoded ip and port).\nThis is to test Audio Calls in the field first before wiring them up using correct XMPP XEPs.\n3. Implement all XEPs needed for Audio Calls To make Audio Calls for XMPP work, we need proper XMPP integration. This wires up the stuff implemented in (2) into the XMPP layer by implementing the proper XEPs listed below. This will add support for 1:1 audio calls to Conversations, Dino and many more XMPP clients.\n4. Implement Video calls using WebRTC On top of the work done in (2) and (3) we want to implement Video Call support as well. This will add support for 1:1 video calls to Conversations, Dino, and more.\n5. Security quickscan We want a security quickscan performed by Radically Open Security and implement mitigations for problems found by them.\n6. Implement MUC UI management (add/remove/promote users etc.) While Monal supports MUCs (multi user chats) in its flavours “channel” and “group”, the app is still lacking proper support for creating and managing group-type MUCs. We will implement that missing piece in this task.\n7. Port addContact UI to SwiftUI The existing UI to add a contact or show pending contact requests is not user-friendly. We will therefore port it to SwiftUI. Once contacts can be added using the new UI, a UI for creating MUCs will be added. Monal will then support the creation of new private MUCs. Additionally, the existing functionality to scan contact QR-Codes and open contact links from other apps / iOS camera will be refactored. After the refactoring the user can preview the action and select an appropriate account before adding the contact.\n8. Add SASL mechanism upgrade capability to XEP-0388 XEP-0388 (“Extensible SASL Profile”) modernizes the old XMPP SASL profile defined in RFC 6120 and reduces round-trips. But neither the old SASL profile nor the new one (dubbed SASL2) solve the problem of SASL mechanism upgrades. A server that saves the hashed password for SCRAM-SHA-1 authentication has no way of upgrading to SCRAM-SHA-256. It does not know the cleartext password to calculate the hash to store itself and no way to ask the client for it. We want to take the opportunity and update the SASL2 XEP before it gets widely deployed to provide a way for a smooth upgrade path that allows the servers to store multiple hashes and get new hashes provided by clients that support the new algorithm without the need of ever knowing the cleartext password.\n9. Implement SASL2 in Monal (including SCRAM SHA1, SHA256 and SHA512) Implement the updated SASL2 XEP and the accompanying XEP-0440 (“SASL Channel-Binding Type Capability”) in Monal which serves as foundation for the implementation of XEP-0397 (“Instant Stream Resumption”).\n10. Write new XEP for downgrade protection of channel-binding types and SASL mechanisms and implement it A Man-In-The-Middle capable of impersonating the XMPP server on the TLS level can use SASL Mechanism Stripping and/or strip channel-binding types to downgrade the security. Adding an optional SCRAM attribute containing the hash of all server-advertised SASL mechanisms and channel-binding types as seen by the client will enable the server to check if any downgrade took place and to abort the authentication, if so. Because the SCRAM attribute will be part of the mutual authentication between client and server, a MITM will not be able to forge it.\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00003-nlnet-funding/","summary":"We are pleased to announce that we got funding by the EU’s NGI Assure via the NLnet Foundation to work on some important features in Monal.\nIn short this consists of the following tasks (in no special order).\n1. Implement more privacy-friendly push server The current push appserver (https://github.com/tmolitor-stud-tu/mod_push_appserver) saves more data than strictly needed to perform its task, let’s change that. On top of that, a possible HA-setup and load balancing should be strived for.","title":"NLNet Funding"},{"content":"We recently started to migrate the App from Anu Pokharel‘s Apple account to Thilo Molitor‘s Apple account.\nAs part of this transition we also deployed some new push servers to not let an old retired developer pay for the infrastructure needed for Monal.\nComing along with this transition from the old developer team to the new one is our new clean website at https://monal-im.org/. From now on, the old blog at https://monal.im/ will not be used for Monal anymore.\nMany thanks to all users, contributors and followers so far.\nSpecial thanks goes to Anu. Without him and his passion, Monal would not have been possible. He developed and maintained Monal for more than 10 years, always ensuring compatibility with the latest iOS releases.\nWhen I (Thilo) gradually took over development, I was able to build upon an app with a decent codebase rather than writing my own app from scratch. That made it possible to improve Monal further while already being used by thousands of people. I can not stress enough how thankful I was and still am for all the work Anu put into the development of Monal. Thank you, Anu, for your wonderful work towards a modern XMPP client for iOS and macOS!\nThilo, Friedrich, Anu\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00002-project-moved/","summary":"We recently started to migrate the App from Anu Pokharel‘s Apple account to Thilo Molitor‘s Apple account.\nAs part of this transition we also deployed some new push servers to not let an old retired developer pay for the infrastructure needed for Monal.\nComing along with this transition from the old developer team to the new one is our new clean website at https://monal-im.org/. From now on, the old blog at https://monal.","title":"Monal IM - project moved"},{"content":"Implemented XEPs XEP Status Since . . . . xep-0004 complete 4.9 xep-0030 complete 4.6 xep-0045 partial 5.0 xep-0048 complete 5.0 xep-0054 Implemented only for MUC profiles complete 5.0 xep-0059 complete 4.8 xep-0060 Used mainly for Pep partial 4.9 xep-0066 Used to mark XEP-0363 filetransfers only partial 4.9 xep-0077 partial 4.7 xep-0084 complete 4.9 xep-0085 Only typing notifications, use XEP-0319 to publish interactions partial 4.7 xep-0092 complete 5.0 xep-0115 complete 4.7 xep-0153 XEP-0153: vCard-Based Avatars (implemented only for MUC profiles) partial 5.0 xep-0162 partial 5.4 xep-0163 complete 4.9 xep-0167 complete 6.0 xep-0176 complete 6.0 xep-0172 complete 4.9 xep-0184 complete 4.7 xep-0191 complete 5.0 xep-0198 complete 4.6 xep-0199 complete 4.7 xep-0215 complete 6.0 xep-0223 XEP-0223: Persistent Storage of Private Data via PubSub complete 4.9 xep-0237 complete 4.6 xep-0245 complete 4.9 xep-0249 XEP-0249: Direct MUC Invitations complete 5.0 xep-0280 complete 4.5 xep-0286 complete 4.7 xep-0293 complete 6.0 xep-0294 complete 6.0 xep-0305 complete 5.1.1 xep-0308 complete 4.8 xep-0313 complete 4.8 xep-0319 complete 4.7 xep-0320 complete 6.0 xep-0333 complete 4.8 xep-0338 complete 6.0 xep-0339 complete 6.0 xep-0352 complete 4.7 xep-0353 complete 6.0 xep-0357 complete 4.8 xep-0359 complete 4.8 xep-0363 complete 4.9 xep-0368 complete 4.6 xep-0379 No automatic approval if server does not support subscription pre-approval; No checking of tokens, if server does not do so (XEP-0401) partial 4.9 xep-0380 complete 5.1 xep-0384 complete 4.8 xep-0388 complete 6.0 xep-0392 complete 5.1 xep-0398 Used for MUC avatars complete 6.0 xep-0401 complete 6.0 xep-0402 complete 5.4 xep-0410 complete 5.0 xep-0423 Check this XEP to see what\u0026#39;s missing partial xep-0424 complete 6.3 xep-0425 complete 6.3 xep-0440 complete 6.0 xep-0441 Only to automatically turn on archiving if possible (setting: always) complete 4.8 xep-0445 complete 5.2 xep-0454 No support for embedded thumbnails partial 5.0 xep-0474 complete 6.0 xep-0480 complete 6.0 xep-0486 complete 5.0 xep-0490 complete 6.3 Planned XEPs XEP Status xep-0158 planned xep-0374 planned xep-0386 XEP-0386: Bind 2.0 planned xep-0420 planned xep-0158 planned ","permalink":"https://monal-im.github.io/monal-im.org/site/supportedxeps/","summary":"Implemented XEPs XEP Status Since . . . . xep-0004 complete 4.9 xep-0030 complete 4.6 xep-0045 partial 5.0 xep-0048 complete 5.0 xep-0054 Implemented only for MUC profiles complete 5.0 xep-0059 complete 4.8 xep-0060 Used mainly for Pep partial 4.9 xep-0066 Used to mark XEP-0363 filetransfers only partial 4.9 xep-0077 partial 4.7 xep-0084 complete 4.9 xep-0085 Only typing notifications, use XEP-0319 to publish interactions partial 4.7 xep-0092 complete 5.0 xep-0115 complete 4.","title":"Supported XEPs"},{"content":" Monal Support Channel (XMPP MUC): monal@chat.yax.im Github Tickets: https://github.com/monal-im/Monal/issues Email: info[at]monal[minus]im[dot]org. Donate Monal is developed by volunteers and community collaboration. The work which has been done is usually not paid, and the developers ask for donations to keep up service costs and development in the future! Please consider giving a little back for the hard work which has been conducted. Currently, there are three ways for financial support of the Monal development:\nDonate via GitHub Sponsors Donate via Libera Pay EU citizens can donate via SEPA, too. IBAN: DE66 5007 0371 0856 0419 01 Here you can read about further support of the development!\nFind general information in the Monal Wiki.\nTranslations We host and manage translations via Weblate. Feel free to translate Monal to your language!\nReporting a Vulnerability It is highly appreciated reporting a vulnerability to the Monal developers. We ask you for disclosure until it has been fixed. This prevents abuse and exploitation in the current published releases. Please report issues directly to info[at]monal[minus]im[dot]org.\nPlease try to report\nin detail what you are concerned about if applicable, how to reproduce your contact details, if the sending email is not enough. That way we can ask questions back to you. You are also invited to make a recommendation on how to fix a potential security vulnerability.\nOnce a vulnerability has been announced and indicated we try our very best to provide a fix as soon as possible, at its best within days. However, dependent on the potential issue it can take longer if many code sections need to be changed.\nPlease be reminded that this is a non-commercial software project.\nThank you for considering reporting a security vulnerability. This improves the quality of the app significantly.\n","permalink":"https://monal-im.github.io/monal-im.org/site/support/","summary":"Monal Support Channel (XMPP MUC): monal@chat.yax.im Github Tickets: https://github.com/monal-im/Monal/issues Email: info[at]monal[minus]im[dot]org. Donate Monal is developed by volunteers and community collaboration. The work which has been done is usually not paid, and the developers ask for donations to keep up service costs and development in the future! Please consider giving a little back for the hard work which has been conducted. Currently, there are three ways for financial support of the Monal development:","title":"Support"},{"content":" iOS macOS macOS (homebrew) Stable App Store App Store brew install --cask monal Beta Testflight Invitation Testflight Invitation brew install --cask monal@beta Alpha upon request to info@monal-im.org\nThen download from our alpha download site brew tap monal-im/homebrew-monal-alpha\nbrew install --cask monal-alpha Features Monal currently covers the following chat features:\nDecentralised and federated chat standard XMPP Private and group messaging Privacy-respecting push notifications Encrypted private and group chats (state-of-the-art encryption (OMEMO) Message history Free selection of your XMPP account provider Voice messaging Message archiving Upload of files, videos and images (HTTP Upload) Audio and Video calls Many settings and a design to offer privacy settings in the app to the need of the user A detailed and technical listing of your supported features (so called XMPP Extensions) can be found in our DOAP file. Planned features User-interface overhaul Implemented XEPs XEP Status Since . . . . xep-0004 complete 4.9 xep-0030 complete 4.6 xep-0045 partial 5.0 xep-0048 complete 5.0 xep-0054 Implemented only for MUC profiles complete 5.0 xep-0059 complete 4.8 xep-0060 Used mainly for Pep partial 4.9 xep-0066 Used to mark XEP-0363 filetransfers only partial 4.9 xep-0077 partial 4.7 xep-0084 complete 4.9 xep-0085 Only typing notifications, use XEP-0319 to publish interactions partial 4.7 xep-0092 complete 5.0 xep-0115 complete 4.7 xep-0153 XEP-0153: vCard-Based Avatars (implemented only for MUC profiles) partial 5.0 xep-0162 partial 5.4 xep-0163 complete 4.9 xep-0167 complete 6.0 xep-0176 complete 6.0 xep-0172 complete 4.9 xep-0184 complete 4.7 xep-0191 complete 5.0 xep-0198 complete 4.6 xep-0199 complete 4.7 xep-0215 complete 6.0 xep-0223 XEP-0223: Persistent Storage of Private Data via PubSub complete 4.9 xep-0237 complete 4.6 xep-0245 complete 4.9 xep-0249 XEP-0249: Direct MUC Invitations complete 5.0 xep-0280 complete 4.5 xep-0286 complete 4.7 xep-0293 complete 6.0 xep-0294 complete 6.0 xep-0305 complete 5.1.1 xep-0308 complete 4.8 xep-0313 complete 4.8 xep-0319 complete 4.7 xep-0320 complete 6.0 xep-0333 complete 4.8 xep-0338 complete 6.0 xep-0339 complete 6.0 xep-0352 complete 4.7 xep-0353 complete 6.0 xep-0357 complete 4.8 xep-0359 complete 4.8 xep-0363 complete 4.9 xep-0368 complete 4.6 xep-0379 No automatic approval if server does not support subscription pre-approval; No checking of tokens, if server does not do so (XEP-0401) partial 4.9 xep-0380 complete 5.1 xep-0384 complete 4.8 xep-0388 complete 6.0 xep-0392 complete 5.1 xep-0398 Used for MUC avatars complete 6.0 xep-0401 complete 6.0 xep-0402 complete 5.4 xep-0410 complete 5.0 xep-0423 Check this XEP to see what\u0026#39;s missing partial xep-0424 complete 6.3 xep-0425 complete 6.3 xep-0440 complete 6.0 xep-0441 Only to automatically turn on archiving if possible (setting: always) complete 4.8 xep-0445 complete 5.2 xep-0454 No support for embedded thumbnails partial 5.0 xep-0474 complete 6.0 xep-0480 complete 6.0 xep-0486 complete 5.0 xep-0490 complete 6.3 Planned XEPs XEP Status xep-0158 planned xep-0374 planned xep-0386 XEP-0386: Bind 2.0 planned xep-0420 planned xep-0158 planned ","permalink":"https://monal-im.github.io/monal-im.org/site/install/","summary":"iOS macOS macOS (homebrew) Stable App Store App Store brew install --cask monal Beta Testflight Invitation Testflight Invitation brew install --cask monal@beta Alpha upon request to info@monal-im.org\nThen download from our alpha download site brew tap monal-im/homebrew-monal-alpha\nbrew install --cask monal-alpha Features Monal currently covers the following chat features:\nDecentralised and federated chat standard XMPP Private and group messaging Privacy-respecting push notifications Encrypted private and group chats (state-of-the-art encryption (OMEMO) Message history Free selection of your XMPP account provider Voice messaging Message archiving Upload of files, videos and images (HTTP Upload) Audio and Video calls Many settings and a design to offer privacy settings in the app to the need of the user A detailed and technical listing of your supported features (so called XMPP Extensions) can be found in our DOAP file.","title":"Install"},{"content":" Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies\nReleases Privacy Policy 6.0 and newer Privacy Policy Rev 003 5.2.0 up to 5.4.x Privacy Policy Rev 002 before 5.2.0 Privacy Policy Rev 001 ","permalink":"https://monal-im.github.io/monal-im.org/site/privacy/","summary":"Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies","title":"Privacy"},{"content":" Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies\nReleases Privacy Policy 6.0 and newer Privacy Policy Rev 003 5.2.0 up to 5.4.x Privacy Policy Rev 002 before 5.2.0 Privacy Policy Rev 001 Privacy Monal App \u0026lt; 5.2.0 Monal for iOS and macOS will register for APNS push notifications via a server to server (s2s) connection from your XMPP server to our push server. Your XMPP JID alongside with a push identifier and secret token from Apple, that is only valid for this app, will be saved and logged in the push-server logs. We do not intend to track you. All server logs are purged every two weeks. Our logs allow us to see the following details:\nYour JID (including your server’s hostname) Time when you register for push notifications Your apple push node and push token that was generated for Monal by Apple Time when your XMPP server triggered a push notification to your Monal device To fulfill its duty, our push server has to hold some information associated with an Apple push token, until Apple marks the token a deleted, which usually means you have uninstalled the app (Info: Apple confirms if a token is still valid on every push). In detail these information consists of:\nThe Apple push token The timestamp of the last push error The timestamp of the last successful push The timestamp of the registration of your device with Monal’s push-server The timestamp when the registration was renewed A random UUID identifying your device A random secret used by your XMPP server to authenticate a push Push server locations Name Hoster Location Notice ios13push.monal.im AWS US Provided by Anurodh Pokharel\nIPv4 only push.monal.im AWS US Provided by Anurodh Pokharel\nIPv4 only\niOS 12 only Crash reports and app usage Monal does track crashes and usage data anonymously using the tools provided by Apple. This is opt-in only and controlled by iOS and macOS global settings. If a user decides not to send any data to developers, no crash logs are sent to Monal developers.\nLogs Your local device will contain a log file with all sent and received raw XMPP messages as well as debug logs. It does contain sensitive personal data! This file will never be transferred to us, except if you explicitly (manually) send it to us (e.g. via mail).\nGDPR Subject Access Requests (SAR) European GDPR allows users to request a copy of all data retained about them. Please send GDPR requests to info@monal-im.org. As by GDPR we need to validate your JID before answering to your inquiry. Therefore, we will provide you a JID you must send a confirmation to, before we can answer your request and send you all retained data related to your JID.\n","permalink":"https://monal-im.github.io/monal-im.org/site/privacyarchive/monal_app_rev_001/","summary":"Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies","title":"Privacy Monal App \u003c 5.2.0"},{"content":" Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies\nReleases Privacy Policy 6.0 and newer Privacy Policy Rev 003 5.2.0 up to 5.4.x Privacy Policy Rev 002 before 5.2.0 Privacy Policy Rev 001 Privacy Monal App 5.2.0 - 5.4.x App Resources are very limited on iOS and macOS. Monal for example can only run a limited time in the background after a user either locked the screen or switched the app. Hence, apps can not simply keep a connection to your xmpp server open 24/7 to inform you about new messages. To overcome these limitations your XMPP-Server can can request our push server to send push messages to Apple. With these push messages we can request Apple to wake up the app on your phone. Once it is woken up it has about 30 seconds to connect to your XMPP server, fetch all new messages and show a push notification for these new messages.\nHow push works Every time that Monal logins at your XMPP servers, it requests your server to inform us once your received an XMPP message while Monal was closed. We therefore requests a Monal specific push token from Apple. Using this Monal specific push token our push server can send push messages via Apples push system to wake up the app on your device.\nOnce push messages are enabled for your Monal instance on your XMPP servers, your XMPP servers will open a encrypted server to server (s2s) connection to one of our push servers. Using this s2s connection your XMPP servers will then request our push servers to wake up Monal every time that new messages should be processed. To wake up your instance your XMPP servers send us:\nyour unique Monal specific push token that was generated by Apple the domain of the XMPP server that you are using. Push We never see your messages. We do not know who you are chatting with. We could only ever track what XMPP domains a push token is/was using. We can not identify a user. Push-Servers We provide two independent push server regions at the moment: Europe and US. By default, each device will choose our Europe based push region unless the device local is set to the US.\nHow to change the push region Open Monal Open up the settings menu in the upper left corner (gearwheel) Open the Notifications menu Scroll down Select a region Push server regions If you are an XMPP server administrator, and you restricted s2s connections, please allow s2s to all our regions.\nRegion Hostname Notice Europe eu.prod.push.monal-im.org US us.prod.push.monal-im.org Push server locations Name Region Hoster Location Notice s1.eu.prod.push.monal-im.org Europe Hetzner Finland s2.eu.prod.push.monal-im.org Europe PHP-Friends Germany s1.us.prod.push.monal-im.org US Fosshost US IPv4 only s2.us.prod.push.monal-im.org US Fosshost US Crash reports and app usage Monal does track crashes and usage data anonymously using the tools provided by Apple. This is opt-in only and controlled by iOS and macOS global settings. If a user decides not to send any data to developers, no crash logs are sent to Monal developers.\nLogs Your local device will contain a log file with all sent and received raw XMPP messages as well as debug logs. It does contain sensitive personal data! This file will never be transferred to us, except if you explicitly (manually) send it to us (e.g. via mail).\nGDPR Subject Access Requests (SAR) European GDPR allows users to request a copy of all data retained about them. Starting with Monal 5.2.0 we no longer see your JIDs (username@domain.tld) in our push servers. We therefore are not able to send you retained data related to your JID. We furthermore are unable to provide your retained data related to your unique push token because we have no way to verify that Apple issued you a provided token. If you have questions regarding GDPR, please send us a mail to info@monal-im.org.\n","permalink":"https://monal-im.github.io/monal-im.org/site/privacyarchive/monal_app_rev_002/","summary":"Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies","title":"Privacy Monal App 5.2.0 - 5.4.x"},{"content":" Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies\nReleases Privacy Policy 6.0 and newer Privacy Policy Rev 003 5.2.0 up to 5.4.x Privacy Policy Rev 002 before 5.2.0 Privacy Policy Rev 001 Website Privacy A user’s IP address will be logged in the HTTP server logs. All server logs are purged every two weeks and there isn’t any way for us to associate this information with any particular individual. Our websites do not use or need any cookies. And of course it doesn\u0026rsquo;t use any third party/external (JS-CSS-Font) dependencies.\n","permalink":"https://monal-im.github.io/monal-im.org/site/privacyarchive/monal_website/","summary":"Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies","title":"Privacy Website"},{"content":" TLDR:\nInfo: Monal will stop support for iOS 12, iOS 13 and macOS Catalina!\nWe are searching for a SwiftUI developer.\nWe need a new simplified website.\nWith better continuous funding, our push servers will move from the US to Europe.\nWe have a new support mail: info@monal-im.org\nTwo years ago we decided to rewrite the Monal app almost entirely and improve it gradually in the process, instead of creating another XMPP Client for iOS and macOS. We successfully managed to transform Monal from an app that had flaws and issues with many functions to a level that promotes a user-friendly experience with working features such as push notification, group chat, and partially end-to-end encryption support (OMEMO). If you are selecting an XMPP client for Apple systems we think that Monal is a great choice nowadays. We have been investing more than a thousand hours and worked hard to overcome all the flaws, the legacy app had. We invite you to give the recent beta a try!\nThe development of Monal has not yet finished though, and many more features are hopefully to come. But due to our time constraints, it sometimes takes a bit longer than we and the community would like. We are at most two developers at the moment using our spare time to maintain Monal and develop new features. As we are developing Monal in our spare time without decent funding, it is sometimes hard to prioritize specific features. Please give this circumstance some credits.\nWhat should Monal look like in the future? To give you a bit of insight knowledge of our plans we tried to summarize the most important tasks.\nInterface (SwiftUI) In the future Monal should be easy to use. Therefore, the interface requires a proper rework and while we are at it, it should be ported to SwiftUI. While we are still improving in designing with SwiftUI, we would be glad if there is a SwiftUI \u0026amp; Open Source enthusiast who would like to help us with this.\nWith this transition we would like to improve the accessibility of the app as well. If you like to support an open source project, and you would like to be part of our SwiftUI journey please contact us.\nTask:\nAdd new MUC creation and management UI Port the chat view Finish contact Details List group chat (MUC) participants Display OMEMO encryption fingerprints for verification Port our settings Port all other remaining views Qualifications:\nGeneral knowledge around SwiftUI (iOS and Catalyst) Interest in improving a (XMPP) chat client Optional, but preferred: Some experience with XMPP (e.g. some weeks, or maybe months of usage of Monal or any other “modern” XMPP client) Optional: Experience in designing inclusive / accessible UI Website We need a modern (simplified) Hugo based website that is easier to understand, similar to Conversations, Dino or Gajim.\nIf you have some spare time, and you are a skilled in creating websites with Hugo please contact us.\nRequirements:\nSimple design nothing too fancy Privacy by design → No analytics, no external CSS, jss, … usage OMEMO Encryption in Group Chat (MUC) We started to integrate OMEMO for group chats (MUC) into our alpha build. The receiving and sending sides are already implemented, but there are a few more steps until we can release it into the beta.\nSwitching to our new Domain monal-im.org In late 2021 we decided that we would like to have a domain with DNSSEC as our current top level domain does not support it. This domain will mainly be used for our push servers and mail servers in the future. From now on you will be able to reach us via info@monal-im.org.\nBuild server Thanks to ~20 generous donors, we were able to buy a new build server that will be used to build our alpha, beta and stable releases. Furthermore, Thilo is now finally able to debug code with a proper debugger connected to his phone.\nRedundant Push Servers We are currently using an AWS US instance for our push server that is not redundant and failed in 2021 more frequently than we liked it to. For that reason we started an internal project to auto-deploy our push server with Ansible and looked into ways for running a redundant push server setup. The first tests look promising so far, but a few more things need to be sorted out before we can switch over to our new setup.\nBefore we can switch to the new push server setup, we need a stable funding each month. We estimate that renting a VM in Germany and one at a different hoster in Finland would cost us between 16€ to 32€ each month. Without a stable funding we might not be able to afford this new setup and our push servers would stay in the US.\nThanks to our generous build server donors, we have a few bucks left that will be used as a ~5 month buffer in case of fluctuant push server funding\nPrivacy improved push servers With our current push implementation our so-called “app servers” see your JID (username + server), a unique but otherwise opaque device id and an opaque token generated by apple, as well as your interaction times (when you register for push notifications, timestamps when your XMPP server triggers a push notification device).\nIf you use multiple accounts on one device, the unique device id is shared across all accounts. We don’t think that this is ideal, as we know all jid’s a user is using.\nIn the future we want to try to reduce our knowledge by hiding your username from our app servers. If our idea works, we would only see that a device is registered on one or more domains and the timestamps that a push message was triggered from each domain that is used.\nAudio and Video Calls Many clients such as Conversations and Dino support audio and video calls, so Monal should be next 🙂\nEnd-of-life: iOS 12, iOS 13 and macOS Catalina will not be supported anymore Our user group on iOS 12, iOS 13 as well as macOS Catalina has decreased in last years while the resources needed to maintain these old platforms increased. We therefore decided to focus on newer iOS versions and drop the old ones. The next stable release will only be supported on iOS 14 and higher and macOS Big Sur and higher. We are still unsure how long we will support iOS 14, as most of the devices also support iOS15.\nDonations and Support Monal is developed by volunteers and community collaboration. The work which has been done is usually not paid, and the developers need to keep up service costs and development in the future! Please consider giving a bit back for the hard work which has been conducted. Currently, there are three ways to financially support the Monal development:\nDonate via GitHub Sponsors Donate via Libera Pay EU citizens can donate via SEPA, too. Just contact Thilo Molitor via mail to info@monal-im.org to get his IBAN. Here you can read about further support of the development! Find general information in the Monal Wiki.\nTranslations We host and manage translations via Weblate.\nMany thanks! Of course, thank you very much to everyone who supported us in the past two years! 🙂\nYou can follow us via Mastodon.\n","permalink":"https://monal-im.github.io/monal-im.org/site/post/00001-monal-development/","summary":"TLDR:\nInfo: Monal will stop support for iOS 12, iOS 13 and macOS Catalina!\nWe are searching for a SwiftUI developer.\nWe need a new simplified website.\nWith better continuous funding, our push servers will move from the US to Europe.\nWe have a new support mail: info@monal-im.org\nTwo years ago we decided to rewrite the Monal app almost entirely and improve it gradually in the process, instead of creating another XMPP Client for iOS and macOS.","title":"Insights Into Monal Development"},{"content":"Monal is an XMPP instant messaging client for macOS and iOS which strives to be the go-to client for these platforms just like the app Conversations IM is for Android. XMPP in general is an open and standardized protocol for real time communication. Anyone can host their own server and communicate freely with each other, just like with email and just like email the used addresses are of the form \u0026ldquo;user@domain.tld\u0026rdquo;. The user can use different apps and services, such as Monal, from a single but also multiple accounts. This serves a decentral and sovereign infrastructure and digital communication on the internet but also offers many potential for innovation. The chat client for iOS and macOS involves implementing various XEP standards (XMPP extension protocols, adding modern functionality to the XMPP-core and XMPP-im RFCs, see XMPP Extensions).\nDesigned for iOS and Mac Things look and work the way you expect. iOS, iPadOS or macOS, there is a version of Monal for you.\nMonal is developed under an open-source BSD license that serves the user, while not selling or tracking information for external parties (nor for anyone else). This app exists because it is key to ensure usability on all platforms and within the XMPP network with all its positives aspects when it comes to decentral communication and infrastructure.\nFind the development on GitHub!\n","permalink":"https://monal-im.github.io/monal-im.org/site/home/","summary":"Monal is an XMPP instant messaging client for macOS and iOS which strives to be the go-to client for these platforms just like the app Conversations IM is for Android. XMPP in general is an open and standardized protocol for real time communication. Anyone can host their own server and communicate freely with each other, just like with email and just like email the used addresses are of the form \u0026ldquo;user@domain.","title":"Monal-IM. Privacy like it's 1999"},{"content":"Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies\nReleases Privacy Policy 6.0 and newer Privacy Policy Rev 003 5.2.0 up to 5.4.x Privacy Policy Rev 002 before 5.2.0 Privacy Policy Rev 001 ","permalink":"https://monal-im.github.io/monal-im.org/site/privacyarchive/privacyheader/","summary":"Monal Website\nYou can find our latest privacy policy for our website here: Website Privacy Policy\nMonal App\nOur privacy policy may differ between app versions. Before reading our privacy policy for our App you first need to find out the Monal version that you are using. How to find out your Monal version\nOpen Monal Open up the settings menu in the upper left corner (gearwheel) Scroll down to the last entry \u0026ldquo;version\u0026rdquo; Monal App Privacy Policies","title":""},{"content":"Imprint Thilo Molitor Vogelsbergstr. 18 68642 Bürstadt Germany\neMail: info[at]monal[minus]im[dot]org\nAbout Monal originates in 2002 as fork of the SworIM app. Until 2019 it has been developed by Anu Pokharel. Since then Thilo Molitor took over the development and joined in 2020 with Friedrich Altheide. From initial rewrite of code in the backend the entire app has been upgraded with a modern XMPP engine, new features and future-proof setup. Monal challenges to be the go-to XMPP chat-app for the iOS and macOS platform.\nMonal Team Thilo Molitor - About me on wiki.xmpp.org\nFriedrich Altheide\n","permalink":"https://monal-im.github.io/monal-im.org/site/about/","summary":"Imprint Thilo Molitor Vogelsbergstr. 18 68642 Bürstadt Germany\neMail: info[at]monal[minus]im[dot]org\nAbout Monal originates in 2002 as fork of the SworIM app. Until 2019 it has been developed by Anu Pokharel. Since then Thilo Molitor took over the development and joined in 2020 with Friedrich Altheide. From initial rewrite of code in the backend the entire app has been upgraded with a modern XMPP engine, new features and future-proof setup. Monal challenges to be the go-to XMPP chat-app for the iOS and macOS platform.","title":"About"},{"content":"Talks and other documents Molitor, Thilo; Altheide, Friedrich. Modern XMPP - A story based on Monal Berlin XMPP Meetup, 13th April 2022, Recording, Slides Molitor, Thilo; Altheide, Friedrich. Privacy friendly push Berlin XMPP Meetup, 13th April 2022, Recording, Slides (starting after page 29) Molitor, Thilo. XMPP Push notifications on iOS Molitor, Thilo. Monal development recap 2019 - 2021 and open discussion Berlin XMPP Meetup, 13th October 2021, Recording XEP publications XEP-0353: Jingle Message Initiation Authors: Philipp Hancke, Peter Saint-Andre, Thilo Molitor This specification provides a way for the initiator of a Jingle session to propose sending an invitation in an XMPP message stanza, thus taking advantage of message delivery semantics instead of sending IQ stanzas to all of the responder\u0026rsquo;s online resources or choosing a particular online resource.\nXEP-0474: SASL SCRAM Downgrade Protection Authors: Thilo Molitor This specification provides a way to secure the SASL and SASL2 handshakes against method and channel-binding downgrades.\nXEP-0388: Extensible SASL Profile Authors: Dave Cridland, Thilo Molitor, Matthew Wild This document describes a replacement for the SASL profile documented in RFC 6120 which allows for greater extensibility.\nXEP-0480: SASL Upgrade Tasks Authors: Thilo Molitor This specification provides a way to upgrade to newer SASL mechanisms using SASL2 tasks.\n","permalink":"https://monal-im.github.io/monal-im.org/site/publications/","summary":"Talks and other documents Molitor, Thilo; Altheide, Friedrich. Modern XMPP - A story based on Monal Berlin XMPP Meetup, 13th April 2022, Recording, Slides Molitor, Thilo; Altheide, Friedrich. Privacy friendly push Berlin XMPP Meetup, 13th April 2022, Recording, Slides (starting after page 29) Molitor, Thilo. XMPP Push notifications on iOS Molitor, Thilo. Monal development recap 2019 - 2021 and open discussion Berlin XMPP Meetup, 13th October 2021, Recording XEP publications XEP-0353: Jingle Message Initiation Authors: Philipp Hancke, Peter Saint-Andre, Thilo Molitor This specification provides a way for the initiator of a Jingle session to propose sending an invitation in an XMPP message stanza, thus taking advantage of message delivery semantics instead of sending IQ stanzas to all of the responder\u0026rsquo;s online resources or choosing a particular online resource.","title":"Publications"}] \ No newline at end of file diff --git a/site/index.xml b/site/index.xml index 0db0131..5cfe4a8 100644 --- a/site/index.xml +++ b/site/index.xml @@ -1842,7 +1842,7 @@ Thank you, Anu, for your wonderful work towards a modern XMPP client for iOS and - https://xmpp.org/extensions/xep-0158 + xep-0158 @@ -1924,7 +1924,7 @@ Thank you, Anu, for your wonderful work towards a modern XMPP client for iOS and - https://xmpp.org/extensions/xep-0374 + xep-0374 @@ -1944,7 +1944,7 @@ Thank you, Anu, for your wonderful work towards a modern XMPP client for iOS and - https://xmpp.org/extensions/xep-0386 + xep-0386
XEP-0386: Bind 2.0 @@ -1974,7 +1974,7 @@ Thank you, Anu, for your wonderful work towards a modern XMPP client for iOS and - https://xmpp.org/extensions/xep-0420 + xep-0420 @@ -2004,7 +2004,7 @@ Thank you, Anu, for your wonderful work towards a modern XMPP client for iOS and - https://xmpp.org/extensions/xep-0158 + xep-0158 @@ -3159,7 +3159,7 @@ Decentralised and federated chat standard XMPP Private and group messaging Priva - https://xmpp.org/extensions/xep-0158 + xep-0158 @@ -3241,7 +3241,7 @@ Decentralised and federated chat standard XMPP Private and group messaging Priva - https://xmpp.org/extensions/xep-0374 + xep-0374 @@ -3261,7 +3261,7 @@ Decentralised and federated chat standard XMPP Private and group messaging Priva - https://xmpp.org/extensions/xep-0386 + xep-0386
XEP-0386: Bind 2.0 @@ -3291,7 +3291,7 @@ Decentralised and federated chat standard XMPP Private and group messaging Priva - https://xmpp.org/extensions/xep-0420 + xep-0420 @@ -3321,7 +3321,7 @@ Decentralised and federated chat standard XMPP Private and group messaging Priva - https://xmpp.org/extensions/xep-0158 + xep-0158 diff --git a/site/install/index.html b/site/install/index.html index dcbf909..4ae9017 100644 --- a/site/install/index.html +++ b/site/install/index.html @@ -5,7 +5,7 @@ Decentralised and federated chat standard XMPP Private and group messaging Privacy-respecting push notifications Encrypted private and group chats (state-of-the-art encryption (OMEMO) Message history Free selection of your XMPP account provider Voice messaging Message archiving Upload of files, videos and images (HTTP Upload) Audio and Video calls Many settings and a design to offer privacy settings in the app to the need of the user A detailed and technical listing of your supported features (so called XMPP Extensions) can be found in our DOAP file.">

Install

12.03.2022 · 3 min · Monal RSS | Suggest Changes
iOSmacOSmacOS (homebrew)
StableApp StoreApp Storebrew install --cask monal
BetaTestflight InvitationTestflight Invitationbrew install --cask monal@beta
Alphaupon request to info@monal-im.org
Then download from our alpha download site		brew tap monal-im/homebrew-monal-alpha
brew install --cask monal-alpha

Features

Monal currently covers the following chat features:

  • Decentralised and federated chat standard XMPP
  • Private and group messaging
  • Privacy-respecting push notifications
  • Encrypted private and group chats (state-of-the-art encryption (OMEMO)
  • Message history
  • Free selection of your XMPP account provider
  • Voice messaging
  • Message archiving
  • Upload of files, videos and images (HTTP Upload)
  • Audio and Video calls
  • Many settings and a design to offer privacy settings in the app to the need of the user
  • A detailed and technical listing of your supported features (so called XMPP Extensions) can be found in our DOAP file.

Planned features

  • User-interface overhaul

Implemented XEPs

XEPStatusSince
.
.
.
.
xep-0004complete4.9
xep-0030complete4.6
xep-0045partial5.0
xep-0048complete5.0
xep-0054
Implemented only for MUC profiles		complete5.0
xep-0059complete4.8
xep-0060
Used mainly for Pep		partial4.9
xep-0066
Used to mark XEP-0363 filetransfers only		partial4.9
xep-0077partial4.7
xep-0084complete4.9
xep-0085
Only typing notifications, use XEP-0319 to publish interactions		partial4.7
xep-0092complete5.0
xep-0115complete4.7
xep-0153
XEP-0153: vCard-Based Avatars (implemented only for MUC profiles)		partial5.0
xep-0162partial5.4
xep-0163complete4.9
xep-0167complete6.0
xep-0176complete6.0
xep-0172complete4.9
xep-0184complete4.7
xep-0191complete5.0
xep-0198complete4.6
xep-0199complete4.7
xep-0215complete6.0
xep-0223
XEP-0223: Persistent Storage of Private Data via PubSub		complete4.9
xep-0237complete4.6
xep-0245complete4.9
xep-0249
XEP-0249: Direct MUC Invitations		complete5.0
xep-0280complete4.5
xep-0286complete4.7
xep-0293complete6.0
xep-0294complete6.0
xep-0305complete5.1.1
xep-0308complete4.8
xep-0313complete4.8
xep-0319complete4.7
xep-0320complete6.0
xep-0333complete4.8
xep-0338complete6.0
xep-0339complete6.0
xep-0352complete4.7
xep-0353complete6.0
xep-0357complete4.8
xep-0359complete4.8
xep-0363complete4.9
xep-0368complete4.6
xep-0379
No automatic approval if server does not support subscription pre-approval; No checking of tokens, if server does not do so (XEP-0401)		partial4.9
xep-0380complete5.1
xep-0384complete4.8
xep-0388complete6.0
xep-0392complete5.1
xep-0398
Used for MUC avatars		complete6.0
xep-0401complete6.0
xep-0402complete5.4
xep-0410complete5.0
xep-0423
Check this XEP to see what's missing		partial
xep-0424complete6.3
xep-0425complete6.3
xep-0440complete6.0
xep-0441
Only to automatically turn on archiving if possible (setting: always)		complete4.8
xep-0445complete5.2
xep-0454
No support for embedded thumbnails		partial5.0
xep-0474complete6.0
xep-0480complete6.0
xep-0486complete5.0
xep-0490complete6.3

Planned XEPs

XEPStatus
https://xmpp.org/extensions/xep-0158planned
https://xmpp.org/extensions/xep-0374planned
https://xmpp.org/extensions/xep-0386
XEP-0386: Bind 2.0		planned
https://xmpp.org/extensions/xep-0420planned
https://xmpp.org/extensions/xep-0158planned