I think this should be adopted. If people use it, that'd be great. 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.
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. Dave. [ The missing close parenthesis is purely to pay Goffi back for having mismatched brackets around SNIP ] On Thu, 26 Jun 2025 at 12:09, Goffi <[email protected]> wrote: > Dear XMPP fellows, > > To give you an idea of what is possible to do with this XEP, I've just > posted > 2 screenshots there : > https://mastodon.social/@Goffi/114749239855176796 > > As you can see, the idea is to be able to have a badge with a very simple > to > understand score showing how secure is it to use a service or gateway. > > Of course the information provided in the specification will evolve with > time. > I think that I'll add the algorithm to calculate the score there too, so > if > people wants to do the same thing, we can have consistency in the score. > > Don't hesitate to give me feedback, notably on data you would like to see > exposed. > > Regarding the technical, it's currently using disco extension (XEP-0128), > but > this has been discussed during council and it may evolve to another way > (with > custom element or whatever). The current options are: > > - keep current behaviour > - disco, but on a dedicated node > - using ad-hoc commands > - dedicated IQ with custom elements > - Pubsub/PEP (with the advantage that we can subscribe, and get notified > when > something change, e.g., terms of service). > > I personally don't care much as long as data are available. Would be nice > to > have notification on data change. > > If you have well-founded ideas on the way forwards, please shoot. > > I would very love to see widespread adoption of those data, so in our > clients > we can show how safe is it to use an XMPP server, gateway, or any service. > Would be great to see them in Biboumi and Slidge, and to have plugins in > server so admins can fill their data. > > Best, > Goffi_______________________________________________ > Standards mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
