XSF Discussion - 2018-09-25


  1. Maranda

    SamWhited, and it's not falling back either on malformed request...

  2. Maranda

    I'll have to blacklist the mechanism

  3. SamWhited

    Oh yah, it doesn't do that, otherwise it would be a potential DOS

  4. SamWhited

    It only falls back if the feature isn't advertised at all and no successful auth has caused a mechanism to be pinned, IIRC

  5. SamWhited

    *a higher-priority mechanism to be pinned

  6. edhelas

    was there some discussions regarding the GDPR and the usage of transports with XMPP ?

  7. edhelas

    > and Mojave completes the transition by pulling out Jabber support

  8. Zash

    Who

  9. edhelas

    macOS Mojave, the state of XMPP in iMessage was already bad, now it's gone

  10. edhelas

    so leave us with not much actually

  11. edhelas

    Dino doesn't has a stable built yet for macOS, Adium is based on libpurple, there's maybe Swift

  12. edhelas

    and Movim but it's an Electron client :p

  13. jonas’

    gajim?

  14. edhelas

    yes indeed

  15. Zash

    Monal?

  16. goffi

    Cagou (SàT) is working on Mac OS, but need people to test it (I have no Mac myself)

  17. dos

    there's Monal, but it still feels somewhat beta, especially regarding MUCs

  18. Ge0rG

    And it's absent from the EU.

  19. dos

    I've tried it when looking for a client for gf, but eventually opted to fixing movim's electron client, it really felt like the best xmpp chat option on macOS :P

  20. dos

    I'm in Poland and I downloaded it from the app store... month ago?

  21. dos

    but it might be absent on iOS

  22. Zash

    GDPR FUD ey?

  23. dos

    well, yeah, when I read the blog post on Monal site I facepalmed pretty hard xd

  24. dos

    it would be way more understandable for Movim to have such concerns, but Monal?

  25. dos

    I mean... unless there's something in Monal we don't know about ( ͡° ͜ʖ ͡°)

  26. edhelas

    Maybe for Movim as well ( ͡° ͜ʖ ͡°)

  27. moparisthebest

    Speaking as a service operator who has 'banned EU residents' we don't really care if you use it, just don't want to be bothered with GDPR crap

  28. Link Mauve

    Because it’s so hard to just not sell our data, and to allow us to retrieve or delete it.

  29. moparisthebest

    Will I can lie to your face and swear I've audited everything and I'm compliant

  30. moparisthebest

    Or just not bother

  31. moparisthebest

    I'm probably compliant, just don't care

  32. Maranda

    Too bad that GDPR protects nothing basically, and causes only annoyances to operators and ultimately users. One of those proper "EU style" things.

  33. Maranda

    Like the latest filter shit they came out with, that's just brilliant.

  34. moparisthebest

    yep Maranda basically that

  35. moparisthebest

    GDPR compliance costs google and facebook nothing, they already have a million engineers, customer service, and lawyers

  36. moparisthebest

    meanwhile now I have to know journald's default retention period, make sure it doesn't change with updates, document it somewhere public, hire an EU rep, then have a lawyer check over everything and declare if I'm GDPR compliant or not?

  37. moparisthebest

    or... I can just tell EU residents to buzz off and not think about it. :D

  38. Maranda

    And they can pay the fines anyways or refuse to, and eventually just bury EU under tons of stamped paper.

  39. Zash

    It got kinda tiresome to read that kind of thing in May.

  40. Maranda

    🤣

  41. Ge0rG

    especially as most of it is wrong.

  42. Zash

    As I said before, > GDPR FUD ey?

  43. moparisthebest

    Ge0rG, allow me to simplify, if not required by law, is it easier to care about it or not care about it? :)

  44. Ge0rG

    moparisthebest: if you want to use my data, you better know where it's stored

  45. moparisthebest

    Ge0rG, so you know the retention period of every log on every server, and go line by line over all code changes every update to make sure it doesn't change?

  46. moparisthebest

    cause, that sounds like a lot of work compared to 'not caring'

  47. dos

    GDPR doesn't care about your "every log"

  48. Ge0rG

    moparisthebest: in the strictest sense I've seen so far, you need to ensure that if you roll back a backup, all accounts deleted since that backup will be deleted after the rollback

  49. moparisthebest

    and that means what for IRC

  50. moparisthebest

    also, by definition, if my server explodes and I have to restore from backup, how would I ever know which accounts had been deleted in between date-of-last-backup and server-explosion

  51. moparisthebest

    that's an insane requirement

  52. Ge0rG

    moparisthebest: since when does an IRC server store *anything*?

  53. moparisthebest

    services and logs

  54. Ge0rG

    moparisthebest: I'm not sure if you are attempting to be ignorant or arrogant here. I'm sure you haven't missed first my and then the XSF announcement of an XMPP server data privacy template. You could have just copied the relevant section about logging from there.

  55. moparisthebest

    seriously though, with any type of service, if you are restoring from backup you presumably don't have any data from before that backup right?

  56. moparisthebest

    such as, what accounts were deleted

  57. Ge0rG

    Sorry, I have some real work to be done. If you need further assistance, I can ask my emplyer for a consulting offer :P

  58. moparisthebest

    thanks for confirming what I said about google/facebook being able to afford GDPR compliance and normal people not being able to

  59. SamWhited

    As far as I can tell the GDPR is mostly perfectly reasonable requirements, unlike most of the tech laws that come out of europe. If you can't afford compliance, you're probably either misunderstanding and aren't covered by it or shouldn't be operating a service that stores other peoples private data.

  60. Ge0rG

    moparisthebest: the good thing is that normal people will not be held to the same standards as Google.

  61. moparisthebest

    good thing is people outside the insanity that is EU won't be held to those insane standards at all

  62. Zash

    Yeah the requirements and therefore costs seemed to scale with size well enough

  63. SamWhited

    What's insane about requiring that you disclose who you're sharing user data with and making it easy for them to ask you to purge it? That seems perfectly reasonable.

  64. Ge0rG

    moparisthebest: oh, right. It's much better to live in a country where your ISP is free to datamine you, sell your location data to the highest bidder, to slow down your video streaming and to inject ads into your traffic.

  65. moparisthebest

    all networks are to be treated as an attacker, that's what encryption/authentication is for

  66. moparisthebest

    not 'please don't look at my data sir'

  67. SamWhited

    So encrypt your data? The law heavily encourages that because you're more responsible for losing your users data

  68. Ge0rG

    moparisthebest: oh, great. Now tell me about that magic protocol that will protect my traffic from all analysis, even from traffic pattern recognition

  69. Ge0rG

    and don't say "use VPN" because the VPN provider is obviously subject to the same (lack of) laws

  70. moparisthebest

    are ISPs doing that now, I thought only govts that aren't affected by these laws did that anyhow

  71. moparisthebest

    doesn't seem like there would be a lot of money in it

  72. Ge0rG

    moparisthebest: https://eu.usatoday.com/story/tech/news/2017/04/04/isps-can-now-collect-and-sell-your-data-what-know-internet-privacy/100015356/

  73. SamWhited

    None of this has anything to do with the law other than that it encourages is by making you more responsible though. I'm not even sure what the encryption thing was about, are you suggesting the law should have been *more* specific and required it?

  74. Ge0rG

    SamWhited: I think moparisthebest was speaking of encryption as a means for users to protect themselves from data collection

  75. SamWhited

    Ge0rG: which is fine, I just don't see what that has to do with this argument unless it's just a strawman

  76. moparisthebest

    SamWhited, I'm suggesting laws are useless with regard to internet privacy, and that encryption is the only option

  77. SamWhited

    If nothing else tons of companies have now put "Delete account" buttons on their product, which sounds great. That's not useless.

  78. SamWhited

    They also are making lists of all the people that they're selling or otherwise sharing my data with, which has been very nice.

  79. Link Mauve

    moparisthebest, now please tell me how to encrypt my Facebook friends in a way to prevent Facebook from knowing them.

  80. SamWhited

    So it doens't appear that laws related to the internet are useless, quite the contrary, it's been fantastic.

  81. Link Mauve

    And from selling this graph to some other companies.

  82. Ge0rG

    SamWhited: nice but illegal. Almost none of the big data-selling news outlets actually honor the opt-in requirement

  83. Ge0rG

    SamWhited: and most just say "if you don't want our tracking, delete your cookies"

  84. SamWhited

    Ge0rG: so your argument is that some people won't follow laws, so we shouldn't have any?

  85. Ge0rG

    SamWhited: not at all. As a user, I love the GDPR

  86. Link Mauve

    Ge0rG, now let’s wait until enough of their users sue them.

  87. Link Mauve

    Now that the EU introduced class actions too.

  88. Zash

    What if we have both laws and tech to back them up?

  89. moparisthebest

    Link Mauve, easy, if you don't give them the data, they don't have it

  90. Ge0rG

    moparisthebest: you can't not give your data to a web site you are visiting

  91. SamWhited

    Anyways, I'm a big fan. It gets me frustrated when people dismiss it as another link tax sort of law that doesn't make sense, having implemented it at two companies where it *definitely* made the users data safer

  92. Link Mauve

    moparisthebest, I can also throw away my computer and start growing potatoes, but that’s not something most people will want to do.

  93. Link Mauve

    Also, I am able to understand the implications of giving my data to Facebook, while most people aren’t.

  94. SamWhited

    Yah, if you have superpowers and can convince everyone to get off facebook, great, do that. In the mean time, since they're already on it, we need some sort of law that requires that Facebook plays nicely when they leave and cleans up their data.

  95. Ge0rG

    except that facebook isn't following the law, so we'll see some major fines in the next five to twenty years.

  96. moparisthebest

    so what's your opinion of latest EU laws? the actual link tax, and forced filtering of all uploaded content?

  97. moparisthebest

    are those good like GDPR too or is that over the line?

  98. moparisthebest

    I haven't seen the prosody or ejabberd modules to scan all stanzas for copyright violations that will be required either so

  99. Ge0rG

    moparisthebest: those are utter junk, pushed forward by big media lobbying

  100. SamWhited

    Those don't make any sense and are garbage because they're pretty much impossible to follow. The GDPR just lists basic data protections you should have been doing anyways

  101. SamWhited

    But I also haven't helped implement those anywhere, so I don't really know who has to follow them or what the specific details are.

  102. moparisthebest

    I agree the general basis of the GDPR is good general data practice to follow, I think it's both unenforceable in general and onerous to small operators though, and shouldn't really be a law, meh

  103. SamWhited

    God I wish we had something similar here; I'm sure it's not perfect, but I'm pretty okay with it being onerous if those small operators weren't bothering to protect my data before

  104. Ge0rG

    moparisthebest: it wouldn't have become a law if everybody was respecting users' privacy from day 1

  105. SamWhited

    As for unenforceable, I have no idea. We'll see if fines start rolling out or not I guess. But even if it's unenforceable, it's made two companies I've worked for improve their practices, so it seems to be doing good either way.

  106. Ge0rG

    and I'm sure it will be enforced.

  107. Ge0rG

    It just takes time. Significant time. Have a look at the timeframe of the Google Android antitrust case.

  108. SamWhited

    yah, I don't see why it wouldn't be, it seems straight forward enough… we may not have similar laws in the U.S., but people complain to the FCC about Google and then Google gets fined all the time. This seems to be the same just with more teeth.

  109. SamWhited

    (or whomever, Google's just a good stand in for "large company doing things they probably shouldn't be")

  110. Ge0rG

    Heh

  111. edhelas

    ok let's move the discussion there Link Mauve

  112. edhelas

    regarding https://xmpp.org/extensions/inbox/muc-avatars.html

  113. edhelas

    what is the current supports of the code 104 in XMPP clients ?

  114. edhelas

    I'm currently having some though on that XEP and I'd like to propose some changes to generalize it

  115. edhelas

    the core idea of this XEP is to expose the vcard hash in the bare MUC JID disco#info and notify it using a message 104

  116. edhelas

    I'd like to propose to do that for also disco#info of Pubsub nodes and all JIDs (including users ones)

  117. edhelas

    the notification will then be done using a message for MUC, presence or message for users and pubsub message for Pubsub nodes

  118. edhelas

    then we basically cover all the cases using the same core mechanism

  119. Maranda

    SamWhited, if eventually you wanna have some fun ™️ https://conference.gajim.org:5281/pastebin/cd179f64-2dff-4968-9b36-c45b874b48fa

  120. Maranda

    :D

  121. SamWhited

    My SCRAM implementation can take any generic hash algorithm, so they're already implemented. On the other hand, those aren't actually defined anywhere and haven't been vetted, so probably not a good idea to use them :)

  122. jonas’

    which are not?

  123. SamWhited

    Anything other than SHA1 and SHA256, to my knowledge

  124. jonas’

    right

  125. jonas’

    although, I think SCRAM doesn’t care *too* much about the hash, as long as the hash is reversible; i.e. it should be as safe as any as long as the hash used is safe

  126. jonas’

    (that’s a property of PBKDF2 even)

  127. SamWhited

    Yah, it should be safe, but probably best not to use random hash algorithms that aren't defined anywhere for no reason; SHA-1 and SHA-256 are both fine.

  128. jonas’

    hmmm

  129. SamWhited

    Kafka supports SCRAM-SHA-512 for some reason, so I guess you could use it with that

  130. jonas’

    Maranda, if you just want to poke at your implementation, aioxmpp should support all of those (if your build of python has them).

  131. jonas’

    you’d have to play some tricks to force it to use a specific one of them though)

  132. SamWhited

    ugg, does aiosasl support all these too? That makes me sad

  133. Maranda

    👍

  134. jonas’

    SamWhited, I don’t see a convincing argument for *not* allowing other variants of the SHA-2 family if one variant of the SHA-2 family is specified

  135. SamWhited

    Where security is concerned, just randomly changing things because it has a bigger number or whatever probably isn't a good idea. I can't imagine how this would go wrong, but for compatibility if nothing else it makes me sad that people are implementing them and other people consuming the library who don't know any better will think it's osmething to use

  136. SamWhited

    I don't see a convincing argument to implement them, and as far as I'm concerned the burden of proof should be on that side of things whenver auth is concerned.

  137. jonas’

    to be honest, I somewhat assumed that they were specified due to the wildcard in the IANA registry

  138. SamWhited

    Oh, interesting; I could be wrong. I didn't see an RFC though, does the IANA registry link to a document?

  139. jonas’

    yes, to the one for SCRAM-SHA-256

  140. jonas’

    https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml

  141. jonas’

    I guess technically this is just a reservation of the SCRAM- prefix

  142. SamWhited

    Oh, yah, that's just a reservation for the entire familyl

  143. jonas’

    Note to future SCRAM-mechanism designers: each new SASL SCRAM mechanism MUST be explicitly registered with IANA within the SASL SCRAM Family Mechanisms registry.

  144. jonas’

    yeah

  145. jonas’

    that’s pretty explicit

  146. jonas’

    also a very convincing argument to remove support

  147. jonas’

    SamWhited, there you go https://github.com/horazont/aiosasl/issues/6

  148. jonas’

    the "minimum iteration count" parameter of the registry is interesting, too

  149. SamWhited

    ♡ thanks; between security concerns and standardization concerns this makes me very happy.

  150. Maranda

    hm, interesting, well the implementation in Metronome is SHA digesting algorithm agnostic as well so it doesn't matter.

  151. SamWhited

    It matters in the sense that this is auth which is extremely important and security sensitive. In crypto, tiny insubstantial changes can often have a big impact that we don't forsee; it's not exactly intuitive. I doubt this is a problem, but it doesn't help to add more algorithms for no reason and it *possibly* hurts. Might as well just leave it to the experts and not make up your own crypto.

  152. SamWhited has huge pet peeve about this sort of thing

  153. jonas’

    me too, normally, but I hadn’t seen this as "making up new crypto" to be honest

  154. SamWhited

    Well, "changing existing crypto", then. I agree, I can't imagine this possibly causes any problems, but it's also not necessary so why take the risk?

  155. jonas’

    yeah

  156. Maranda

    SamWhited, I didn't mean that way :P

  157. SamWhited

    Heh, cool; sorry I'm being grumpy about it.

  158. jonas’

    ’tis fine

  159. SamWhited

    This is just the kind of thing where I expect the longer hash will cause some buffer operation to behave slightly differently on some architecture and then suddenly you have a side channel, or something.

  160. Maranda

    I didn't know they weren't defined either, blame google for returning result on SCRAM-SHA-384 and SCRAM-SHA-512

  161. SamWhited

    (well, I don't "expect" it, but I could see it happening)

  162. Maranda

    I didn't know they weren't defined either, blame google for returning results on SCRAM-SHA-384 and SCRAM-SHA-512

  163. jonas’

    that doesn’t make sense to me, actually

  164. jonas’

    that would be a fundamental problem of pbkdf2 then

  165. jonas’

    which I think we would know about

  166. jonas’

    (we = the cryptography community, thus warning louder against it and deprecating pbkdf2 for that reason)

  167. SamWhited

    I was just making up a random example, I agree it's not likely

  168. jonas’

    sure