16 Jul
2024
16 Jul
'24
5:43 a.m.
Yes, we are aware of them, but found them insufficient, and went with our
own implementation. I'll try to briefly explain the difference in approach:
Basically, there are two types of trust information you need to share: your
own devices and those of your contacts whom you trust. Own devices are
published on PEP with signature (so that if one of your devices, or
contact's devices, sees that an already trusted device signed yet another
device, it starts trusting it automatically. With contact's devices trusted
by your own devices we opted for trust messages, but exchange it via
special notifications service. (after many experiments of sending messages
to your own xmpp id and implementations of it in various servers, we
decided that a service is a more reliable option).
Oh, and we added a third state: trust/distrust/revoked and timestamps.
Eventually we'll publish it all some time after we're happy with how
everything works (this particular section works well, but some others
aren't, yet) and we release our apps.
On Tue, 16 Jul 2024 at 14:45, MSavoritias <email(a)msavoritias.me> wrote:
To solve the keys problem you may also be interested
in
- XEP-0434: Trust Messages (TM)
- XEP-0450: Automatic Trust Management (ATM)
Which Kaidan has implemented here ->
https://www.kaidan.im/2022/08/31/e2ee-trust-management/
It serves as a nice solution to the problem.
Andrew Nenakhov kirjoitti 16.7.2024 klo 12.40:
It is actually not necessary.
On Tue, 16 Jul 2024 at 14:15, Tim Henkes <syndace(a)web.de> wrote:
I think this can be compared to calls or A/V in
that both devices are
expected to be actively used while the transfer is happening. I think this
should be possible even on aggressive platforms like iOS.
Aggressive or not, it might actually be unnecessary, at least according to
our vision of multi-device encryption.
We have discovered that whenever there are encryption session that are
encrypted for one of your devices, and not the other, this leads to a
horrible user experience that can't be recovered in no way. Grabbing the
wrong device and seeing 'unable to decrypt message' which is decryptable on
another of your devices is really, really bad and inconvenient, and we
treat such incidents as a severe error.
So our solution is to require the sender to encrypt messages for all valid
devices of the message recipient, warning the user really aggressively if
one of those devices is not trusted (via fingerprint matching or our other
method of verification via code), nudging the user to perform device trust
procedure. This way, the only history you need to synchronize conversations
that happened prior to addition of this new device just once, at device
initialization. For this, you don't need to create some complex protocols
that would continuously sync history.
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org