Repository navigation
Push Notifications are broken.. sometimes. #637
Description
Activity
Not a developer, but I can confirm the problem on my public XMPP server (yax.im):
- Message is sent to the user
- prosody sends IQ to pubsub.chatsecure.org
- pubsub.chatsecure.org returns IQ result
- nothing happens on the smartphone
Debug log from prosody:
Jan 03 17:40:34 yax.im:carbons debug Sending carbon to [email protected]/chatsecureXXXX Jan 03 17:40:34 c2sb659af0 debug Invoking cloud handle_notify_request for new smacks hibernated stanza... Jan 03 17:40:34 yax.im:cloud_notify debug Sending push notification for [email protected] to pubsub.chatsecure.org Jan 03 17:40:34 stanzarouter debug Routing to remote... Jan 03 17:40:34 s2sout3c93a10 debug going to send stanza to pubsub.chatsecure.org from yax.im Jan 03 17:40:34 s2sout3c93a10 debug sending: <iq type='set' to='pubsub.chatsecure.org' from='[email protected]' id='push'> Jan 03 17:40:34 s2sout3c93a10 debug stanza sent over s2sout Jan 03 17:40:34 s2sin53cbc60 debug Received[s2sin]: <iq id='push' type='result' to='[email protected]' from='pubsub.chatsecure.org'>This is the full IQ-set that's sent from yax.im to ChatSecure's server (token and node anonymized):
<iq type="set" to="pubsub.chatsecure.org" from="[email protected]" id="push"> <pubsub xmlns="http://jabber.org/protocol/pubsub"> <publish node="A9BFF3A9-276C-46E2-****-************"> <item> <notification xmlns="urn:xmpp:push:0"> <x xmlns="jabber:x:data" type="form"> <field type="hidden" var="FORM_TYPE"> <value>urn:xmpp:push:summary</value> </field> <field type="text-single" var="message-count"> <value>6</value> </field> <field type="text-single" var="pending-subscription-count"/> <field type="jid-single" var="last-message-sender"/> <field type="text-single" var="last-message-body"/> </x> </notification> </item> </publish> <publish-options> <x xmlns="jabber:x:data"> <field var="FORM_TYPE"> <value>http://jabber.org/protocol/pubsub#publish-options</value> </field> <field var="token"> <value>b86cd972bcfb466f************************</value> </field> <field var="endpoint"> <value>https://push.chatsecure.org/api/v1/messages/</value> </field> </x> </publish-options> </pubsub> </iq>
I'm seeing this as well, not sure why it stopped working because we've made no changes in a long time. A quick look at our error logs shows no clear culprit, so I'll have to take a closer look. Let me know if you notice it working again.
Does the manual "Knock" feature work between two ChatSecure iOS clients?
- changed the title
[-]Push notification with current version[/-][+]Push Notifications are Broken[/+]on Jan 3, 2017 - changed the title
[-]Push Notifications are Broken[/-][+]Push Notifications are broken.. sometimes.[/+]on Jan 4, 2017 Okay, so I tested again this afternoon and was able to get it to work using both Knock as well as XEP-0357 style pushes.
This might be OS throttling based on our use of content-available..
Were any of you using "low power mode"?
Upgraded both of my devices to beta 58. XEP-0357 notifications still don't arrive at the device.
The iPhone was attached to the charger all the time, low-power-mode is disabled.
Not quite sure how to trigger the "Knock" feature, IIRC it should appear instead of "Send" in the chat view for offline contacts? My secondary iOS device/account is offline, but all I see is a greyed out "Send" button.
In order for Knock to work between iOS clients, you need to establish an OTR session once in a while to exchange tokens, make sure you set it to "OTR" or "OMEMO & OTR", at least temporarily.
81 remaining items
@chrisballinger This would be really awesome! :)
I'll create a list of stanza types tomorrow.@chrisballinger @iNPUTmice @weiss
I would propose the following notification types:presence(all presence stanzas)important_presence(for joining mucs, not sure how to define what muc presences are important and what are not, though, as I'm not that much into mucs)invite(muc invites)chatstate(all chatstates, could be minimized to only typing notifications)readable_message(message stanzas having a body)query(iq stanzas)message(all other message stanzas not covered above)
Any thoughts on this?
I would propose the following notification types:
I think I'd avoid predefining notification types.
One idea might be to let clients add an
include_payload(or whatever) attribute to the<enable/>request, which isnoneby default but can be set tofullorstrippedinstead. If it's set tofull, the published<notification/>s would include a<payload/>child which holds the complete stanza. Withstripped, it would strip all stanza contents except for the stanza's name, itstypeattribute (if any), and the direct child elements with theirxmlnsattributes (if any). Or something like that.Maybe the (underspecified)
urn:xmpp:push:summarything could then be removed from the XEP.Anyway, these things should probably be discussed on the standards list instead.
@weiss I don't think including the full stanza is a good idea for privacy reasons because the pubsub server is usually run by the app developers, not your XMPP server operator. You can then end up leaking content and metadata in two places instead of (mostly) just one. I 100% do not support including full stanzas, and I refuse to implement any functionality that relies on parsing them. I don't even feel comfortable with the current
summaryfunctionality that allows people to include the sender and message body (I also ignore this content).Allowing servers to send our pubsub bridge unwanted
fullstanzas is dangerous and creates a central point of failure. In my opinion it defeats the whole point of having a decentralized network. Servers operators might think it's required to include this data, or modules might have bad defaults. The ONLY functionality we need is a tap on the shoulder to wake the client up, and then do a normal connection.@chrisballinger Holger proposed this setting to be entirely configurable by the client. Servers sending full stanzas when not configured to do so would violate the standard and servers can do this already, despite of any XEP changes.
There are some valid scenarios for inclusion of full stanzas.
For example a server monitoring pager used by a company which operates the XMPP server AND the app server as well as their own app.
This doesn't even mean that the app server does send out the whole unencrypted stanza through GCM or APNS.However Holger's proposal mainly was to use stripped stanzas instead of hardcoded stanza types.
This way no content would be leaked, but the xep and implementation thereof would be much more flexible:With stripped, it would strip all stanza contents except for the stanza's name, its type attribute (if any), and the direct child elements with their xmlns attributes (if any).
And last but not least Holger proposed to make the current behaviour to not send any (useful) metadata at all the default:
One idea might be to let clients add an include_payload (or whatever) attribute to the request, which is none by default but can be set to full or stripped instead.
I like his proposal and I think it is the right way to go (and removing the underspecified
urn:xmpp:push:summarything was something I thought about as well).The current revision of the XEP specifies how to include message body contents with the push notification. It doesn't specify under what circumstances the server might or should do that. This is something I'd definitely remove from the XEP.
As @tmolitor-stud-tu said, what I suggested was making this configurable per client instead, which IMO is totally harmless. Just don't let ChatSecure enable this behavior. I suggested having the option because I can imagine non-APNS scenarios where including full stanzas makes sense. E.g., an Ubuntu Phone app cannot reconnect (to fetch stanzas) while in the background, and you might have a trusted app server there (you're not forced to use central infrastructure like on iOS or Android). Or you might be using XEP-0357 in a totally different context, such as IoT.
However, as @tmolitor-stud-tu also pointed out, my main suggestion was the option to include stripped stanzas with notifications (instead of specifying a predefined "notification type"). Examples:
<!-- A chat message: --> <message type='chat'><body/></message> <!-- A PEP/PubSub event: --> <message type='headline'><event xmlns='http://jabber.org/protocol/pubsub#event'></message> <!-- A Jingle session initiation: --> <iq type='set'><jingle xmlns='urn:xmpp:jingle:1'/></iq>The ONLY functionality we need is a tap on the shoulder to wake the client up, and then do a normal connection.
Initially I was really hoping this would be true on all relevant mobile platforms (which might not include things like Ubuntu Phone), but this discussion was motivated by the fact that silent notifications don't seem to be reliable on iOS, no? :-/
As @tmolitor-stud-tu said, what I suggested was making this configurable per client instead, which IMO is totally harmless. Just don't let ChatSecure enable this behavior.
I see, basically allow clients to tell the server how to behave, and not leave it up to the settings on the server. My nightmare scenario was that all of a sudden I get a bunch of leaky full stanzas because of poorly configured servers. There are valid cases where, if you own the whole infrastructure, you don't mind that stuff is leaking... but I don't want those cases to ever be considered default behavior. I just don't like that I can't really control what is sent to
pubsub.chatsecure.org, so I want to minimize that as much as possible.My hesitation with stripped stanzas is how do we know what is "safe" to include? If a client sends a more complex stanza than the strip algorithm can't handle, how do we ensure that the result doesn't leak unexpected content? Even if we can agree on a stripping algorithm, it will still leak more metadata to me than I want compared to boiling it down to just
messageandinvitetypes. It also adds complexity to each 357 pubsub implementation to figure out how to parse different kinds of stanzas.@chris I don't think that stripping stanzas would be overly complex.
I guess an implementation in prosody would take about 10-15 lines of code.Yes, this is a bit more metadata than just
inviteormessage, but in my opinion the stripped stanzas contain nothing sensitive.
Only having direct child tag names and namespaces as well as tag name and namespace of the stanza itself really isn't much metadata.If a client sends a more complex stanza than the strip algorithm can't handle, how do we ensure that the result doesn't leak unexpected content?
Well, my ad-hoc suggestion above was to "strip all stanza contents except for the stanza's name, its type attribute (if any), and the direct child elements with their xmlns attributes (if any)." This assumes the element names and
type/xmlnsvalues won't contain sensitive data. But yes, this does leak some details about the type of data your users are receiving. (Though to me this seems less sensitive than the user JIDs currently leaked to your app server as per the XEP.)it will still leak more metadata to me than I want compared to boiling it down to just
messageandinvitetypes.Yes, if we're reasonably confident that
messageandinvitewill be "enough for anybody"™ then there's no point in my suggestion. My fear is that other clients might have push requirements we failed to anticipate while predefining notification types.(Though to me this seems less sensitive than the user JIDs currently leaked to your app server as per the XEP.)
I also would like that to not be leaked as well, because it's not needed in our case. Perhaps that could be addressed in future revision and made configurable by the client as well.
My fear is that other clients might have push requirements we failed to anticipate while predefining notification types.
I agree, perhaps we could still boil it down to a few simple types but offer an escape hatch w/ stripped or full stanzas.
@gerg5c42g542g2c54g52c That won't be possible, sorry...
@gerg5c42g542g2c54g52c What wrong with ejabberd's mod_push? The issue with Prosody 0.10 and ejabberd 17.01 is resolved in v4.0.4, which should be available some time early next week.
It would be nice if it was possible to fix push by solely client-side changes as many servers don't use prosody, but use old ejabberd version with pre-alpha mod_push.
I don't think many servers use the "pre-alpha" module you have in mind (I'm not aware of a single public server that does).
So as I understand this, push on iOS won't work on any ejabberd servers in a reasonably close future
Depends on your definition of "reasonable". A proper
mod_pushmodule will be shipped with one of the next ejabberd releases.Alright, I'm going to close this issue because it's gone way beyond its original scope and now that v4.0.4 is out there are additional resources for end users to self-debug their issues. Please open separate issues for new feature discussion.
Dear Developers,
I installed your nice app at some friends, and I am using it with a own xmpp server (prosody 0.10) + Push-module (cloud_notify). Some of my friends a while back also got some push notifications, so it seemed to work somehow a while ago. But now there aren't any push notifications any more. I wonder now if the push server is down (as my prosody logs seem to indicate, as they say something of "not found"), or if is rather my fault, e.g. because he the push app server doesn't like my self-signed certificate. But if the later, why did it work then sometimes a while ago?
Any helpful comment highly appreciated :-)
greets