Hi Dave, Thanks for your feedback.
To be clear: this is a base to document so everybody get the idea, but I expect it to be modified, possibly heavily (which is my understanding of the "experimental" status). In fact, there are already a few fields that I'd like to change but I'm waiting for the spec to move forward first: pep. rightfully told me that ToS should accept multiple URI, so ToS could be linked via HTTP and XMPP (e.g., Pubsub item). Also the "government" in access_policy was put because I was thinking of cases where they can't access (e.g. service which delete logs, encrypt everything). But technically, more or less all services would give access to government on request. So I'm not 100% sure if it's pertinent to keep it. Le jeudi 26 juin 2025, 14:11:51 heure d’été d’Europe centrale Dave Cridland a écrit : > I think this should be adopted. If people use it, that'd be great. I hope to be able to show a badge for any gateway services in not-to-distant future. > But: I hate that "e2e" means not actually end-to-end. "e2e" etc are terms > of art with specific meanings, we shouldn't be altering them. There's also > complex cases, like escrow-based cryptography, which aren't captured here > (but do exist and are deployed). Whether something's decrypted (or > re-encrypted) in transmit, or stored in unencrypted form (including > "encryption at rest", which is usually a box ticking exercise) makes a huge > difference in legal terms, though less in security. But e2ee has the > specific meaning of being encrypted from its originator to its final > destination, and that's something we shouldn't change here. One of the base idea of this specification was actually to detect when a gateway is decrypting content, while it appears as "e2e" to the client because OMEMO or whatever is used between client and gateway. But you're right, maybe it would be better to rename it to "service-to-end" or something like that to make it more clear. Also note that I have proposed another protoXEP, which will be resubmitted in a while due to council discussion and requested changes, to do real end-to-end encryption with gateways (the "gre" option in this data policy spec). > Otherwise, looks good - I might propose changing a few things from booleans > to URLs (like data export), and anyone with PITR is going to hate that "0" > means no backups. (That's Point In Time Recovery, not Pain In The ... > whatever. I'm open to use another value, that's not a problem at all. > Dave. > [ The missing close parenthesis is purely to pay Goffi back for having > mismatched brackets around SNIP ] Goffi
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
