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

Mathieu Pasquet mathieui at mathieui.net
Thu Dec 29 23:07:37 UTC 2016


Hi,

It was indeed a nice talk.

On Thu, Dec 29, 2016 at 04:48:19PM -0600, Sam Whited wrote:
> A few scattered thoughts after a first reading of this thread:
> [snip]
> 
> > * 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?).

This was also covered; one of the crucial antispam mechanisms of Signal
is the use of phone numbers as identifiers, and even using the "desktop"
client requires to approve using the mobile client first.

I personally see more email spam than XMPP spam nowadays, but as a
server administrator it’s the opposite, having to watch for automated
registration patterns. A reporting and reputation system would go a long
way towards reducing the amount, and maybe a multi-tiered system would
work (I would hate to prevent people from creating and connecting to
account from Tor exit nodes, but at the same time we have a lot of bogus
registrations and spam and DDoS using it).


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

One of the points was that the dichotomy between applications and
accounts is only an issue in the federated world, as most "apps" are the
only way of accessing the silo, and even gmail which offers external
POP/IMAP/SMTP connectivity is still primarily used through the web
interface.

I think ideally clients should provide clear defaults like what
conversations does, and of course options, but hidden from the view of
normal users who don’t understand this kind of things. This is sad (as
it might lead to “megaservers” for popular clients), but that really
needs to be straightened out.

I could envision a "pick your username" dialog giving new users a
random server among a list of curated services.

Mathieu

-- 
poezio developer & jabberfr admin


More information about the Standards mailing list