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

Sam Whited sam at samwhited.com
Thu Dec 29 22:48:19 UTC 2016

A few scattered thoughts after a first reading of this thread:

On Thu, Dec 29, 2016 at 4:32 PM, Tobias Markmann
<tmarkmann at googlemail.com> wrote:
> * 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.

Agreed, it would be nice to add TLS version and maybe ciphers to the
compliance suites. I'll add those after the pending OMEMO PR (see the
next quote) is merged or rejected.

> * 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.

Added (we can turn these into 2017 suites soon since they're still
experimental): https://github.com/xsf/xeps/pull/335

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

The slides (with no other context, I wasn't at the talk) say that
"Centralized and proprietary services have considerable advantages
when it comes to abuse management." I'm not sure this is true. I very
*very* rarely have spam get through my email filters (which is not
proprietary or centralized), and don't see why individual services
that use XMPP (server operators) couldn't also implement the exact
same spam filters on their XMPP servers. We may not have the big data
of gmail, but even simple filters do wonders for Spam (the filter in
Thunderbird is pretty good in my experience).

That being said, it does need to be "addressed" in the sense that
someone has to actually do that and maybe tie it in with
https://xmpp.org/extensions/xep-0377.html (which no client implements
as far as I know; it all ties back to incentivizing clients to
implement modern features, so I think that's the more important issue;
I'm not entirely sure how the SPAM slides tied in with the rest of the
presentation… does Signal do anything about this, or is it just not
popular enough to be a target for spammers?).

> * 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.

In my mind this is probably the single biggest issue with most public
services based on XMPP these days; we need to provide a clear path
forward, although I must confess that I'm at a loss as to how that
could be done.


Sam Whited
pub 4096R/54083AE104EA7AD3

More information about the Standards mailing list