On 5 October 2015 at 02:04, Mike Barnes <m...@bremensaki.com> wrote: > What we need to be doing is putting information about the quality of > encryption used in a conversation in front of the users, and letting > them make informed decisions, instead of fracturing the network > invisibly.
I semi-agree. Once I would have completely agreed :) One problem is that this approach leads to overloading the user with information (that they aren't really qualified to make a choice on). You will notice that the current trend in browsers is now removing this information as much as possible, and just doing the "right" thing. Websites with incorrect certificates used to show a warning padlock, now they throw up big alert pages that are hard to bypass. > Is there any defined mechanism to do this? Users are accustomed to the > little padlock icons on web URLs, can XMPP client software easily > implement something like this or will it need server extensions to > report back? As a temporary measure, could the server send a direct > message to a user alerting them if the encryption on a connection they > initiate falls below a desired threshold? It would need the server's help. This has in fact been discussed before, a long time ago. I think there was even a XEP. The problem is that it wasn't enough. The server doesn't always have a connection open to the remote server, so it doesn't know (in advance) what security proprties it has. Then, when it does have a connection, this is easily changed. An attacker with access to the network could let the secure connection through, so that the client displays the padlock. Then when the client sends a message, quickly break the secure connection, and ensure only an insecure one can be established. > Inform the users, don't cut them off from their contacts and leave > them no path to even tell them why. I think a better option is to let the user decide whether what they are sending is sensitive or not, and the level of security to apply to that particular message. That way, their (obviously trusted) server will never send a sensitive message over an insecure connection, etc. A failure would result in a delivery error, which can be handled by the user's client. This is technically achievable using security labels (http://xmpp.org/extensions/xep-0258.html ), though it hasn't really been deployed that way on the public network, and not many clients support it (though Swift and Gajim both do, and they are cross-platform). Regards, Matthew
