jdev - 2020-03-26

little offtopic but i dont know an appropriate room for the question

at work i browse with firefox, it always tells me that it does not recognize the CA of the cert, but the cert seems to be installed as root cert on my maschine so firefox is fine with it

the cert is obviously from my company

does that mean they can intercept and read all TLS traffic?

Sounds like a MITM TLS proxy.

Then yes, those can read all your TLS traffic.

hm i guess its their right, i use their hardware, but annoys me a bit

I am pretty sure they do not have the right if you fall under german jurisdiction

flow: they are allowed to do so if you are not allowed to use the PC for private purposes

in Austria they can read all you do

they are just not allowed in some circumstances to make it a offical reason for a lay off

When reading a stanza/xml element, is there a case where one would want to know the declared prefixes ever? apart to determine what's the "default" NS for the current element. With this I mean "bar" for <foo xmlns="bar"/> or <ns:foo xmlns:ns="bar"/> are technically equivalent and there's no reason for the higher-level application to be aware of the difference, right?

Not that I've encountered.

You'd want to set a custom prefix I guess for special cases like stream:stream, or for debugging maybe

(even though 0044..)

I don't see how anything is improved by spamming namespace prefixes like that.

spamming?

https://xmpp.org/extensions/xep-0044.xml#example-4

yeah I guess the version thing is meh. I'd say it's a contrived exapmle just to show support

In practice you probably wouldn't generate this, that's not really smart

You did say 'when reading'.

Ok. Well that confirms what I was asking anyway

You don't need to know

When serializing there might sometimes be some benefit, like not having to have the xmlns twice in errors

what do you mean

<iq id="dawsdfRgbxBQAfF6" type="error" to="me" from="borkborkbork"> <error by="my server" type="cancel"> <remote-server-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/> <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas">Server-to-server connection failed: unable to resolve service</text> </error> </iq>

Observe how the error condition and text elements have the same xmlns. And it's not the shortest one ever.

sure but prefixes are not important here right

NSs are

hmm I'm not sure I understand sorry

It's verbose and a pain to read.

Sure, and you can deduplicate that

We're not talking about the same thing

That's not the layer I'm currently worried about :)

<error by="my server" type="cancel" xmlns:e="urn:ietf:params:xml:ns:xmpp-stanzas"> <e:remote-server-not-found/> <e:text>Server-to-server connection failed: unable to resolve service</e:text> </error> Would be fewer bytes and easier to read.

What I get from this is there is no need for the application to know about the prefix

None

Not unless it wants to be annoying and really enforce that the <stream:stream> has that exact prefix.

... which IIRC is required by the standard

yeah, I have an idea for the API

That'd be an extra step, by default I'll just not ask for prefixes

If you wanna serialize the input back exactly then I guess you wanna keep it

And they will be generated

right

But if you're a server routing stanzas it might be more efficient to keep the actual input

We were recently looking at this and came to the conclusion that the server should be preserving prefixes etc. I forget what led us there.

Compat?

But preserving prefixes is different from not exposing them to the user of my library anyway

Indeed.