26 Jun
2025
26 Jun
'25
6:43 a.m.
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