On Donnerstag, 27. April 2017 22:37:19 CEST Georg Lukas wrote:
> * Jonas Wielicki <[email protected]> [2017-04-27 19:24]:
> > The UX is one thing. I’d first like to clear how N=1 would work
> > implementation wise.
> 
> Sorry, but this is doing it the wrong way around.

See below.

> You can store a list
> of tuples of (token, counter, max validity), either on the server or in
> the client. This is how yaxim currently does PARS. You could define an
> IQ to query the server for a new token, given a counter and a max
> validity, and let the server implementation sort it out. This is the
> easy part.

Right, this however loses the advantage of Daniels proposal that it’s trivial 
for clients to substitute an incapable server.

> The hard part is to define the right UX and the right security limits. 

Yes, that’s the hard part, I agree. However, first going for the hard part of 
UX while its unclear if there is a reasonable implementation at all (I hadn’t 
thought of the IQ thing you proposed, which would definitely work, too and I’m 
totally not a fan of those multi-item PEP node items) doesn’t seem quite 
reasonable to me either. If you’re convinced that a reasonable server-side 
implementation will be found, that’s fine with me. (Also, I was probably a bit 
too tired when I started thinking about this.)

> I
> think it is a security problem to have tokens that don't impose any
> limits, 

Agreed. Note that there is a time limit though.

> and I think that N=1 is a very sane default limit for
> invitations. 

Agreed. But I am probably not a good indicator for UX. Can we take a look at 
how other services do this?

Regarding N=\infty tokens, I see some valid use-cases for those, even though 
I’m unsure if those use-cases still work with time limits in place (e.g. 
inviting your whole family with a broadcast mail or something which they’re 
unlikely to read and act on within a reasonable validity time frame).

Regarding the point you made eariler:

>  - pending subscriptions are a similar DoS in most clients as completed
>   subscriptions.

This is maybe true for most *clients*, but consider users who have "only allow 
users in my roster / seeing my presence" rules in place. Auto-subscribed users 
are then much more harmful.


regards,
Jonas

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________

Reply via email to