XSF Discussion - 2017-12-13


  1. jonasw

    edhelas, https://github.com/horazont/aioxmpp/issues/90

  2. jonasw

    some notes on that topic^

  3. jonasw

    edhelas, https://github.com/horazont/aioxmpp/issues/90

  4. edhelas

    thx

  5. edhelas

    https://blog.apnic.net/2017/12/12/internet-protocols-changing/

  6. edhelas

    XMPP over UDP for when ?

  7. marc

    Ge0rG, just thought about user invitation again, we have to following scenarios, correct? * User invitation: - Client-side PARS (fallback for lazy server operators) - Server-side PARS: For private servers - Server-side PARS or account creation: For private or public servers * Account creation for admins and privileged users

  8. marc

    Ge0rG, the new XEP would cover everything except client-side PARS

  9. Ge0rG

    marc: Server-side PARS: this can work for public and private servers, depending on a server-side config.

  10. marc

    Ge0rG, yes, of course

  11. Ge0rG

    marc: other than that, yes

  12. marc

    Ge0rG, good :)

  13. Ge0rG

    Interesting in the context of xmpp.net: https://bitrot.sh/post/12-12-2017-osint-ssl-on-xmpp-shodan/

  14. marc

    Ge0rG, have you thought about token expiration again?

  15. jonasw

    what’s the question about token expiration?

  16. marc

    jonasw, do they expire on generation or when they're used (account creation)?

  17. marc

    jonasw, if they expire on generation: does the server generate PARS-only tokens instead?

  18. Ge0rG

    marc: "expire" implies a time limit

  19. marc

    does the server generate no tokens at all?

  20. jonasw

    huh, how would expiration on generation work, what would that mean? they’re invalid immediately?

  21. marc

    jonasw, no, the server denies token generation of course...

  22. marc

    Ge0rG, yes, a combination of amount and time is probably the best solution

  23. marc

    however, what shall we do if a user hit this limit?

  24. marc

    +s

  25. marc

    I would prefer an error message like "You generated too many invitations. This feature will be available again on DATE"

  26. Ge0rG

    marc: as I said, I consider a limit on the _generation_ of tokens as inappropriate. I would prefer a limit on token _redemption_ instead.

  27. Ge0rG

    marc: technically, it makes sense to limit the number of pending tokens to some arbitrary but large number, like 100, to prevent the user from DoSing the server. In practice, tokens are cheap compared to roster items, avatars and picture uploads.

  28. marc

    Ge0rG, I don't care about how cheap are token generation is but about UX of the invitee

  29. Ge0rG

    marc: what about the UX of the inviter? 😝

  30. marc

    -are

  31. marc

    Ge0rG, yes, that's also important but less than of the invitee I think

  32. Zash

    They are already deep enough in XMPP that we don't care about their needs!!

  33. marc

    If you receive a token which is valid for 2 hours and use it after an hour and it doesn't work (because too many tokens were used) this looks like a broken system to the invitee

  34. marc

    And you don't want to explain why it didn't work...

  35. marc

    Also you have to store the number of used tokens for every user

  36. Ge0rG

    marc: what's the problem you try to solve with the limit on tokens?

  37. marc

    Ge0rG, too many account creations / too many invites

  38. Ge0rG

    marc: which one of those?

  39. marc

    Ge0rG, that's almost the same ;)

  40. Ge0rG

    marc: no, they are different

  41. marc

    yes, _almost_ the same ;)

  42. Zash

    Too many invites -> oh noes, XMPP is becoming too popular, better stop people!

  43. Ge0rG

    Sufficiently different to make a difference in our discussion.

  44. marc

    Given that a token should be usable if it is not expired ;)

  45. marc

    Zash, not talking about public servers here

  46. Zash

    Oh no, someone popular is inviting all their friends, better stop them!

  47. moparisthebest

    shouldn't 100 friends be enough for anyone Zash

  48. Zash

    marc: Never assumed you were

  49. Ge0rG

    Zash: "a spammer is inviting their botnet to my server"

  50. marc

    Zash, trolling is not helpful

  51. Zash

    I'm not

  52. Ge0rG

    moparisthebest: 10 friends on the free plan

  53. Ge0rG

    Zash: is it possible to disable users in prosody without deleting them?

  54. Zash

    Ge0rG: Probably useful to keep track of the tree of invitations for such events

  55. Ge0rG

    Zash: yes, very useful

  56. marc

    Zash, Okay, then you agree that limiting invitations may be useful, right?

  57. Zash

    marc: Not always.

  58. moparisthebest

    are you talking about a XEP decision or an implementation decision? this sounds like clearly an implementation decision

  59. marc

    Zash, I said "may be useful"

  60. marc

    You don't have to use this option

  61. Ge0rG

    moparisthebest: about how to allow that decision within the XEP

  62. marc

    But there are good reasons for it

  63. Zash

    I haven't followed this that closely tho. Limits on which dimentions exactly?

  64. Zash

    Account creations per invite/token? Tokens per user? Per time?

  65. marc

    Zash, oh come on... but your first reaction is "Too many invites -> oh noes, XMPP is becoming too popular, better stop people!"

  66. Ge0rG

    Zash [16:06]: > Account creations per invite/token? Tokens per user? Per time? This is exactly what I want to know, too

  67. moparisthebest

    and that's exactly why it should be an implementation decision

  68. Ge0rG

    marc: so now what's your user story for limitations?

  69. moparisthebest

    XEP should just say 'server can refuse to supply more tokens with reason'

  70. marc

    Yes, to me it's an implementation decision.

  71. Zash

    marc: What I mean is, putting limits in place that prevents someone from getting all their friends into XMPP might not be in our best interest, assuming we want XMPP to be popular.

  72. marc

    Zash, but some server operators don't want to have 10000 users

  73. marc

    Zash, that's the reason

  74. Zash

    But then, artificial scarcity could possibly drive up the percieved value of an account

  75. marc

    if you run a public server you don't have to care about it and just open it

  76. Ge0rG

    marc: if it's a server implementation decision, it has no place in the XEP 😛

  77. Zash

    Should be up to local policy, probably

  78. marc

    Ge0rG, the limitation (how many tokens per user, per time, etc.) should be implementation defined

  79. marc

    Ge0rG, we have to decide how to inform the user in a proper way

  80. Ge0rG

    marc: "with an appropriate error response"

  81. Zash

    If there's a TTL involved, is it not up to the UI to be clear about that?

  82. Zash

    "This is a time limited offer, get them while their hot!"

  83. marc

    Ge0rG, exactly :) But _when_, that's the point. You want to throw an error on account creation. I would throw it on token generation

  84. Ge0rG

    marc: these are different limits.

  85. marc

    Ge0rG, so you want to make this also implementation defined?

  86. Zash

    If tokens expire, how would you communicate that except when it is used?

  87. Ge0rG

    marc: no. I want to say you can't avoid errors on account registration

  88. marc

    Zash, for token expiration that's okay

  89. Zash

    If the user who created it is still around, they could possibly be notified

  90. marc

    Zash, but if your tokens are valid for 2 hours and don't get accepted because of some other reaons this is confusing

  91. Ge0rG

    marc: but token lifetime is not communicated to the user!!!

  92. marc

    Ge0rG, why?

  93. Zash

    Which user?

  94. marc

    Ge0rG, should be

  95. Ge0rG

    marc: how?

  96. Ge0rG

    Zash: neither

  97. Zash

    Suppose you could stick a date/timestamp in the token

  98. marc

    Ge0rG, landing page for example?

  99. marc

    You could also apply it as parameter to the URI

  100. Ge0rG

    marc: the landing page is not hosted by the xmpp server, and URL parameters can be manipulated

  101. marc

    Ge0rG, the server can provide a URL

  102. marc

    manipulating the expiration date?

  103. marc

    Are you serious?

  104. marc

    Nobody cares because it is checked by the server anyway

  105. marc

    An expiration date in the URI is the most uncritical part

  106. Ge0rG

    marc: only half-serious.

  107. moparisthebest

    actually is it defined what the URL looks like or contains?

  108. moparisthebest

    might be nice if the server doesn't have to actually store anything

  109. marc

    moparisthebest, no

  110. moparisthebest

    is that up to implementation then?

  111. marc

    depends on what web site do you use

  112. marc

    In my ejabberd implementation you can generate an URL with the invitation token and URI as parameter

  113. marc

    like url: "https://example.com/i/@URI@" or url: "https://example.com/i/@TOKEN@"

  114. marc

    It's up to example.com then how to display the invitation

  115. moparisthebest

    but who invents the URL ? (along with any parameters)

  116. marc

    moparisthebest, what do you mean by "invents the URL"

  117. moparisthebest

    can the URL be https://example.com/i/terrible.php?auth=thaeoutinhtneoauh&timestamp=445456456546&inviter=bob@bob.com&tons_of_other_vars=1

  118. marc

    Of course

  119. moparisthebest

    so the URL is generated by the server and is implementation defined, good

  120. marc

    It's a configuration parameter of the server

  121. Ge0rG

    moparisthebest: that's possible, but I could intercept your invitation link and manipulate the params

  122. Ge0rG

    moparisthebest: also: long links suck.

  123. marc

    +1

  124. moparisthebest

    Ge0rG, that's what the HMAC is for :P

  125. marc

    moparisthebest, and how do you verify it?

  126. Ge0rG

    moparisthebest: your server could just generate an encrypted & signed token that's passed on.

  127. moparisthebest

    the reason I ask is because I like the concept of https://modules.prosody.im/mod_http_upload_external.html

  128. moparisthebest

    so that your xmpp server and your web server don't need to talk, and you don't need to store anything

  129. moparisthebest

    they simply share a secret key and done

  130. marc

    You could do this

  131. marc

    But that's out of scope here

  132. moparisthebest

    yep excellent, just wanted to ensure you could do it :)

  133. marc

    At least in my opinion

  134. Ge0rG

    moparisthebest: the invitation token is opaque for the client and can contain anything you want.

  135. moparisthebest

    the URL you mean? that's mainly what I was getting at

  136. Ge0rG

    moparisthebest: it could be a base64-encoded zlib compressed collection of Shakespeare.

  137. Ge0rG

    moparisthebest: the URL should not be the primary means, if the receiver already supports xmpp: URIs

  138. moparisthebest

    ok, cool, that still works

  139. Ge0rG

    moparisthebest: and you can encode your magic token in the xmpp: URI parameter

  140. moparisthebest

    a neat stateless format might be like base64(inviter@jid\0expiration_timestamp\0hmac)

  141. Ge0rG

    marc: so the invitee client still needs to support registration failures.

  142. marc

    Ge0rG, of course

  143. Ge0rG

    marc: so technically we don't need to encode a way to reject invitation tokes on ad-hoc

  144. marc

    Ge0rG, technically not but for UX :D

  145. Ge0rG

    marc: unless you want to limit the number of tokens, which you already agreed are cheap

  146. Ge0rG

    marc: do you think there should be a limitation on the number of PARS token?

  147. marc

    Ge0rG, I don't see a reason for PARS token but maybe there are some

  148. marc

    Ge0rG, PARS tokens are not that critical I think

  149. Ge0rG

    marc: the IBR tag is a nice-to-have additional feature on top of PARS. If the server is out of invitation codes, I think it makes for a better UX to skip the ibr invitation and to fallback to plain PARS than to break the complete invitation flow

  150. marc

    Ge0rG, plain PARS is client-side PARS, right?

  151. Ge0rG

    marc: no, plain PARS is PARS without ibr support

  152. Ge0rG

    marc: but server-side

  153. marc

    Ge0rG, okay... yes I thought about it. Somehow it is nice but somehow ugly

  154. marc

    The nice thing is that the inviter can still invite users

  155. Ge0rG

    C: request invite token S: is the user allowed? yes -> return PARS+IBR no -> return PARS not supported -> return error C: didn't get token? Fallback to client-side PARS

  156. marc

    The bad thing is that invitees receive different invitations

  157. Ge0rG

    marc: and I think it does not make sense to limit the number of pending PARS+IBR tokens in that scenario

  158. Ge0rG

    marc: yes, unless you limit _registrations_ as opposed to _inivtations_ :P

  159. Ge0rG

    if you don't limit invitations, all invites from a user look the same

  160. marc

    Ge0rG, yes, you get confused after 30 seconds instead of 10 seconds :p

  161. Ge0rG

    marc: I don't understand

  162. marc

    Ge0rG, you get confused when the registration doesn't work instead of getting a different invitation

  163. Ge0rG

    marc: except there is no guarantee that the registration link will work

  164. marc

    Ge0rG, sounds like a broken system by design?

  165. Ge0rG

    marc: did you know that TCP is by definition a reliable protocol, and that you still can't rely on it?

  166. marc

    Ge0rG, did you know that a normal user doesn't care about technical issues? ;)

  167. Ge0rG

    marc: what's your point?

  168. Ge0rG

    marc: "inviter out of registrations" is one of many possible reasons to reject an account registration.

  169. Ge0rG

    marc: on a sane server, no users will ever run into it

  170. marc

    An invitation token MUST work if you received one

  171. Ge0rG

    marc: what if the server went down due to a nuclear bomb?

  172. Ge0rG

    still a MUST?

  173. Ge0rG

    what if the server admin was fed up by dumb arguments and shut it down?

  174. marc

    Ge0rG, well, the server wouldn't respond in this case so it's fine I think

  175. marc

    Probably the user will blame the ISP

  176. marc

    That's fine

  177. Ge0rG

    marc: "An invitation token MUST work if you received one" - there is no way on earth to enforce that.

  178. marc

    Ge0rG, I guess you know what I mean with this statement ;)

  179. Ge0rG

    marc: especially not if you issue time-limited tokens

  180. Ge0rG

    marc: I guess you don't :P

  181. marc

    Ge0rG, time limitations are known to users from many other services

  182. Ge0rG

    marc: so you agree that it's normal for a registration not to work always?

  183. Ge0rG

    normal in the sense that users will expect this to happen, from time to time

  184. marc

    Ge0rG, if the invitee followed the rules it shouldn't happen

  185. marc

    Ge0rG, and if the server is down for a minute if works after a minute

  186. Ge0rG

    marc: except the invitation email got greylisted for a day and the token expired. BOOM.

  187. marc

    And nobody has to generate an other token

  188. Ge0rG

    marc: another token wouldn't even help if the inviter is out of invitations :P

  189. marc

    Ge0rG, yes, but that's out of scope sorry

  190. marc

    Ge0rG, depends on your policy

  191. Ge0rG

    marc: my point is: you can't enforce in the XEP that an invitaiton token MUST always work.

  192. Ge0rG

    marc: and if you accept that truth, you can make the overall flow easier and more consistent by removing a corner case.

  193. Ge0rG

    namely the corner case where your server rejects/downgrade the invitation token because of some internal counter.

  194. marc

    Ge0rG, yes, you can not enforce it but we shouldn't introduce confusing behaviour on purpose

  195. Ge0rG

    marc: I think it's more confusing if your server returns different invitations based on how often you asked

  196. marc

    Ge0rG, yes, let's block it completely then :D

  197. Ge0rG

    marc: I think it's more confusing if your server returns different responses based on how often you asked

  198. marc

    Ge0rG, I don't agree with this statement if you throw a warning or an error or something like that

  199. marc

    Ge0rG, and if you think that's confusing to the user if they receive different invitations you shouldn't implement client-side PARS as fallback :D

  200. marc

    +it

  201. Ge0rG

    marc: users get confused by different UI flows, not by different URLs.

  202. marc

    Ge0rG, UI flow for client-side PARS is different because you can not create an account for some reason

  203. Ge0rG

    marc: let's assume for a moment that you MUST limit the number of new accounts invited by a given user. Then you will have one confusing UX, either on invitation token generation or on account creation. But the latter only happens if the receiver doesn't have an XMPP account yet and if other people who got invitations didn't use them.

  204. Ge0rG

    marc: you can create an account, just not with the inviter's server.

  205. marc

    Ge0rG, " if other people who got invitations didn't use them"? -> "if all other people who got invitations use them"?

  206. Ge0rG

    marc: correct

  207. marc

    Ge0rG, sounds unpredictable for the invitee to me

  208. marc

    And still you have to track the tokens after account creation

  209. marc

    Or at least some counter for a user

  210. Ge0rG

    marc: you have to anyway

  211. marc

    Ge0rG, no, just store the token. If an account is created, remove it

  212. marc

    No other information is needed

  213. Ge0rG

    marc: what if the account registration would trigger another limit?

  214. marc

    Ge0rG, what limit?

  215. Ge0rG

    marc: total number of registrations per day for example

  216. marc

    Ge0rG, that should be included in the account/token generation process

  217. marc

    Ge0rG, of course you can configure your service for bad UX ;)

  218. marc

    I think an account token should be considered as already registered account

  219. marc

    For the "account limitation policy"

  220. Ge0rG

    marc: I disagree

  221. Ge0rG

    marc: an account-invte token is as good as an already registered account, but a PARS+IBR token is just an option

  222. Ge0rG

    you can short-sell options

  223. marc

    Ge0rG, correct, but account invitations shouldn't be blocked by other rules once they are issued IMO

  224. Ge0rG

    marc: yes, but account invitations are created by admins anyway.

  225. marc

    Ge0rG, we're talking about account invitations+PARS ;)

  226. marc

    I think you know this ;)

  227. Ge0rG

    marc: wait a moment. I was talking about contact invitations with IBR-fallback

  228. marc

    Ge0rG, hm?

  229. marc

    IBR = account invitation

  230. Ge0rG

    marc: account-invitation = server-admin sends xmpp://newuser@server?token to make the invitee register an account

  231. Ge0rG

    marc: contact-invitation = normal user sends xmpp:inviter@server?token;ibr to allow either contact subscription or IBR

  232. marc

    Ge0rG, IBR-fallback = invitier gives invitee the possiblity to create an account even if the server doesn't allow IBR, right?

  233. Ge0rG

    marc: right

  234. marc

    Ge0rG, yes, we're talking about the same thing with different terms :D

  235. Ge0rG

    marc: so you are talking about IBR-fallback?

  236. Ge0rG

    a.k.a. PARS+IBR

  237. Ge0rG

    a.k.a. contact-invitation

  238. marc

    Ge0rG, yes

  239. Ge0rG

    marc: so with the contact-invitation, there are two possibilities: either the invitee already has an account or not. In the first case, obviously, there is no need to block an "account slot" for them

  240. marc

    Ge0rG, if you think client-side PARS fallback doesn't change the UI, PARS+IBR to PARS fallback (both server-side) doesn't change the UI too

  241. marc

    So we have no problem actually

  242. Ge0rG

    marc: client-side PARS fallback performs exactly the same task, just at different places.

  243. Ge0rG

    marc: server-side PARS+IBR vs PARS-only has different implications

  244. Ge0rG

    marc: I'm just saying that it's better to overissue tokens and to limit at the moment of registration, than to run out of tokens even though the ones you issued will never be used

  245. Zash

    Ge0rG: Huh, only the admin can give out invites?

  246. marc

    Ge0rG, I know and I don't think that's good :)

  247. marc

    Zash, no

  248. Ge0rG

    Zash: only the admin can give out accounts

  249. marc

    Ge0rG, afk, just tell me why we don't use a fallback from PARS+IBR to PARS when a user reaches some IBR-invitation limit

  250. Ge0rG

    marc: because IBR-invitation limits don't make sense.

  251. marc

    Ge0rG, and explain me why we should store lots of information about users just to enforce account limitation during IBR

  252. Ge0rG

    marc: because account creation is the best moment to limit account creation.

  253. marc

    Ge0rG, why?

  254. marc

    why doesn't it make sense

  255. Ge0rG

    because until an account is created, you don't know whether it will ever be

  256. marc

    Yes, if the invitee uses PARS the inviter can issue more tokens

  257. Ge0rG

    marc: so now what you can do as the inviter depends on what your invitees do. Yay.

  258. marc

    Ge0rG, if you implement the policy that way, yes

  259. Ge0rG

    marc: that's bad UX!

  260. marc

    Ge0rG, we have two options: "bad" UX for inviter or invitee

  261. Ge0rG

    marc: that's not true. The bad UX for the invitee is inevitable

  262. Ge0rG

    marc: the good thing, it is only bad in corner cases.

  263. Zash

    Do you have like user stories written down?

  264. Ge0rG

    I'd like to write the specification down.

  265. marc

    Ge0rG, Yes, it's a corner case for both solution

  266. marc

    +s

  267. marc

    and I think for your solution additional data needs to be stored on the server

  268. Ge0rG

    marc: maybe, maybe not.

  269. marc

    Ge0rG, :P

  270. Ge0rG

    marc: you need to store a counter on the user account anyway, if you want to limit number/time

  271. marc

    Ge0rG, but that's optional

  272. Ge0rG

    and adding a counter of user-initiated IBRs is not very expensive

  273. marc

    Ge0rG, in your solution that's required

  274. Ge0rG

    marc: no, it's optional. You don't NEED to limit anything.

  275. marc

    Ge0rG, for my solution you use data which are necessary anyway

  276. Ge0rG

    marc: but your solution is limiting user behavior at the wrong end of the registration

  277. Ge0rG

    marc: anyway, that doesn't matter much for the XEP. Let's move this thing forward.

  278. marc

    Ge0rG, why doesn't it matter?

  279. Ge0rG

    marc: because it is an implementation detail, mostly.

  280. Ge0rG

    marc: we still need to write an XEP

  281. marc

    Ge0rG, yes, but I would like to have an error response for such things in the ad-hoc command

  282. marc

    That's the point ;)

  283. Ge0rG

    marc: the ad-hoc command is allowed to fail for whatever reasons deemed inappropriate.

  284. Ge0rG

    marc: with standard error messages

  285. marc

    Ge0rG, oh no.. standard error messages

  286. marc

    They're not useful at all

  287. Ge0rG

    marc: but I still am convinced that it is wrong to let it fail.

  288. Ge0rG

    So I've been writing a blog post about fighting spam today, instead of writing the invitation XEP.

  289. edhelas

    I'm planning to do another PR on 0060 in the upcoming days

  290. edhelas

    to expose the access_model tag in the metadata