XSF Discussion - 2022-05-31

Are there any best practices on ensuing that only a recognized (mobile) device is used by a particular end-user? For example, not any other phone than the first one that was used by the client (unless some kind of manual administrative action is performed?

Basically, I'm looking for a way to prevent a device other than the one that's either implicitly or explicitly associated with the end-user to be used for the account of that end-user.

Do you control the client and server?

It's not a best practice, but in that case you could fairly easily use a persistent resource from the client (but would obviously have to then randomise it on the server).

Guus, generate a certificate, use client-certificate authentication.

(and put the key into device storage which cannot be copied (easily) to another device, don't allow sign-up with another key unless administrative action)

Or that, depending how much 'administrative action' you want to be required.

Kev: as in resource binding? I thought of that, but I worried that this would be pretty easy to mimic - especially since the resource that's used will be used in stanzas that are sent to other users?

jonas’ thanks, that's the route that I was dreading :)

No, you'd reject the client-provided resource and use a server-provided one.

Kev: ah, right - so the client-provided resource would never escape into the wild. That hinges on clients actually accepting a server-provided resource that's different from the one that they provide. I recall that the spec allows for this, but is that used in practice?

Yes.

Clients that don't cope with server-provided resources are broken.

But I did predictate it on you controlling the server and client :)

me controlling the server and client does not implicate that they're not broken. :D

Heh.

Guus, why dreading? It should be simple and straightforward and it ensures your requirements more or less cryptographically

nothing involving client-sided certificates is ever simple, in my experience.

it is if you treat them mostly as a private key

jonas’ : It does require that either the admin is generating new certs themselves and injecting them into the devices somehow, or that they are somehow tying up randomly client-generated certs with user credentials. Whereas the resource would allow you to build a system where the admin merely has to approve a new client, knowing for whom it is. I guess it depends on Guus's requirements.

i.e. no CA involved, possibly even ignore expiration (or let them live for 1000 years)

But if you're happy to pre-provision the clients with generated certs, it should indeed not be terribly complicated. We've had deployments do similar things in the past.

I'd just generate the key on initial sign up

and use whatever procedure you use to trust the password the user supplies during signup to trust the key

no pre-provisioning or CA involved, that's, indeed, just madness ✏

jonas’: so, have an initial password-based auth, which somehow provides a cert for the device, which, once registered makes unavailable the password-based auth and will require something like SASL External for that device from then on?

I guess that could be sold to the end-user as some kind of 'account activation', which under water registers a cert for the end-user.

what no

just let the app provide the private key instead of the username/password on signup

how does your signup procedure work?

(if you're integrating with an existing username/password based scheme, then yes, your flow sounds sensible)

jonas’: yeah, user definitions preexist.

how does any of that ensure that only a recognized device is used by a particular user? the client cert could be transferred and the resource could also be simply configured by another device, no? I guess you need to have full control over the client software (which is possible on mobile platforms) and use some onbording procedure when the user starts the client for the first time

fwiw, TLS-PSK (Pre Shared Key) is also a thing, but other than that, I aggree with jonas’ that (TLS) certs become easy if you treat them like "private keys"

although I am not sure if they provide than any advantage ofer a PSK

Guus, ah then the activation workflow makes sense

smells of corporate security to me

and by that I mean they'll make it as user-hostile as possible for 0 benefit other than being able to check a box that says "secure"

dunno, those specialized locked-down clients do not need to be user-hostile, in fact, the could be very user friendly

wouldn't be surprised if Conversations would bring support for such a setup

I am looking forward to the day we have actual per-device credentials (be it TLS keys, or Device-key-SASL, or whatever)

of course, then without the limitation of one device per user

Working on it :)

You can burn a full JID into the cert

(well, actually not "whatever". I strongly think it should be devicekey or TLS keys)

Vaguely related, how do I https://datatracker.ietf.org/doc/html/rfc7250 ?

You know how clients like to skip entire bundles of XEPs to "keep their UI simple"? Maybe it'd be useful to have a standand UI or UI guidelines, so that doesn't have to be the case?

https://matrix.org/blog/2022/05/30/welcoming-rocket-chat-to-matrix moparisthebest: already discussed this too?

qy, huh?

something something https://docs.modernxmpp.org/

Zash: Gajim's rather feature complete, the other two are not, as i understand it primarily because they're UI-first and want to keep things "simple"/"easy to use" - so if there was a known UI form, that wouldnt be an excuse?

> Zash wrote: > something something https://docs.modernxmpp.org/ ...oh

Well, 🚀 modernxmpp

Dino has video conferencing, your argument is invalid

It doesn't have a disco browser :-)

Also, diversity and the freedom to try out different things is a strength here. All clients don't have to be the same.

what features are you missing? all the stuff that has *terrible* UI like ad-hoc commands? :P

Zash: But it is the biggest flaw of xmpp

Well, it doesn't _have_ to have terrible ui if we figure out a nice one!

has anyone ever used ad-hoc commands and thought "hmm that was a pleasent experience"

That's just, like, your opinion, man

😅

usually more like "hmm why did the whole thing freeze" "oh no I clicked back and it crashed" "why didn't anything save"

moparisthebest: I actually think as theyre done in gajim, pretty nice. I'll agree in profanity, not a great time, but im grateful theyre at least there...

How else am i meant to configure biboumi :|

Routinely have to operate 5 different clients to do everything i want smh

biboumi should be configurable over a bot-like interface

I'm sure the Soprani.ca folks are plenty interested in improving the experience with gateways etc

they just went ahead and made everything configurable via talking to a bot, works very well

Are we just anti adhoc being a thing then?

What about disco?

ad hoc is useful because you can do input validation, and you can also format the output of commands

Who's this "we"?

soprani.ca folks are adding it to their conversations fork, for that reason

> Who's this "we"? modernxmpp and/or the authors of more recent gui clients

wgreenhouse: I may switch to that fork, unless blabber adopts it too...

> has anyone ever used ad-hoc commands and thought "hmm that was a pleasent experience" moparisthebest: they work great for me in jabber.el :D

Is it a prompt-based flow in j.el?

you can do input validation in a bot too

moparisthebest: Do you have something against ad-hoc in particular? Or just think it can't be implemented nicely?

It is a stable xep, isn't it?

just that it can't be implemented nicely and serves no purpose that a bot doesn't serve easier, imho

Feels like IRC logic; everything as chat :p

never say never, but it takes effort on both client and server side to get the most out of it

I think Gajim did an excellent job, but on the other hand I haven't touched adhoc in months. Configuring Biboumi is mostly a one-time thing.

Most available ad-hoc commands are server admin related, for which `prosodyctl shell` is just so much nicer and more powerful.

> Is it a prompt-based flow in j.el? qy: no, it's a new emacs buffer with fields, like M-x customize

Oh excellent indeed

so you can actually keep chatting with that jid, it doesn't "steal" the buffer

ha yes, I last touched biboumi config years ago (using gajim), and haven't needed ad-hoc for prosody in years either for what Zash mentioned

For weechat i think i'm gonna have to copy profanity's model but make it a bit more prompt-based

good luck keeping your infinitly configurable UI code concise and bug free :D

there are beaucoup bugs, just not in ad hoc handling. :P

This is something I've been particularly interested in lately. I really thought that dataforms were the main problem and couldn't be used to create a nice UI, and while I still don't love them I have come around on their existance a bit.

However, the ad-hoc spec is just *really* hard to understand and implement properly for something that should be simple, so I still suspect that it ends up being horribly buggy not because of UI problems, but because of how it's written and explained.

Observation: You don't need dataforms for parameter-less ad-hoc commands.

Sure, that's why I thought forms were the problem then I discovered that even for parameterless ones there were lots of bugs and issues for something that should have been trivially simple.

Also, I think you could replace dataforms with anything as payload carrier, tho that's probably more interesting for some RPC uses

So I'm really not sure about them now. I've come around a little bit, but kind of think the whole thing should be thrown out and re-written. Then again, we haven't had much success with that strategy in the past, even for things that didn't have a huge number of implementations.

Overly generic things are tricky.

Many things could probably be done with the simpler registration XEP (77?)

This is probably the underlying problem ⤴️

registration would make more sense for things like biboumi

since what most people are doing is setting nickserv stuff and maybe changing the hostname to connect to

> moparisthebest> has anyone ever used ad-hoc commands and thought "hmm that was a pleasent experience" Actually, yes. Poezio's UI here is ok. I get it's an "advanced feature" (handling generic adhoc forms) and I think that's why it's not in C nor Dino, not because it's "not pretty" or "not easily usable".

Same with Communiqué, I think, but it was *really* hard to figure out all the weird ad-hoc bugs, and I'm sure it's still probably not compatible with some implementations.

so you are writing a service, and debating on how best to let users configure it, your options are: 1. text bot, works with literally everything, including bridges, don't need to test anything else because there aren't differences in implementations 2. ad-hoc commands, works with a couple clients, you have to test them each because they each display things differently and have different bugs, and no other clients care to support them because of all of these problems

but hey whatever floats your boat, as an advanced user I'd much rather just use text anyway, ad-hoc commands are more akin to the windows registry :P

ouch. fair enough, though

...you're using the windows registry as an example of good, modern design?

yes, as good and modern as ad-hoc commands :)

