XSF Discussion - 2018-06-11

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

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

Damn, 0308 is in Draft.

what did you want to change?

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

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

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

oh yes, this needs fixing

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

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

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

yeah

Why not make GDPR support into a plugin?

if only

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

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

GDPR can be spreaded though software😂

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

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

Hey kid, got GDPR?

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

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

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

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

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

:(

Is it even allowed

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

great

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/

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

But then IANAL either

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

> 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

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

daniel: it's just a regular link

daniel, what's the issue with that

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

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

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

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

Ge0rG, interesting

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

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

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

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

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

Ge0rG: could you give an example?

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

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

ah css mix-blend-mode

will probably be fixed just like leaking :active

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

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

isn't this true for software in general?

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

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

this is just survivorship bias

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.

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

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

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

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

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

Wiktor: firefox ships with JavaScript enabled, so yes.

yep, that scr could be malicious too

little evil johnny castaway

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

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

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

Now please tell me that not all JS is malicious.

is it?

Ge0rG, not all JS is malicious!

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

Not all X!!

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

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

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?

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

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

Somebody mentioned Intel ME?

haha, yes, Intel ME

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

And AMD's whatever

Computers are teh wurst

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

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

Zash, potatoes!

Let's just all become potato farmers

Ge0rG, are you even sure of that

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

pep.: sure of what?

*only Intel*

I mean,

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

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

:)

Sounds better

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

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

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

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

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

I bet that's already true to some extent

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

Just in case, I am the author of this protoxep

hey labdsf, welcome :)

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?

hi labdsf

labdsf, yes, that is definitely a concern ✏

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.

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

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

Ge0rG, timer setting synchronization part?

or starting of the timer on the recipient side?

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

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

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

and it is for plaintext only

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

No idea.

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

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

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

MAM*

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

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

So it still breaks the multi-client use case.

Yes.

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

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

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

when all devices got the messages, they are removed

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

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

Ge0rG, unregister it after 2 weeks of inactivity

labdsf: not a bad idea

But we aren't there yet.

Maybe we can fix it with IM-NG

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

device is unregistered after one week

I thought Signal has a single-device model?

no

it is WhatsApp that has single-device

We need to establish a device-registration XEP.

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

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

labdsf afaik, you can't shutdown the phone no

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

yes

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

edhelas, you are talking about WhatsApp

ah yeah sorry

Signal is different, you can shutdown the phone

What a feature.

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

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

"Signal-like" means?

multiple queues, one per device

messages are removed as soon as you download them

Ugh

or after one week if you don't

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

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

it does, I just described above

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

we need to go deeper

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

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

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

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

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

MattJ: so what's my TTL, then?

MattJ: do you have the eyes of a Shinigami?

integer overflow ✏

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

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

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

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

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

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

and what is an "OMEMO message"?

daniel: what were you smoking?

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

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

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

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

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

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

Ge0rG, no

it just becomes read forever

ephemeral Pubsub posts!

I like the idea of being able to temporarily correct messages

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

It's called restarting Prosody

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

MattJ: thanks for making me sad.

MattJ +1 :D

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

in trunk?

In trunk

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

> 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

daniel: touché

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

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

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

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

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

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

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

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

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

hmm

jonasw: the XEP was rejected

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

Ge0rG, I am aware

Ge0rG, what are you telling me?

you saying I should reject the update on that ground?

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

or the Council.

exactly

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

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

labdsf: and then let us know

> 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.

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

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

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

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

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

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

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

labdsf, why?

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

yeah, gajim needs fixing then :)

maybe

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

labdsf, MattJ is working on that, kinda

regarding fixing clients, please file issues

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.

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

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

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

because you may want to use to Gajims, for example

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

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

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

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

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

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

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

parsing the resource string is awful for that

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

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

goffi, disco#info can have names in it

allow users to set proper disco#info names

(and default them to something sensible)

hum, disco#info can be nice indeed

and the name can even be internationalised!

in resource too

no

you can only have one resource

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

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

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

true

an Informational document would be good

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

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

Ge0rG: where ?

Hm.

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

32 bits?

That seems like a lot

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

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

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

the server has to assign one to you then

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

sure, gajim needs fixing

ok, I will file an issue

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

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

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.

32 bit is what OMEMO uses

I‘d probably do base64 instead.

for device id

goffi, which github issues?

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

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

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

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

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

good then

daniel, right

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

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

burn them

Ge0rG: well if there are they should reread the rfc

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

jonasw: plus two more

oh right

(three if you count the padding)

With three bytes you don't have padding

true

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

something like "commissions beer respite"?

Did I say "passphrase"?

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

Can you read minds?

I guess it is offline message queues in prosody

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

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

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

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)

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

Yes

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

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

Tedd has a very interesting reading of the LMC rules

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

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

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".

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

Regardless of what hints are in the message

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

And store does not work because MAM is disabled

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

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

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

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

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

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

Ge0rG, the XSF preaches? :)

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)

birdsite.tld/shitxsfsays

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

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

and server stores permanently encrypted messages that nobody can decrypt

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

labdsf, pretty much agree

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

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

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

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

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

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

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

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

labdsf: don't ask *me* about that

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

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

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

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

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

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

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

Probably a trivial operation for most clients

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

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

"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?

Are we not delivering everything to every clients nowadays

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

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

Gajim would just fetch them from MAM of course.

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

hmm

*offline messages

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?

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"

"Mobile" will receive the message because it was online

And if Mobile wasn't connected

then "Gajim.bar" will probably receive the message

I like the certainty of that sentence

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

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

Does anyone get deduplication right?

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

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

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.

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.

s/of/if/

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

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

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

labdsf, resources in Conversations are only semi-stable fwiw

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

I like resources with human-readable parts.

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

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

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

But I think it is easier to just fix major clients

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

daniel, to a local server it can

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

what zash said

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

but that’s borderline insane

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.

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

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

No need to think about the case when server does not

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

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

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

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

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

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

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

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

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

except for / and -

jonasw: exactly. / and -

what’s the isuse with that?

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

why not?

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

(and then I can still move to urlsafe…)

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

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

but whatever, I’ll use urlsafe then

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

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

(and are single device only most of the time)

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

yes

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

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

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

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

jonasw: 👍

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

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

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

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

Ge0rG, yupp. and I shall burn in hell

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?

if those bugs exists it's better to find them

daniel, I agree

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

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

PRECIS was a great idea

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?

precis is arguably easier to understand and implement than stringprep

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

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

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

jonasw, it relies on char classes

and those are standardized by unicode

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

You can do strict validation; it's fine.

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.

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?

how is this better?

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

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?

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

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

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

or pass through both?

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

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

and O(n) validation

I suppose it depends on the situation though.

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

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?

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

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

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.

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

and possible attack vectors which come from ambiguous validation

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

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

SamWhited, where are the failure scenarios defined?

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

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

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

there are PRECIS *XEPs*?

err, RFCs, that is

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

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

but maybe I have looked at the wrong place

daniel, yeah, that too

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

true story

Not all of my corner cases were pulled from thin air