[Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

Andrew Nenakhov andrew.nenakhov at redsolution.com
Tue Sep 3 16:05:39 UTC 2019


вт, 3 сент. 2019 г. в 19:15, Ralph Meijer <ralphm at ik.nu>:>
> Hi,
>
> Let me start out saying that, like Philipp, my reading of the current
> version of XEP-0353 is also that there is additional information shared
> with the client over FCM/APNS. However, I must also say that neither
> XEP-0353 nor XEP-357 make it clear how this should work exactly. This is
> a problem, because it results in proprietary solutions for doing the
> same thing. At minimum this should get another look and more concrete
> examples with how existing push services would *actually* be used.
>
> Andrew's description of their use of XEP-0353 introduces new elements in
> the existing namespace, and adds a new iq-based exchange. Assuming this
> is an experiment, I do want to point out that before it would go into
> actual use, those would need to be moved to their own private namespace,
> or be included in a next version of this specification (which might
> require a new namespace).

I agree that our approach changes 0353 significantly. Since we DID
implement 0353 in its current form to the letter and discovered that
it can't work well on iOS without additional roundtrip. So it is
unlikely we'll support this XEP without changes. If our approach won't
be accepted into 0353, we'll move it to another namespace and treat is
as a new protocol, and will be implementing it (or another working
solution, if one emerges) instead of non-working one.

As for passing additional information over FCM/APNS. This data goes
totally unencrypted over third party entities, one of which has very
little public trust with matters concerning privacy. The mechanics of
these services prevent payload from being encrypted, so it's what it
is: some meaningful data will go in plain open form over untrusted
networks. If we start doing that, why really stop at 'additional
data'? We could have saved ourselves tons of blood and sweat spent at
making iOS client wake up on notification, connect to a server, fetch
recent messages, check their markers and present only an actual
message to users, all of this in fewer than 30 seconds. Instead, we
could have just displayed banner with a message in a standard open
way, without even establishing a connection, and all we had to do is
agree to send message contents to Apple/Google. No big deal, right?

While I'm not at all jumping on this full e2ee & full stanza
encryption bandwagon, compromising user privacy this way is a no go
for us.

> In the mean while it can present the screen for allowing the user to
> accept the call. As soon as the slow human user then presses 'accept'
> you're immediately good to go and fully establish the call. This saves
> several round-trips, and thus many centiseconds compared to XEP-0353 in
> its current form, and even more if you have a model that relies on
> re-establishing the XMPP connection before starting all of the above.

Of course, it is faster and simpler to do it this way! But at what
cost? Agan, If we start developing the fastest solution, we'll
eventually come up with some CA service that manages calls directly,
fully bypassing XMPP. Is that what we want?

-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com


More information about the Standards mailing list