Have I entered the twilight zone 😧

Anyway, i agree for now, thats why i was trying to think of how to get more clients to implement ad-hoc commands

Because if only half the clients implement it, its not worth any of them doing it

classic chicken and egg

But if you premake the egg, who needs a chicken

Hence, modernxmpp ui and implementation guidelines for ad-hoc commands, so its nice&easy

> here's a yolk i prepared earlier

moparisthebest: bot-as-interface reminds me of your position regarding 393 :p

And I completely understand why you like it, and you may understand why I would hate it

you might notice a pattern here, 393 and bots are KISS, ad-hoc and choose-your-own-markup are not :D

moparisthebest: I feel like you would really like IRC

moparisthebest: KISS, but for whom :)

The receiving client can't have any specific UI for your gateway if the interface is a bot, there's no choice but to make a generic message-sending UI

It's simple for client devs, maybe, not for users

it's more simple for users

"message X and have a conversation" vs "60 minutes of them nodding their heads while attempting to explain what an ad-hoc is"

qy, I do like IRC :P just through XMPP

I had a nice little library I was working on that let you design ad-hoc command flows and then it would respond to them both with forms and with chat messages (and I think the sopranica folks have something similar). It's not an either/or situation, but I definitely think for normal users a UI would be preferred. Even as someone who doesn't really care one way or another, the UI is way easier in some situations.

