XSF Discussion - 2018-09-25

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

I'll have to blacklist the mechanism

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

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

*a higher-priority mechanism to be pinned

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

> and Mojave completes the transition by pulling out Jabber support

Who

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

so leave us with not much actually

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

and Movim but it's an Electron client :p

gajim?

yes indeed

Monal?

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

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

And it's absent from the EU.

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

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

but it might be absent on iOS

GDPR FUD ey?

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

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

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

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

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

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

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

Or just not bother

I'm probably compliant, just don't care

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

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

yep Maranda basically that

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

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?

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

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

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

🤣

especially as most of it is wrong.

As I said before, > GDPR FUD ey?

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

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

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?

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

GDPR doesn't care about your "every log"

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

and that means what for IRC

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

that's an insane requirement

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

services and logs

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.

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?

such as, what accounts were deleted

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

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

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.

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

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

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

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.

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.

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

And from selling this graph to some other companies.

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

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

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

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

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

Now that the EU introduced class actions too.

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

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

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

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

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

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

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.

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

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

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

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

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

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

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.

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

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

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

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.

and I'm sure it will be enforced.

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

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.

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

Heh

ok let's move the discussion there Link Mauve

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

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

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

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

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

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

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

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

:D

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 :)

which are not?

Anything other than SHA1 and SHA256, to my knowledge

right

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

(that’s a property of PBKDF2 even)

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.

hmmm

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

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

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

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

👍

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

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

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.

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

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

yes, to the one for SCRAM-SHA-256

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

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

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

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

yeah

that’s pretty explicit

also a very convincing argument to remove support

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

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

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

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

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.

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

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?

yeah

SamWhited, I didn't mean that way :P

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

’tis fine

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.

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

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

that doesn’t make sense to me, actually

that would be a fundamental problem of pbkdf2 then

which I think we would know about

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

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

sure