XSF Discussion - 2018-06-11


  1. Ge0rG

    moparisthebest: the ideas of the GDPR are slowly making it into US state legislation... https://www.schneier.com/blog/archives/2018/06/new_data_privac.html

  2. UsL

    US should do article 13 as well. It's awesome. It'll be the best internet.

  3. Ge0rG

    Damn, 0308 is in Draft.

  4. jonasw

    what did you want to change?

  5. Ge0rG

    jonasw: the biz rules. - allow modifications from other full JIDs of the same user - say that a correction that doesn't qualify shall be displayed like a normal message

  6. Ge0rG

    jonasw: #2 is what Klaus just adressed on standards@

  7. jonasw

    > A correction MUST only be allowed when both the original message and correction are received from the same full-JID.

  8. jonasw

    oh yes, this needs fixing

  9. jonasw

    whoever thought that was a great idea... possibly due to MUC.

  10. jonasw

    I think that any message which doesn’t qualify for the business rules is displayed normally is kinda implicit

  11. Kev

    > whoever thought that was a great idea MUC, mostly, but we can loosen the words for non-MUC.

  12. jonasw

    yeah

  13. rainslide

    Why not make GDPR support into a plugin?

  14. edhelas

    if only

  15. Ge0rG

    rainslide: one can not simply module:load legal compliance.

  16. rainslide

    I don't konw my Chinese forum uses which program, it show me a GDPR just now…

  17. rainslide

    GDPR can be spreaded though software😂

  18. vanitasvitae

    <gdpr xmlns='urn:xmpp:legal:gdpr:0' compliant='true'/>

  19. MattJ

    "It showed me a GDPR just now" -> "a GDPR" is not a large pop-up

  20. Seve/SouL

    Hey kid, got GDPR?

  21. edhelas

    vanitasvitae thanks for the tip! I'll enable it in my client now

  22. Ge0rG

    GDPR is a software-transmitted disease. A so-called STD.

  23. pep.

    I guess for now we're at <gdpr xmlns='urn:xmpp:legal:gdpr:0' compliant='maybe' />

  24. Ge0rG

    My employer's website redirects you to `about:blank` if you deny the cookie popup. I was ashamed to find that out.

  25. Ge0rG

    I was even more ashamed when the DPO told me this is by design.

  26. pep.

    :(

  27. pep.

    Is it even allowed

  28. Ge0rG

    He said yes. We are not required to make business with people who don't want to be tracked.

  29. pep.

    great

  30. Wiktor

    IANAL but... > More importantly, organizations can't restrict website usability or services based on whether or not consent was granted. Source: http://www.dmnews.com/retail-week/gdpr-cookies-personal-data/article/738977/ > For example, a bank that asks for its customers’ consent to use their payment details for marketing purposes, but denies banking services or increases fees if consent is not granted, would be exerting inappropriate pressure. The GDPR does not absolutely prohibit offering services conditioned on consent to data processing, but per Recital 43, any consent so provided is presumed invalid, and the Working Party notes that “[valid] cases will be highly exceptional.” Source: https://iapp.org/news/a/top-10-operational-responses-to-the-gdpr-part-2-lawful-bases-for-processing/

  31. pep.

    Just like facebook's policy is not legal because it forces you into accepting their crap processing or nothing

  32. pep.

    But then IANAL either

  33. Wiktor

    yep, let's just prepare a lot of popcorn and see what happens to them :)

  34. daniel

    > My employer's website redirects you to `about:blank` if popup. I was ashamed to find that out. Isn't the real scandal that you can redirect to about: pages? That seems dangerous

  35. Ge0rG

    Wiktor: I agree with you here, but my two coworkers who have undergone GDPR training disagree.

  36. Ge0rG

    daniel: it's just a regular link

  37. pep.

    daniel, what's the issue with that

  38. pep.

    I can redirect you to file:///home/foo/bar, that doesn't mean I can do anything about it

  39. daniel

    pep.: I can't point my finger at something in particular. But that doesn't _right_

  40. Wiktor

    I know Ge0rG, I'm just trying to find supporting text for all these issues as I'm curious myself (but fortunately I don't have this problem now).

  41. Ge0rG

    pep.: you can check the color value of the link via JavaScript to see if you opened it in the past, and whether the file might exist :P

  42. pep.

    Ge0rG, interesting

  43. pep.

    Ge0rG, hmm, but I won't be able to do that via redirecting you there right

  44. pep.

    Ge0rG, hmm, but I won't be able to do that by redirecting you there right

  45. Wiktor

    Ge0rG: I think this was fixed in 2010: https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector

  46. Ge0rG

    There are so many things in "the web" that undermine security, we should just bury it all in Lake Karachay

  47. rainslide

    > He said yes. We are not required to make business with people who don't want to be tracked. And they hire them, sometimes.

  48. Ge0rG

    Wiktor: yes, but there is a gazillion of other side channels

  49. Wiktor

    Ge0rG: could you give an example?

  50. pep.

    daniel, what's interesting is the other way around, https://mathiasbynens.github.io/rel-noopener/

  51. Ge0rG

    Wiktor: https://arstechnica.com/information-technology/2018/05/chrome-and-firefox-leaks-let-sites-steal-visitors-facebook-names-profile-pics/

  52. Wiktor

    ah css mix-blend-mode

  53. Wiktor

    will probably be fixed just like leaking :active

  54. Ge0rG

    Wiktor: https://www.bleepingcomputer.com/news/security/css-code-can-be-abused-to-collect-sensitive-user-data/

  55. Ge0rG

    web security is a huge game of whack-a-mole. And sometimes I'm not sure if we aren't the moles.

  56. Wiktor

    isn't this true for software in general?

  57. Wiktor

    web is just "used software" and complex software so it has more vulnerabilities discovered

  58. Ge0rG

    Wiktor: software in general is doing okay, but the web is a fractal of insecurity.

  59. Wiktor

    this is just survivorship bias

  60. Ge0rG

    Wiktor: the web browser is an attempt to rebuild the desktop operating system, but with the sole intent to load and execute malicious code from third parties.

  61. Ge0rG

    it doesn't help that all three major web operating system vendors are either in the tracking-users business or paid by this business.

  62. Wiktor

    > sole intent to load and execute malicious code from third parties [citation needed]

  63. Wiktor

    the code is as malicious as any other piece of software can be

  64. Wiktor

    do you claim Firefox and Mozilla are in this just because they want you to execute "malicious code from third parties"?

  65. Ge0rG

    Wiktor: do you remember the time when famil members just downloaded random .scr files from the internet because "that screen saver was so awesome"?

  66. Ge0rG

    Wiktor: firefox ships with JavaScript enabled, so yes.

  67. Wiktor

    yep, that scr could be malicious too

  68. Wiktor

    little evil johnny castaway

  69. Ge0rG

    Wiktor: it took a while for users to learn that, the hard way.

  70. Wiktor

    and now they're learning on the web...

  71. Ge0rG

    Wiktor: but now, they are doing 90% of their work in a web browser, which is designed and optimized to load and execute malicious JavaScript

  72. Ge0rG

    Now please tell me that not all JS is malicious.

  73. Wiktor

    is it?

  74. pep. enables NoScript

  75. pep.

    Ge0rG, not all JS is malicious!

  76. Ge0rG

    Wiktor: the typical modern web page has 5kb of JS to animate the menus, which depends on 1MB of jquery, and a dozen or two of different tracking services embedded

  77. Zash

    Not all X!!

  78. Ge0rG

    And any of those tracking service may do anything to your website.

  79. Wiktor

    yes, so what? this is just bad design, last time I read ECMAScript spec it didn't require me to put trackers on my page to achieve "malicious JavaScript" badge

  80. Ge0rG

    Oh, did I mention those pages that allow third-party live bidding platforms to sell code execution rights to shady companies that will redirect you to a "YOU HAVE WON!!!111!" page, delete your back-history and deploy the vibration alert?

  81. Wiktor

    your computer allows shady things, do you consider it malicious too?

  82. Ge0rG

    Wiktor: "this is just bad design" is a statement that applies to the modern web.

  83. pep.

    Somebody mentioned Intel ME?

  84. Wiktor

    haha, yes, Intel ME

  85. Ge0rG

    Wiktor: which brings me directly back to my initial statement, which you just proved :P

  86. pep.

    And AMD's whatever

  87. Zash

    Computers are teh wurst

  88. Wiktor

    bad design on part of the site developer, you cannot claim that if your observed set is composed only out of white swans that black swans do not exist

  89. Ge0rG

    with I-ME, at least *only Intel* can execute code on my box without me knowing.

  90. pep.

    Zash, potatoes!

  91. Zash

    Let's just all become potato farmers

  92. pep.

    Ge0rG, are you even sure of that

  93. Ge0rG

    Zash: ITYM Teewurst <https://en.wikipedia.org/wiki/Teewurst>.

  94. Ge0rG

    pep.: sure of what?

  95. pep.

    *only Intel*

  96. pep.

    I mean,

  97. pep.

    Intel could proxy to third-parties. Just like these websites allows third-parties in

  98. Ge0rG

    pep.: only Intel and the state actors that coerced them.

  99. pep.

    Intel could proxy to third-parties. Just like these websites allow third-parties in

  100. pep.

    :)

  101. pep.

    Sounds better

  102. Ge0rG

    pep.: but at least they need to intercept the laptop shipping to me and inject the payload manually

  103. Ge0rG

    pep.: my laptop doesn't come asking for malware whenever I surf to a news site.

  104. Wiktor

    Intel ME can be updated though ethernet, even when the computer is powered off (but not plugged off the grid)

  105. rainslide

    > isn't this true for software in general? Maybe true for all general stuffs in large scale.

  106. rainslide

    News next decade: Intel becomes the largest tracker (?)

  107. pep.

    I bet that's already true to some extent

  108. labdsf

    I have read the logs about ephemeral messages from http://logs.xmpp.org/xsf/2018-06-07/

  109. labdsf

    Just in case, I am the author of this protoxep

  110. Ge0rG

    hey labdsf, welcome :)

  111. labdsf

    so far, the main concern is that nested <ephemeral> contents is hard to implement and does not guarantee anything anyway as some clients will store raw XML?

  112. jonasw

    hi labdsf

  113. jonasw

    labdsf, yes, that is definitely a conceprn

  114. jonasw

    labdsf, yes, that is definitely a concern

  115. Ge0rG

    labdsf: I can't speak for the other Council members; my personal concern is that it is not clear how it is supposed to work in multi-client scenarios.

  116. labdsf

    as for the threat model, it is indeed "stolen device" attack only, nothing more, all parts of the conversation trust each other

  117. Ge0rG

    labdsf: I already have a hard time removing messages from server-side MAM after 14 days ;)

  118. labdsf

    Ge0rG, timer setting synchronization part?

  119. labdsf

    or starting of the timer on the recipient side?

  120. Ge0rG

    labdsf: starting of the timer. Also, with a <no-store/> hint, the message will only be delivered to clients that are online at the time of transmission

  121. labdsf

    it is no-permanent-store in the specification, whatever it means

  122. Ge0rG

    labdsf: so if my mobile is connected at the time, it will get a copy; if it's not connected, it won't.

  123. labdsf

    and it is for plaintext only

  124. labdsf

    is there any practical difference between no-permanent-store and no-store?

  125. Ge0rG

    No idea.

  126. Ge0rG

    MAM only mentions no-store, in https://xmpp.org/extensions/xep-0313.html#hints

  127. Ge0rG

    labdsf: with the current MAM and XMPP "design", it's not possible to know when all clients have received a given message, so no-permanent-store doesn't make much sense

  128. labdsf

    according to https://xmpp.org/extensions/xep-0334.html#no-permanent-store , no-permanent-store messages should not be stored in MUC

  129. labdsf

    MAM*

  130. Holger

    Yes the idea is "only in the offline spool".

  131. labdsf

    so if no client is offline, it will be stored for offline delivery

  132. Ge0rG

    So it still breaks the multi-client use case.

  133. Holger

    Yes.

  134. Ge0rG

    MattJ had a nice idea to keep a per-client offline spool, backed by the MAM store. That would break as well.

  135. labdsf

    it does not break it completely, but we need a better replacement for offline message delivery than MAM for it to work

  136. labdsf

    so each device can register on the server and have its own message queue

  137. labdsf

    when all devices got the messages, they are removed

  138. Ge0rG

    labdsf: yes, that would be great. Except if you drop your device into a beer keg and messages for that device get stored forever.

  139. Holger

    Ge0rG: I'd burn no-permanent-store with fire, but as you recently told me hints were burnt down altogether anyway.

  140. labdsf

    Ge0rG, unregister it after 2 weeks of inactivity

  141. Ge0rG

    labdsf: not a bad idea

  142. Ge0rG

    But we aren't there yet.

  143. Ge0rG

    Maybe we can fix it with IM-NG

  144. labdsf

    Signal actually has this model, it allows you to register the first device with SMS, then register additional devices using already registered one

  145. labdsf

    device is unregistered after one week

  146. Ge0rG

    I thought Signal has a single-device model?

  147. labdsf

    no

  148. labdsf

    it is WhatsApp that has single-device

  149. Ge0rG

    We need to establish a device-registration XEP.

  150. labdsf

    Signal allows you to register the phone with SMS, then register desktop by scanning its QR code, then shutdown the phone and use desktop

  151. Ge0rG

    Until then, I just use the resource string as a device identifier.

  152. edhelas

    labdsf afaik, you can't shutdown the phone no

  153. Ge0rG

    labdsf: and the desktop is a full device, like the phone is?

  154. labdsf

    yes

  155. edhelas

    because the phone is just acting a a proxy for the desktop

  156. labdsf

    edhelas, you are talking about WhatsApp

  157. edhelas

    ah yeah sorry

  158. labdsf

    Signal is different, you can shutdown the phone

  159. Ge0rG

    What a feature.

  160. labdsf

    WhatsApp starts displaying the message that your phone has disconnected above the "roster"

  161. labdsf

    I think we can postpone implementation of plaintext ephemeral messages or at least disable them by default until we have better Signal-like offline message delivery

  162. Zash

    "Signal-like" means?

  163. labdsf

    multiple queues, one per device

  164. labdsf

    messages are removed as soon as you download them

  165. Zash

    Ugh

  166. labdsf

    or after one week if you don't

  167. Zash

    .... isn't that because it doesn't support multiple devices?

  168. Ge0rG

    labdsf: another point: I can see why you wrapped the <body> into <ephemeral>, but I'm not convinced of this approach. It will interact in non-obvious ways with things like OMEMO

  169. labdsf

    it does, I just described above

  170. labdsf

    Ge0rG, in case of OMEMO you place <encrypted><payload>...</payload>...</encrypted> inside <ephemeral>

  171. edhelas

    we need to go deeper

  172. Ge0rG

    labdsf: yes; so you need to parse <ephemeral> for everything that's allowed in a <message>, except with a timer attached.

  173. Ge0rG

    labdsf: what if I send a Read Marker inside <ephemeral>? Will the conversation show up as un-read after the time?

  174. Ge0rG

    or is there a white-list of tags that are allowed inside of <ephemeral>?

  175. labdsf

    I expect that <ephemeral> is only used when you explicitly send a message

  176. Ge0rG is a corner case specialist.

  177. Ge0rG

    I should get that printed onto my business cards, to give people a fair advance warning.

  178. MattJ sends Ge0rG inside an <ephemeral>

  179. Ge0rG

    MattJ: so what's my TTL, then?

  180. MattJ

    integer overlow

  181. Ge0rG

    MattJ: do you have the eyes of a Shinigami?

  182. MattJ

    integer overflow

  183. labdsf

    As mentioned in https://xmpp.org/extensions/inbox/omemo-media-sharing.html we already have https://xmpp.org/extensions/xep-0373.html that does stanza encryption

  184. labdsf

    <ephemeral> is no different from <openpgp> except that content is not encrypted

  185. labdsf

    but then we can have <ephemeral><openpgp><ephemeral>... which will be hard to implement if OpenPGP is a plugin

  186. labdsf

    various plugins trying to wrap the messages in unspecified order will be a problem

  187. Ge0rG

    And then all that is wrapped in <forwarded><sent> to your mobile device.

  188. Ge0rG

    > https://xmpp.org/extensions/inbox/omemo-media-sharing.html Please don't even get me started about `if (message.startsWith("aesgcm://")) { ... }`

  189. Ge0rG

    and what is an "OMEMO message"?

  190. Ge0rG

    daniel: what were you smoking?

  191. Ge0rG

    I mean, I can understand how this results from "we don't need to wrap anything but the <body> into OMEMO".

  192. labdsf

    in any case, if you *receive* an ephemeral read marker, the conversation becomes read and the marker is not stored in logs

  193. Ge0rG

    And there is certain merit in producing working code over good specifications; but now might be a good time to rewind and fix this.

  194. jonasw

    Ge0rG, if this is about encrypting whole stanzas, yeah, let’s do that.

  195. Ge0rG

    labdsf: but then later the conversation needs to become un-read again when the marker times out, right?

  196. jonasw

    but I heard it’s not as easy as you’d think

  197. labdsf

    Ge0rG, no

  198. Ge0rG needs to invent some other interesting corner cases.

  199. labdsf

    it just becomes read forever

  200. Ge0rG

    ephemeral Pubsub posts!

  201. MattJ

    I like the idea of being able to temporarily correct messages

  202. edhelas

    Ge0rG it already exists, it's called PEP with one item per node :p

  203. MattJ

    It's called restarting Prosody

  204. Kev

    MattJ: What about temporarily adding a reference to a message?

  205. Ge0rG

    MattJ: thanks for making me sad.

  206. edhelas

    MattJ +1 :D

  207. MattJ

    Probably making Link Mauve sad, he already implemented persistence :)

  208. Ge0rG

    in trunk?

  209. MattJ

    In trunk

  210. Ge0rG

    I'm running two dozens of half-baked half-broken half-experimental modules on my server, I can't upgrade to trunk!

  211. daniel

    > And there is certain merit in producing working code over good specifications; but now might be a good time to rewind and fix this. If you read the entire xep the introduction clearly states that

  212. Ge0rG

    daniel: touché

  213. pep.

    Ge0rG, I'm sure you can upgrade to trunk and still benefit from another dozen of half-baked half-broken half-experimental modules :P

  214. edhelas

    all our projects are not half-baked half-broken half-experimental in the end ?

  215. Ge0rG

    pep.: maybe, but I don't want to introduce even more half-baked-ness.

  216. labdsf

    Ok, so to summarize, I need to 1) add threat model to "security considerations" 2) write "implementation notes" that say plaintext ephemeral messages should be disabled unless the server advertises reliable no-permanent-store offline message delivery mechanism 3) think about moving message contents outside the <ephemeral> if it makes implementation too complicated

  217. labdsf

    Ge0rG, by the way it does not matter whether you place chat state notification inside <ephemeral> or outside of it as long as <ephemeral> is present in the message

  218. labdsf

    what is the procedure to update ProtoXEP? Just sumbit a pull request?

  219. jonasw

    labdsf, there is not really a procedure. you can submit a PR, yes, I’ll merge the update.

  220. jonasw

    unfortunately. I would prefer if that happened under Experimental, because there *is no procedure* for anything there.

  221. jonasw

    I won’t send an update email for example like I’d do for Experimental XEPs

  222. labdsf

    hmm

  223. Ge0rG

    jonasw: the XEP was rejected

  224. jonasw

    but the war on whether we want to "have XEPs in Experimental early and develop there" or "ProtoXEPs must be very promising / very good to accept" is not fought out yet

  225. jonasw

    Ge0rG, I am aware

  226. jonasw

    Ge0rG, what are you telling me?

  227. jonasw

    you saying I should reject the update on that ground?

  228. Ge0rG

    so it's hanging around in inbox now, and I suppose it could get the PRs applied and the author could kindly ask the editot to resubmit it for a vote

  229. Ge0rG

    or the Council.

  230. jonasw

    exactly

  231. jonasw

    that’s what’s effectively happening whenever things in inbox get updated

  232. Ge0rG

    labdsf: so please make a PR to address all Council issues

  233. Ge0rG

    labdsf: and then let us know

  234. Kev

    > but the war on whether we want to "have XEPs in Experimental early and develop there" or "ProtoXEPs must be very promising / very good to accept" is not fought out yet It is, though.

  235. jonasw

    it comes up on the list about once a month, doesn’t it?

  236. Kev

    Usual criteria for Experimental is only "Not obviously wrong", "Confusing as hell" or "duplicating existing stuff for no good reason".

  237. jonasw

    soo... if I have a XEP which is very confusing and duplicates everything, I’m in? ;-)

  238. Kev

    Certainly noting as much as 'must be very good or very promising' has ever been enforced, of which I'm aware.

  239. Kev

    Yes, that's exactly what I meant, of course :p

  240. jonasw

    sorry, I had to take that one after I had a similar negation issue the other day on the same topic:)

  241. labdsf

    Ge0rG, we cannot use resource string as device identifier, sadly

  242. jonasw

    labdsf, why?

  243. labdsf

    Gajim by default has $rand part that is regenerated on each connection

  244. jonasw

    yeah, gajim needs fixing then :)

  245. labdsf

    maybe

  246. labdsf

    if all major clients are fixed to use somewhat permanent resources, it may be easy enough to implement offline message queues in prosody

  247. jonasw

    labdsf, MattJ is working on that, kinda

  248. jonasw

    regarding fixing clients, please file issues

  249. goffi

    why a client should have a permanent resource ? I thought it was seen as bad practice at some point. And using resource to identity a client doesn't smells like a good idea.

  250. labdsf

    goffi, we need to understand why is it a bad practice

  251. goffi

    if it's needed, a random ID generated once by client and put in some disco sounds better to me.

  252. labdsf

    my guess is that using non-random is a bad practice, not permanent

  253. labdsf

    because you may want to use to Gajims, for example

  254. Zash

    Fixed strings like "Gajim" or "Conversations" or "mobile" are meh.

  255. goffi

    would be nice to have some input on that, SàT is also using random resource by default (well, actually resource chosed by server).

  256. jonasw

    goffi, like Zash says, a *predictable* string is bad. a string which identifies a client (of a user) uniquely (but unpredictably) is good

  257. jonasw

    so gajim-dg6jqVpjVI6, generated once at account setup, is good

  258. jonasw

    it helps the server re-identify the client right after bind

  259. goffi

    Zash: I actually find handy to have something like "mobile" when I want to access this device directly, why would is it bad ?

  260. jonasw

    goffi, you can detect the mobile-ness of a device via disco#info

  261. jonasw

    parsing the resource string is awful for that

  262. Zash

    jonasw: lets me guess it and send stuff directly to your phone. also you'll have a bad time if you ever get a second phone

  263. goffi

    jonasw: yes, but if I have several mobiles, and I want to retrieve picture from one in particular ?

  264. jonasw

    goffi, disco#info can have names in it

  265. jonasw

    allow users to set proper disco#info names

  266. jonasw

    (and default them to something sensible)

  267. goffi

    hum, disco#info can be nice indeed

  268. jonasw

    and the name can even be internationalised!

  269. goffi

    in resource too

  270. jonasw

    no

  271. jonasw

    you can only have one resource

  272. jonasw

    but you can have many <identity/> items, one for each language

  273. goffi

    ah ok, I thought you were thinking about non ascii chars.

  274. goffi

    anyway, a XEP or something official givin advices on resource chosing would be a good think.

  275. jonasw

    true

  276. jonasw

    an Informational document would be good

  277. Ge0rG

    goffi: I've written out the arguments for a prefixed random-on-account-creation resource string numerous times in the past, including the "human readable for debugging" argument

  278. jonasw

    Ge0rG, copy & paste your arguments into a XEP template?

  279. goffi

    Ge0rG: where ?

  280. Ge0rG

    Hm.

  281. Ge0rG

    I'm using `yaxim.32bithexrnd` since the first user reported an issue with a second device running yaxim, which was ages ago.

  282. daniel

    32 bits?

  283. daniel

    That seems like a lot

  284. labdsf

    I would like it to behave like DHCP, server selects a resource for you (or you select random with prefix for the first time), then you request the same resource on reconnection

  285. Ge0rG

    goffi: on standards@, mostly. The last time in the context of bind2, where the `uuid4/uuid4` resource string scheme was proposed.

  286. jonasw

    labdsf, you can have that by not specifying a resource on the first connect

  287. jonasw

    the server has to assign one to you then

  288. labdsf

    jonasw, the problem with Gajim is that it does not remember it

  289. jonasw

    sure, gajim needs fixing

  290. labdsf

    ok, I will file an issue

  291. Ge0rG

    daniel: maybe. I didn't do the math regarding the birthday collision phenomenon

  292. jonasw

    32 bit are just 8 characters of hex. that seems good to me

  293. goffi

    Ge0rG: would be nice to put in a protoXEP, it's hard to follow every discussions in MUC + mailing list + github issues now, specially for devs like me which are working on their free time.

  294. labdsf

    32 bit is what OMEMO uses

  295. jonasw

    I‘d probably do base64 instead.

  296. labdsf

    for device id

  297. jonasw

    goffi, which github issues?

  298. daniel

    jonasw, i use 3 bytes in base64. thats short enough that an advanced user (doing debugging or what ever) can still remember it

  299. goffi

    jonasw: I think discussions happens there sometimes, if not that's good news

  300. jonasw

    goffi, not on the xeps repository (not on my watch at least)

  301. jonasw

    if you spot technical discussion there, feel free to alert me or another editor

  302. jonasw

    because I find that awful, too, and we agreed to remind people to move the discussions to standards@

  303. goffi

    good then

  304. jonasw

    daniel, right

  305. Ge0rG

    daniel: I remember being confused by the special characters in a conversations resource. Also, I wonder if there are case insensitive servers out there

  306. jonasw

    Ge0rG, they’d be in violation of RFC 6122 then

  307. jonasw

    burn them

  308. daniel

    Ge0rG: well if there are they should reread the rfc

  309. jonasw

    Ge0rG, which special characters though? base64 is just a-zA-Z0-9

  310. daniel

    jonasw: plus two more

  311. jonasw

    oh right

  312. jonasw

    (three if you count the padding)

  313. daniel

    With three bytes you don't have padding

  314. jonasw

    true

  315. Ge0rG

    I'd actually rather use a password generator for the resource

  316. jonasw

    something like "commissions beer respite"?

  317. Ge0rG

    Did I say "passphrase"?

  318. labdsf

    jonasw, you mentioned MattJ is working on something (premanent resources? message queues?), where can I read about it?

  319. Zash

    Can you read minds?

  320. labdsf

    I guess it is offline message queues in prosody

  321. Ge0rG

    Zash [18:31]: > Can you read minds? Is there an XEP for that?

  322. pep.

    labdsf, there was some mention of that on this channel iirc, and maybe also on prosody@

  323. MattJ

    Ge0rG, https://xmpp.org/extensions/xep-0183.html

  324. MattJ

    labdsf, there's nothing to read, just reworking the message delivery logic in Prosody. No XEP because no protocol changes (we have all the protocols we already need)

  325. labdsf

    MattJ: What is the change in delivery logic? Will no-permanent-store offline messages be stored for some time for recently seen resources?

  326. MattJ

    Yes

  327. MattJ

    Probably no-permanent-store will be ignored for the most part, in preference to delivering the message to all known devices

  328. labdsf

    I would like to disable MAM completely. As a workaround I have it store messages for a week and in-memory only.

  329. Ge0rG

    Tedd has a very interesting reading of the LMC rules

  330. MattJ

    I really dislike the idea of MAM (I don't run it on my own server)

  331. MattJ

    I wrote the XEP, and intended it to cover multiple use cases, but I should clarify that it's the "store everything forever" thing that people seem to have interpreted it as that I don't like

  332. labdsf

    MattJ: as I understand it, no-store is "deliver to online clients only", no-permanent-store is "no MAM, store for some time in memory for clients that are likely to reconnect in a few days", store is "store in MAM permanetly until it is removed by some internal logic".

  333. MattJ

    The stuff I'm working on auto-deletes messages once they have been received by all devices

  334. MattJ

    Regardless of what hints are in the message

  335. labdsf

    So you sort of ignore no-store and make it work like no-permanent-store

  336. labdsf

    And store does not work because MAM is disabled

  337. Ge0rG

    Funny how everybody involved in xmpp software runs their own custom configuration that's incompatible to the preached best practices and to everybody else's

  338. MattJ

    Ge0rG, you think I'm preaching that people should have MAM enabled and store everything forever? :)

  339. Ge0rG

    MattJ: you wrote the XEP. And MAM support is demanded by at least one modern client.

  340. MattJ

    labdsf, I'm breaking stanzas into three categories: [deliver to all], [deliver to all online], [deliver to single resource]

  341. Ge0rG

    I'm running my secondary clients with negative priority to avoid them consuming messages when the primary client is offline.

  342. Ge0rG

    MattJ: the preaching statement was not related to you personally, just to what the xsf says

  343. MattJ

    Ge0rG, the XSF preaches? :)

  344. labdsf

    I would like to have two options: with MAM (Telegram-like, local archive acts like cache and can be pruned anytime) / without MAM (client has to store all messages locally)

  345. Zash

    birdsite.tld/shitxsfsays

  346. labdsf

    the fact that MAM became an offline message delivery mechanism is a bug

  347. labdsf

    especially with OMEMO, when messages are sent with <store/> but cannot be decrypted more than once

  348. labdsf

    and server stores permanently encrypted messages that nobody can decrypt

  349. Ge0rG

    labdsf: congratulations, you just discovered the mess that multi device xmpp is.

  350. MattJ

    labdsf, pretty much agree

  351. MattJ

    which is why I'm taking a step back and rewriting our code like it's 2018

  352. Ge0rG

    If I weren't on mobile I'd give you the link to the presentation listing this and many other issues

  353. Ge0rG

    Per device offline message queues would actually be a reason for me to upgrade prosody to trunk

  354. labdsf

    Ge0rG, but it seems pretty easy to fix (from the protocol point of view, not sure about implementation), just add semi-permanent resources and store messages for some time

  355. Ge0rG

    labdsf: Yeah. Except it was a hard fight to convince a small subset of the xmpp community that permanent resources are a good and not a bad thing

  356. labdsf

    resource is a part of URL, it is there for IoT applications from the start, how non-permanent resource is of any use?

  357. labdsf

    IoT was not that popular buzzword than, but something like that was considered when resources were added I think

  358. labdsf

    you connect a device, assign it a resource and then it is available by permanent URL

  359. Ge0rG

    labdsf: don't ask *me* about that

  360. labdsf

    MattJ, if MAM is enabled, messages are stored even if they have been received by all devices I guess?

  361. labdsf

    one reason for MAM to exist is when you want to connect a new device later

  362. MattJ

    There will be a setting (disabled by default) to control storage of messages for longer periods

  363. labdsf

    Signal solves this problem by synchronizing messages device-to-device, but that would require an entire new specification

  364. MattJ

    e.g. "store for at least 7 days"

  365. MattJ

    It wouldn't require much more of a specification than one that says clients can optionally enable other clients to speak XEP-0313 to them

  366. MattJ

    Even if it only supported a limited subset (give me everything after id X)

  367. MattJ

    Probably a trivial operation for most clients

  368. Holger

    Is the plan to (re)construct carbons of outgoing messages while delivering per-device offline messages?

  369. labdsf

    https://dev.gajim.org/gajim/gajim/issues/9193

  370. pep.

    "so offline messages will be stored for longer than needed and not delivered to the client." how would they not be delivered to the client?

  371. pep.

    Are we not delivering everything to every clients nowadays

  372. Ge0rG

    MattJ: that would make for a nice and secure UX as well. "Conversations on Android asked to obtain your message history. Yes / No"

  373. Holger

    pep.: No idea but presumably the server would only deliver offline messages when a known resource reconnects.

  374. Holger

    Gajim would just fetch them from MAM of course.

  375. pep.

    So if I disconnect all my resources and connect with a new one (new client), I'll never receive these only messages? :/

  376. pep.

    hmm

  377. pep.

    *offline messages

  378. Holger

    pep.: Well dunno about the Prosody plans. But otherwise you'd receive the full MAM archive without any paging whenever you log in with a new resource I guess?

  379. labdsf

    pep., well, if MAM is not available, and two clients are connected ("Mobile" and "Gajim.foo"), then "Gajim.foo" disconnects, then a message is received, then "Gajim.bar" connects, a message will be stored for "Gajim.foo" and not delivered to "Gajim.bar"

  380. labdsf

    "Mobile" will receive the message because it was online

  381. pep.

    And if Mobile wasn't connected

  382. labdsf

    then "Gajim.bar" will probably receive the message

  383. pep.

    I like the certainty of that sentence

  384. Holger

    I wonder whether clients that don't implement MAM get deduplication right ...

  385. labdsf

    well, according to https://xmpp.org/extensions/xep-0160.html it will be Gajim.bar only

  386. Zash

    Does anyone get deduplication right?

  387. labdsf

    "the server delivers the message to the resource that has sent that presence"

  388. labdsf

    Zash, just remove messages with the same ID, I think Xabber does this

  389. Holger

    Yes, shouldn't be hard if you rely on stanza IDs. We ran into the dedup mess because we didn't have them until recently.

  390. Holger

    While I'm not convinced you're improving the UX with clients that *don't* support carbons and proper dedup of you start sending them incoming messages received by other clients.

  391. Holger

    s/of/if/

  392. Ge0rG

    labdsf: let me tell you about https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat#Matching_Your_Reflected_Message

  393. Ge0rG

    Zash: yaxim does deduplication right, but it doesn't support MAM.

  394. labdsf

    pep., I have updaet issue https://dev.gajim.org/gajim/gajim/issues/9193 with an expanded example

  395. daniel

    labdsf, resources in Conversations are only semi-stable fwiw

  396. daniel

    i support gajim (and other clients) using semi stable (but randomized) resources but i don’t think relying on them is a good idea

  397. Andrew Nenakhov

    I like resources with human-readable parts.

  398. labdsf

    daniel: how can we not rely on stable resources to identify clients?

  399. labdsf

    We can make clients advertise that they have stable resource to avoid storing messages for randomized ones

  400. jonasw

    MattJ, if you don’t want to mean something "store everything forever", calling it "archive" was probably not smart :)

  401. labdsf

    But I think it is easier to just fix major clients

  402. daniel

    i’m not even sure a client can guarantee that…

  403. jonasw

    daniel, to a local server it can

  404. Zash

    It can't. Server has final say in what resource is used.

  405. daniel

    what zash said

  406. daniel

    even though a client could end the stream if the server doesn’t provide the resource it wants

  407. daniel

    but that’s borderline insane

  408. jonasw

    what I meant was: if a users server wants to make use of that property for that users clients, having the client advertise it makes sense. because if the server allows, the client can guarantee it.

  409. jonasw

    (to the extent that it makes sense, after a disk wipe it obviously can’t)

  410. labdsf

    There is no problem, if the server implements offline message queues, it has to provide stable resources

  411. labdsf

    No need to think about the case when server does not

  412. daniel

    labdsf, since i missed half the discussion; this is all in an attempt to make self destructible messages work?

  413. labdsf

    In attempt to make offline messages work without MAM, unrelated work in prosody

  414. jonasw

    Ge0rG, what did you mean by "password generator" for the random resource thing?

  415. labdsf

    But that would help make plaintext ephemeral messages usable, which are not in their current state

  416. labdsf

    OMEMO ephemeral messages are already ok I think, I just need to move the payload out of the <ephemeral> tag

  417. Ge0rG

    jonasw: something like https://github.com/pfleidi/yaxim/blob/master/src/org/yaxim/androidclient/util/XMPPHelper.java#L126 but with a-zA-Z0-9 only

  418. labdsf

    So the core functionality is advertising ephemeral message support in device bundle and sending OMEMO ephemeral messages

  419. Ge0rG

    it doesn't *need* to be exactly N bits of entropy

  420. jonasw

    Ge0rG, soo... how’s that different from get_random_bytes(3) | base46?

  421. jonasw

    Ge0rG, soo... how’s that different from get_random_bytes(3) | base64?

  422. jonasw

    except for / and -

  423. Ge0rG

    jonasw: exactly. / and -

  424. jonasw

    what’s the isuse with that?

  425. Ge0rG

    jonasw: because you don't want to have a / in your resource when bind2 strikes

  426. jonasw

    why not?

  427. labdsf

    That was my proposal before discussion, then it was extented to plaintext and OpenPGP which we have to postpone until no-permanent-store can be supported

  428. jonasw

    (and then I can still move to urlsafe…)

  429. daniel

    Conversations uses url safe (- and _) by the way

  430. jonasw

    Ge0rG, my understanding was that it was supposed to be <server part>/<client part> anyways

  431. jonasw

    but whatever, I’ll use urlsafe then

  432. daniel

    not because i’m afraid of bind2 but because it looks nice

  433. daniel

    labdsf, in my experience most clients that implement self destructible messages use omemo anyway

  434. daniel

    (and are single device only most of the time)

  435. Ge0rG

    daniel: was C using url-safe b64 from start on?

  436. daniel

    yes

  437. Ge0rG

    daniel: because I could *bet* I've seen a C with a / in the resource.

  438. daniel

    (start=when it starting doing the random url part thing)

  439. Ge0rG

    jonasw: how much would you bet on nobody ever implemeting resource.split("/")[0] and [1]?

  440. jonasw

    Ge0rG, https://github.com/jabbercat/jclib/compare/07c2589edf5b7d0a23124ace78477a38e0145f44...46433e394ba6bbc8d5209a93cdd62b34b4af1043

  441. jonasw

    Ge0rG, as someone who recently fixed their JID implementation to interpret domain/resource correctly, I say they shall burn in hell

  442. Ge0rG

    jonasw: 👍

  443. jonasw

    Ge0rG, as someone who recently fixed their JID implementation to interpret domain/resource/with/slash correctly, I say they shall burn in hell

  444. labdsf

    daniel: I am in the process of fixing the ProtoXEP to make it clear that everything outside OMEMO should be hidden from the user behind the "i know what I am doing" checkbox, and start writing the code by implementing ephemeral messages for OMEMO in Gajim

  445. daniel

    right. i’m just trying to provide you with an fyi on what most implementors are probably looking for

  446. Ge0rG

    jonasw: so you say you are one of these folks who didn't get it right on the first attempt?

  447. jonasw

    Ge0rG, yupp. and I shall burn in hell

  448. daniel

    Ge0rG, is this an argument to actually use / in Conversations and thus making this type of resource more common and thus helping to find those bugs much quicker?

  449. daniel

    if those bugs exists it's better to find them

  450. jonasw

    daniel, I agree

  451. daniel

    speaking of fun with jids. is there some sort of migration path to PRECIS? :-)

  452. jonasw

    except crying and trying to figure out why anybody would think that PRECIS was a good idea?

  453. SamWhited

    PRECIS was a great idea

  454. jonasw

    SamWhited, good, can you explain to me how it makes sense to /not/ specify a specific unicode version for a standard which is used for data validation?

  455. daniel

    precis is arguably easier to understand and implement than stringprep

  456. jonasw

    I’ve been thinking about this for a while now and wasn’t able to figure that out yet

  457. SamWhited

    Do you want to be stuck on Unicode 3.0 forever? Also yah, I've tried implementing both. PRECIS was *way* easier.

  458. jonasw

    this is bound to give inconsistent results, so we can’t ever do strict validation.

  459. daniel

    jonasw, it relies on char classes

  460. daniel

    and those are standardized by unicode

  461. jonasw

    can’t things move between character clasess in different major releases of unicode?

  462. SamWhited

    You can do strict validation; it's fine.

  463. SamWhited

    Yah, they can, so before you upgrade versions of Unicode double check and think about the consequences. Chances are it won't matter, or you'll have to provide an upgrade path just like when upgrading any other dependency ever.

  464. jonasw

    SamWhited, uhm... so... instead of having a well-defined unicode version in the standard, now every developer of every XMPP related library needs to consider this?

  465. jonasw

    how is this better?

  466. SamWhited

    Because the standard can't be upgraded easily, our random libraries can.

  467. jonasw

    so you’re saying we can manage to pull off a coordinated effort to lift the network on a new Unicode version whenever a new release comes out?

  468. SamWhited

    You don't have to, just be backwards compatible.

  469. SamWhited

    I think my version supports 9 and 10 correctly and I think marcel added a way to make sure they interop, but I'd have to go look

  470. daniel

    how does interop look like though? it has to be valid in both?

  471. daniel

    or pass through both?

  472. SamWhited

    daniel: yah, if it's invalid in one fallback to the other, if it's invalid in both it's invalid.

  473. jonasw

    so with enough time and enough interop, you’ll end up with a thing which just accepts everything.

  474. jonasw

    and O(n) validation

  475. SamWhited

    I suppose it depends on the situation though.

  476. SamWhited

    No you really won't, you still have to follow the spec. Unicode charcters aren't changing left and right every day.

  477. Ge0rG

    daniel: how is it a good idea to expose a small subset of your users to a weird behavior in the hope to sort it out?

  478. jonasw

    O(nm) even, with n being the number of unicode standards you (the network) support and m the length of the string

  479. SamWhited

    This is a rare thing that you *might* have to do if something very bad happens.

  480. SamWhited

    jonasw: that's fine; it's still pretty fast and that only happens in the failure case and probably very rarely at that. You can probably also just check for any characters you think might cause problems if the performance is a problem.

  481. jonasw

    I’m less worried about the practical performance and more about the concept itself.

  482. jonasw

    and possible attack vectors which come from ambiguous validation

  483. SamWhited

    It's not ambiguous, it's very well defined with well defined failure scenarios.

  484. jonasw

    ---which I haven’t thought through yet, because I’m avoiding the isuse at the moment.

  485. jonasw

    SamWhited, where are the failure scenarios defined?

  486. jonasw

    i.e. which unicode versions do I have to try for which parts of a JID under which conditions?

  487. daniel

    well if you are worried about that then there is probably no way to ever migrate to precis in the first place which means you don't have to worry about that

  488. SamWhited

    In the XEPs, they talk about this sort of thing extensively.

  489. jonasw

    there are PRECIS *XEPs*?

  490. SamWhited

    err, RFCs, that is

  491. daniel

    because the differences between stringprep and precis are more severe than precis with unicode x and precis with unicode y

  492. jonasw

    hm, all I found so far was "PRECIS users need to consider the effects of unicode version changes, #notmydepartment" essentially

  493. jonasw

    but maybe I have looked at the wrong place

  494. jonasw

    daniel, yeah, that too

  495. Ge0rG

    And then you are going to end up with users flooded by popup error messages from a client running on an old version of the spec because somebody used a robot face as a MUC nickname

  496. daniel

    true story

  497. Ge0rG

    Not all of my corner cases were pulled from thin air