yea both sounds like a good option if it's easy enough

There are situations where you can't have both, of course. Mcabber responds to a few ad-hoc commands to allow you to eg. set its staus from another client. It's quite nice, but obviously if you sent a message to the JID you'd expect it to just be delivered as a normal message

the case where the recipient is also an entity you can message with is an argument for ad hoc. like, biboumi's configuration uses ad hoc in part because the server JID is also what you chat with to send raw IRC commands

maybe 0077 is a way out, if it's simpler to implement

I think the fact that it's simpler to implement is a non-argument between all of these options. Yes adhoc takes a bit more to implement but It's not like it (or a -- nonexistent -- different intetface with similar goals) was exceptionally hard to implement either

Oh I disagree, ad-hoc was exceptionally hard to implement correctly.

The spec is incredibly confusing and often vague.

I'm thinking it's okay to reserve it for where the complexity is warranted.

Sam: maybe the spec needs improving/redoing, but I don't think that the concept in itself is complex

Clarifications of the specs are always welcome

What part was hard to implement, ooi?

I haven't tried yet, so curious

If I remember correctly it's a bit confusing with the actions and default actions that are available in each stage

And I think there was clarifications on that part

if you all are like me, you read/implement a spec, find it annoying/confusing, vow to write clarifications for the next poor soul...

Othr than that, I would say "exceptional hard" is a hyperbole

then a couple months pass and you've memorized all the things you needed to know and forgot what you intended to write down...

Zash, to be fair, '77 has had its fair share of council/standards politics deadlock

there is that edge case I don't dare to remember

I've conveniently swapped out all of it to the point I didn't remember the number 🤷️

good.

sorry

I didn't mean '77 actually, I meant '50