Hi all,
I was skimming XEP-0490, and the optimisation of injecting multiple
displayed elements into a message referencing different ids in different
namespaces made me spit my tea dramatically over my keyboard. Not really,
of course - tea is far too precious to waste on such things, but you get
the idea.
There's clearly no better alternative, because we have clients in the wild
which are quite painful about message ids, and will therefore break things
if we were to rely on their ids being unique.
This got me thinking: What could we do to - if not remove this wart
entirely, at least file it down so it was less of a nuisance. (I'm not sure
if warts do get filed down; I am not a doctor, do not try this at home)
In a perfect world, we might remove XEP-0359 entirely - not because it is,
in and of itself, a bad spec, but because it is essentially patching
problems elsewhere.
So, what can we do to ensure that some tuple of the stanza attributes
perhaps (from,id), or possibly (from,to,id), is unique "enough", and stable
"enough", for both receivers and senders to rely on without having to
inject multiple ids?
Is this worth doing - it feels like it would clean up a lot of other
constructs, but some cases (MAM, perhaps?) might always need to inject
other identifiers. If we were to rely on clients using unique identifers,
could this be subverted in some way beneficial to an attacker?
My gut feeling is that even if we find that we're stuck with XEP-0359 in
all the same cases, we might produce an interesting document about the
security implications of the id attribute of stanzas, which feels like a
gap worth filling.
What do you all think?
Dave.