Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

[Emmanuel Gil Peyrot]

Hi,

On Thu, Sep 01, 2016 at 08:40:24PM -0600, Peter Saint-Andre wrote:
[…]
> > The name metadata should either be qualified by a lang or simply be
> > removed. I feel like removing is the right thing: Clients/Libraries
> > either know the encryption mechanism by its namespace, and are possible
> > able to tell the user to install a certain plugin to enable the
> > encryption mechanism. And otherwise they could simply say "The received
> > message was encrypted with an unknown mechanism (jabber:x:encrypted)".
> 
> Agreed.
> 
> > That said: I really like the EME XEP.
> 
> Yes, it seems fine. +1 to publishing it (if the Council folks are paying
> attention).
> 
> §3.2 mentions a list of supported protocols. What happens if we add another
> supported protocol to EME? (Because, you know, we have so many end-to-end
> encryption protocols!) Do we create a registry of supported protocols and
> add another to the registry? Do we update the spec, perhaps even with a
> change to the namespace version?

I made this part more explicit in candidate version 0.0.2[1], it may
help to have a registry, but we can only mandate an implementation to
know about the ones currently listed, this was the reasoning for this
table.

> 
> Peter

[1] 
https://github.com/xsf/xeps/pull/241/files#diff-22c9de9f1781a8add91d805f84205b69L125

-- 
Emmanuel Gil Peyrot
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

[Emmanuel Gil Peyrot]

Hello,

I proposed a newer version[1] which tried to fix every piece of
feedback I received on this thread and elsewhere, direct or indirect,
please comment. :)

I chose to keep the 'name' attribute, but made it optional, and let
i18n issues be determined by the sending client if it wants to add it.

[1] https://github.com/xsf/xeps/pull/241

-- 
Emmanuel Gil Peyrot
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

[Florian Schmaus]

On 17.08.2016 20:48, Emmanuel Gil Peyrot wrote:
> On Wed, Aug 17, 2016 at 01:31:28PM -0500, Sam Whited wrote:
>> Having the name be an attribute doesn't seem very friendly to me. What
>> if I want it in a different language or locale? How do RTL languages
>> work? Even if we assume everything is always English, what if my text
>> doesn't work well with all names "an [OTR] encrypted message" works
>> fine, but "an [PGP] encrypted message" does not where the bracketed
>> word is substituted.
>>
>> I'd leave off the name attribute entirely; it's not necessary.
> 
> The rationale for the presence of this name attribute is to have a
> placeholder in case the client doesn’t know anything about the
> encryption method in question.

The name metadata should either be qualified by a lang or simply be
removed. I feel like removing is the right thing: Clients/Libraries
either know the encryption mechanism by its namespace, and are possible
able to tell the user to install a certain plugin to enable the
encryption mechanism. And otherwise they could simply say "The received
message was encrypted with an unknown mechanism (jabber:x:encrypted)".

That said: I really like the EME XEP.

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

[Dave Cridland]

On 18 Aug 2016 13:00, "Kim Alvefur"  wrote:
>
> On 2016-08-18 13:09, Emmanuel Gil Peyrot wrote:
> > On that basis, maybe I could make @name optional, as in “MAY NOT be
> > included for those three XEPs already listed”, “SHOULD for any
> > mechanism not listed here”, and “SHOULD be ignored on a received
> > message if you already have a correct name for it and can present it to
> > the user”?
> >
> > Anyway, no matter the solution chosen, I will include the reasoning and
> > other solutions that have not been taken in the next revision of this
> > XEP.
>
> A registry of i18n'd names might be useful as a shared resource
> somewhere, so you could look up an appropriate name based on the
namespace.
>
>

Is OTR, or PGP, typically translated?

In any case, the name is, I understood, a convenience for clients that do
not recognise the namespace. I18n considerations feel like optimizing for
this failure case.

>
> --
> Kim "Zash" Alvefur
>
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

[Kim Alvefur]

On 2016-08-18 13:09, Emmanuel Gil Peyrot wrote:
> On that basis, maybe I could make @name optional, as in “MAY NOT be
> included for those three XEPs already listed”, “SHOULD for any
> mechanism not listed here”, and “SHOULD be ignored on a received
> message if you already have a correct name for it and can present it to
> the user”?
> 
> Anyway, no matter the solution chosen, I will include the reasoning and
> other solutions that have not been taken in the next revision of this
> XEP.

A registry of i18n'd names might be useful as a shared resource
somewhere, so you could look up an appropriate name based on the namespace.



-- 
Kim "Zash" Alvefur



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

[Emmanuel Gil Peyrot]

On Wed, Aug 17, 2016 at 09:19:01PM -0500, Sam Whited wrote:
> On Wed, Aug 17, 2016 at 1:48 PM, Emmanuel Gil Peyrot
>  wrote:
> > The rationale for the presence of this name attribute is to have a
> > placeholder in case the client doesn’t know anything about the
> > encryption method in question.
> 
> Yes, I understand the point, however, I don't think it covers that use
> case very well in its current form (see the objections from my earlier
> email).

My main fear is that this would bloat the message, since this will
eventually be included in every single encrypted message.

