-
Guus
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?
-
Guus
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.
-
Kev
Do you control the client and server?
-
Kev
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).
-
jonas’
Guus, generate a certificate, use client-certificate authentication.
-
jonas’
(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)
-
Kev
Or that, depending how much 'administrative action' you want to be required.
-
Guus
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?
-
Guus
jonas’ thanks, that's the route that I was dreading :)
-
Kev
No, you'd reject the client-provided resource and use a server-provided one.
-
Guus
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?
-
Kev
Yes.
-
Kev
Clients that don't cope with server-provided resources are broken.
-
Kev
But I did predictate it on you controlling the server and client :)
-
Guus
me controlling the server and client does not implicate that they're not broken. :D
-
Kev
Heh.
-
jonas’
Guus, why dreading? It should be simple and straightforward and it ensures your requirements more or less cryptographically
-
Guus
nothing involving client-sided certificates is ever simple, in my experience.
-
jonas’
it is if you treat them mostly as a private key
-
Kev
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.
-
jonas’
i.e. no CA involved, possibly even ignore expiration (or let them live for 1000 years)
-
Kev
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.
-
jonas’
I'd just generate the key on initial sign up
-
jonas’
and use whatever procedure you use to trust the password the user supplies during signup to trust the key
-
jonas’
no pre-provisioning or CA involved, that's, indeed, just madneess✎ -
jonas’
no pre-provisioning or CA involved, that's, indeed, just madness ✏
-
Guus
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?
-
Guus
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.
-
jonas’
what no
-
jonas’
just let the app provide the private key instead of the username/password on signup
-
jonas’
how does your signup procedure work?
-
jonas’
(if you're integrating with an existing username/password based scheme, then yes, your flow sounds sensible)
-
Guus
jonas’: yeah, user definitions preexist.
-
flow
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
-
flow
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"
-
flow
although I am not sure if they provide than any advantage ofer a PSK
-
jonas’
Guus, ah then the activation workflow makes sense
-
moparisthebest
smells of corporate security to me
-
moparisthebest
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"
-
flow
dunno, those specialized locked-down clients do not need to be user-hostile, in fact, the could be very user friendly
-
flow
wouldn't be surprised if Conversations would bring support for such a setup
-
jonas’
I am looking forward to the day we have actual per-device credentials (be it TLS keys, or Device-key-SASL, or whatever)
-
jonas’
of course, then without the limitation of one device per user
-
MattJ
Working on it :)
-
Zash
You can burn a full JID into the cert
-
jonas’
(well, actually not "whatever". I strongly think it should be devicekey or TLS keys)
-
Zash
Vaguely related, how do I https://datatracker.ietf.org/doc/html/rfc7250 ?
-
qy
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?
- qy looking at conversations and dino particularly
-
Seve
https://matrix.org/blog/2022/05/30/welcoming-rocket-chat-to-matrix moparisthebest: already discussed this too?
-
Zash
qy, huh?
-
Zash
something something https://docs.modernxmpp.org/
-
qy
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?
-
qy
> Zash wrote: > something something https://docs.modernxmpp.org/ ...oh
-
qy
Well, 🚀 modernxmpp
-
Zash
Dino has video conferencing, your argument is invalid
-
qy
It doesn't have a disco browser :-)
-
Zash
Also, diversity and the freedom to try out different things is a strength here. All clients don't have to be the same.
-
moparisthebest
what features are you missing? all the stuff that has *terrible* UI like ad-hoc commands? :P
-
qy
Zash: But it is the biggest flaw of xmpp
-
qy
Well, it doesn't _have_ to have terrible ui if we figure out a nice one!
-
moparisthebest
has anyone ever used ad-hoc commands and thought "hmm that was a pleasent experience"
-
Zash
That's just, like, your opinion, man
-
qy
😅
-
moparisthebest
usually more like "hmm why did the whole thing freeze" "oh no I clicked back and it crashed" "why didn't anything save"
-
qy
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...
-
qy
How else am i meant to configure biboumi :|
-
qy
Routinely have to operate 5 different clients to do everything i want smh
-
moparisthebest
biboumi should be configurable over a bot-like interface
-
Zash
I'm sure the Soprani.ca folks are plenty interested in improving the experience with gateways etc
-
moparisthebest
they just went ahead and made everything configurable via talking to a bot, works very well
-
qy
Are we just anti adhoc being a thing then?
-
qy
What about disco?
-
wgreenhouse
ad hoc is useful because you can do input validation, and you can also format the output of commands
-
Zash
Who's this "we"?
-
wgreenhouse
soprani.ca folks are adding it to their conversations fork, for that reason
-
wgreenhouse
> Who's this "we"? modernxmpp and/or the authors of more recent gui clients
-
qy
wgreenhouse: I may switch to that fork, unless blabber adopts it too...
-
wgreenhouse
> 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
-
qy
Is it a prompt-based flow in j.el?
-
moparisthebest
you can do input validation in a bot too
-
qy
moparisthebest: Do you have something against ad-hoc in particular? Or just think it can't be implemented nicely?
-
qy
It is a stable xep, isn't it?
-
moparisthebest
just that it can't be implemented nicely and serves no purpose that a bot doesn't serve easier, imho
-
qy
Feels like IRC logic; everything as chat :p
-
Zash
never say never, but it takes effort on both client and server side to get the most out of it
- qy yearns for xmpp nickserv
-
Zash
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.
-
Zash
Most available ad-hoc commands are server admin related, for which `prosodyctl shell` is just so much nicer and more powerful.
-
wgreenhouse
> Is it a prompt-based flow in j.el? qy: no, it's a new emacs buffer with fields, like M-x customize
-
qy
Oh excellent indeed
-
wgreenhouse
so you can actually keep chatting with that jid, it doesn't "steal" the buffer
-
moparisthebest
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
-
qy
For weechat i think i'm gonna have to copy profanity's model but make it a bit more prompt-based
-
moparisthebest
good luck keeping your infinitly configurable UI code concise and bug free :D
-
wgreenhouse
there are beaucoup bugs, just not in ad hoc handling. :P
-
Sam
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.
-
Sam
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.
-
Zash
Observation: You don't need dataforms for parameter-less ad-hoc commands.
-
Sam
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.
-
Zash
Also, I think you could replace dataforms with anything as payload carrier, tho that's probably more interesting for some RPC uses
-
Sam
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.
-
Zash
Overly generic things are tricky.
-
Zash
Many things could probably be done with the simpler registration XEP (77?)
-
Sam
This is probably the underlying problem ⤴️
-
wgreenhouse
registration would make more sense for things like biboumi
-
wgreenhouse
since what most people are doing is setting nickserv stuff and maybe changing the hostname to connect to
-
pep.
> 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".
- qy grumbles about being an advanced user
-
Sam
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.
-
moparisthebest
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
-
moparisthebest
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
-
wgreenhouse
ouch. fair enough, though
-
qy
...you're using the windows registry as an example of good, modern design?
-
moparisthebest
yes, as good and modern as ad-hoc commands :)
-
qy
Have I entered the twilight zone 😧
-
qy
Anyway, i agree for now, thats why i was trying to think of how to get more clients to implement ad-hoc commands
-
qy
Because if only half the clients implement it, its not worth any of them doing it
-
moparisthebest
classic chicken and egg
-
qy
But if you premake the egg, who needs a chicken
-
qy
Hence, modernxmpp ui and implementation guidelines for ad-hoc commands, so its nice&easy
-
qy
> here's a yolk i prepared earlier
-
pep.
moparisthebest: bot-as-interface reminds me of your position regarding 393 :p
-
pep.
And I completely understand why you like it, and you may understand why I would hate it
-
moparisthebest
you might notice a pattern here, 393 and bots are KISS, ad-hoc and choose-your-own-markup are not :D
-
qy
moparisthebest: I feel like you would really like IRC
-
pep.
moparisthebest: KISS, but for whom :)
-
pep.
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
-
pep.
It's simple for client devs, maybe, not for users
-
moparisthebest
it's more simple for users
-
moparisthebest
"message X and have a conversation" vs "60 minutes of them nodding their heads while attempting to explain what an ad-hoc is"
-
moparisthebest
qy, I do like IRC :P just through XMPP
-
Sam
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.
-
moparisthebest
yea both sounds like a good option if it's easy enough
-
Sam
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
-
wgreenhouse
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
-
wgreenhouse
maybe 0077 is a way out, if it's simpler to implement
-
pep.
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
-
Sam
Oh I disagree, ad-hoc was exceptionally hard to implement correctly.
-
Sam
The spec is incredibly confusing and often vague.
-
Zash
I'm thinking it's okay to reserve it for where the complexity is warranted.
-
pep.
Sam: maybe the spec needs improving/redoing, but I don't think that the concept in itself is complex
-
Zash
Clarifications of the specs are always welcome
-
qy
What part was hard to implement, ooi?
-
qy
I haven't tried yet, so curious
-
lovetox
If I remember correctly it's a bit confusing with the actions and default actions that are available in each stage
-
lovetox
And I think there was clarifications on that part
-
moparisthebest
if you all are like me, you read/implement a spec, find it annoying/confusing, vow to write clarifications for the next poor soul...
-
lovetox
Othr than that, I would say "exceptional hard" is a hyperbole
-
moparisthebest
then a couple months pass and you've memorized all the things you needed to know and forgot what you intended to write down...
-
jonas’
Zash, to be fair, '77 has had its fair share of council/standards politics deadlock
-
jonas’
there is that edge case I don't dare to remember
-
Zash
I've conveniently swapped out all of it to the point I didn't remember the number 🤷️
-
jonas’
good.
-
jonas’
sorry
-
jonas’
I didn't mean '77 actually, I meant '50