[Standards] 33C3 talk on Signal and current XMPP issue in providing a similar UX

Tobias Markmann tmarkmann at googlemail.com
Thu Dec 29 22:32:18 UTC 2016

Hi all,

So @hanno ( https://twitter.com/hanno/ ) did a presentation followed by a
short discussion on Signal and how XMPP and other federated systems fail to
provide a similar secure and usable system over federated architecture. The
slides can be found at https://www.int21.de/slides/33c3-decentralized/#/ .

The talk was attended quite well so I think at least in the CCC community
there seems to be still vibrant interest in having usable federated XMPP
messaging with sensible and secure defaults. Would be even better if the
large interest would come with similar large implementing developer base,
but we have to work with what we currently have in the XMPP community.

Conclusions from the talk and possible actions to address them are:

* The XMPP manifesto from 2014 was a nice start and had very visible and
noticeable effects, >95% of public XMPP services require TLS for C2S
connections. However, the manifesto is outdated with regard to latest
secure TLS versions and has some inconsistencies. Maybe we should update it
or turn it into a XEP, maybe as part of server compliance suites.

* A lot clients are missing modern features and support for modern XEPs. We
need to provide more incentive for client developers implementing these
newer XEPs. Maybe we should sort the client list on xmpp.org based on
support of the latest compliance suite XEP. Similar to Daniel's page for
XMPP services at https://gultsch.de/compliance.html .

* The current compliance suite doesn't include any E2E security
requirement. This one is easy to fix i think. We write up compliance suites
for 2017 and add E2E to it. Ideally in the first quarter of 2017.

* Current SPAM/SPIM issue needs to be addressed in some way.

* XMPP on-boarding. New users finding the right XMPP service for them, one
that matches their law requirements and privacy expectations. After
registration, they need to easily/secure/privacy-enforcing fill up their
roster with contacts based on known contact information like phone number
or e-mail address.

I probably missed some, so feel free to add further points. What are your
opinions, ideas, and suggestions on these issues?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20161229/2bf89474/attachment.html>

More information about the Standards mailing list