> 
> If this feature is really desired I think that both the implementation
> needs to be changed (to account for i18n) and the examples need to be
> changed (to eg. show a list instead of using a sentence that includes
> the text since there's no good way to ensure that if the word is used
> in a sentence that it will end up being gramatically correct.

i18n here would only be a concern for future encryption mechanisms that
don’t exist already, since the existing ones could already have the
full sentences translated and QA’d, and @name ignored.

On that basis, maybe I could make @name optional, as in “MAY NOT be
included for those three XEPs already listed”, “SHOULD for any
mechanism not listed here”, and “SHOULD be ignored on a received
message if you already have a correct name for it and can present it to
the user”?

Anyway, no matter the solution chosen, I will include the reasoning and
other solutions that have not been taken in the next revision of this
XEP.

> 
> Alternatively, Instead of an encryption name, maybe we should just use
> a  element with an xml:lang attribute like many other XEPs do (eg. 
> various
> types of errors). This text element would contain a fallback message
> instead of just the name, making the fallback the responsibility of
> the client sending the encrypted message instead of the client that
> can't receive the encrypted message. Either way both clients sitll
> have to support this XEP for this to work (to display the fallback),
> but this way the data is sent by one client (the one that sent the
> encrypted message) instead of part of the data being sent by that
> client (the name) and part of the data residing on the receiving
> client (the rest of the sentence) which feels messy.

In every case except OTR, the sending client already included that
sentence in the body of the message, potentially in multiple versions
with @xml:lang, for legacy clients.  If the receiving client decides to
do so, it could use this body instead of making a sentence itself, like
every current client does when they don’t understand a specific
encryption scheme.

The very reason for the existence of this XEP is to make it machine-
readable, that is to allow for a better representation in every case,
to allow for better interaction with the user, and that includes i18n
directly in the receiving client instead of in the sending one.

Maybe a future XEP could be written to retrieve a list of all of the
possible translations associated with a particular namespace, in which
the receiving client would trust the emitting client with that, and
would then use it for any incoming encrypted message.

Thanks,

-- 
Emmanuel Gil Peyrot
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

[Sam Whited]

On Wed, Aug 17, 2016 at 1:48 PM, Emmanuel Gil Peyrot
 wrote:
> The rationale for the presence of this name attribute is to have a
> placeholder in case the client doesn’t know anything about the
> encryption method in question.

Yes, I understand the point, however, I don't think it covers that use
case very well in its current form (see the objections from my earlier
email).

If this feature is really desired I think that both the implementation
needs to be changed (to account for i18n) and the examples need to be
changed (to eg. show a list instead of using a sentence that includes
the text since there's no good way to ensure that if the word is used
in a sentence that it will end up being gramatically correct.

Alternatively, Instead of an encryption name, maybe we should just use
a  element with an xml:lang attribute like many other XEPs do (eg. various
types of errors). This text element would contain a fallback message
instead of just the name, making the fallback the responsibility of
the client sending the encrypted message instead of the client that
can't receive the encrypted message. Either way both clients sitll
have to support this XEP for this to work (to display the fallback),
but this way the data is sent by one client (the one that sent the
encrypted message) instead of part of the data being sent by that
client (the name) and part of the data residing on the receiving
client (the rest of the sentence) which feels messy.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

[Dave Cridland]

This one looks broadly sensible to me. I'll miss next week's council
meeting unfortunately, so this email can constitute no objection to
publication from me.

On 17 Aug 2016 17:39, "XMPP Extensions Editor"  wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Explicit Message Encryption
>
> Abstract: This specification provides a way to mark encrypted messages so
> the
> recipient can discover how to decrypt it.
>
> URL: http://xmpp.org/extensions/inbox/eme.html
>
> The council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

[Emmanuel Gil Peyrot]

On Wed, Aug 17, 2016 at 01:31:28PM -0500, Sam Whited wrote:
> Having the name be an attribute doesn't seem very friendly to me. What
> if I want it in a different language or locale? How do RTL languages
> work? Even if we assume everything is always English, what if my text
> doesn't work well with all names "an [OTR] encrypted message" works
> fine, but "an [PGP] encrypted message" does not where the bracketed
> word is substituted.
> 
> I'd leave off the name attribute entirely; it's not necessary.

The rationale for the presence of this name attribute is to have a
placeholder in case the client doesn’t know anything about the
encryption method in question.

Say in 2017 you are still using a client that has been released in
2016, and a newer XEP got published which provides a much better
encryption method than the existing ones and everyone starts using it,
it might be more user-friendly to communicate the name of said method
to the user than to just have an opaque namespace you can’t say
anything about, even if it isn’t properly localised.

> 
> —Sam
> 
> 
> On Wed, Aug 17, 2016 at 11:39 AM, XMPP Extensions Editor
>  wrote:
> > The XMPP Extensions Editor has received a proposal for a new XEP.
> >
> > Title: Explicit Message Encryption
> >
> > Abstract: This specification provides a way to mark encrypted messages so 
> > the
> > recipient can discover how to decrypt it.
> >
> > URL: http://xmpp.org/extensions/inbox/eme.html
> >
> > The council will decide in the next two weeks whether to accept this 
> > proposal as an official XEP.
> >
> > ___
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > ___
> 
> 
> 
> -- 
> Sam Whited
> pub 4096R/54083AE104EA7AD3
> https://blog.samwhited.com
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___

Thanks,

-- 
Emmanuel Gil Peyrot
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Explicit Message Encryption

[Sam Whited]

Having the name be an attribute doesn't seem very friendly to me. What
if I want it in a different language or locale? How do RTL languages
work? Even if we assume everything is always English, what if my text
doesn't work well with all names "an [OTR] encrypted message" works
fine, but "an [PGP] encrypted message" does not where the bracketed
word is substituted.

I'd leave off the name attribute entirely; it's not necessary.

—Sam


On Wed, Aug 17, 2016 at 11:39 AM, XMPP Extensions Editor
 wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Explicit Message Encryption
>
> Abstract: This specification provides a way to mark encrypted messages so the
> recipient can discover how to decrypt it.
>
> URL: http://xmpp.org/extensions/inbox/eme.html
>
> The council will decide in the next two weeks whether to accept this proposal 
> as an official XEP.
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___



-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___