<div dir="ltr">To follow up on Jeff and Ximin's points:<div> </div><div>Yes, I agree that this data should be exposed at a lower level beneath the high-level simplifications.. We are planning to do this in the annual update of the scorecard, to be launched around the end of this year or early next year.</div></div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Oct 8, 2015 at 12:20 PM, Jeff Burdges <<a href="mailto:burdges@gnunet.org" target="_blank">burdges@gnunet.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Just a another comment : ChatSecure is listed as ChatSecure + Orbot, but only the ChatSecure properties are discussed. Orbot brings a level of metadata protection not found with most tools. It's worth encouraging people to use Orbot, and ChatSecure is the only tool that really tries, but that's not comparable with the others. I doubt the EFF wants long explanations of the more subtle short comings of many of the systems, but they might accept a contributed "Bonus Round" section for the small print at the bottom that singles out various nice features : - All the XMPP+OtR messengers, and some others, have forward-secrecy - TextSecure and Signal have long-term forward-secrecy - ChatSecure integrates with Orbot etc. Yes, Threema has forward secrecy only in the transport layer, not for end-to-end encryption. It says so on page 8 of their whitepaper : <a href="https://threema.ch/press-files/cryptography_whitepaper.pdf" rel="noreferrer" target="_blank">https://threema.ch/press-files/cryptography_whitepaper.pdf</a> <div class="HOEnZb"><div class="h5"> On Wed, 2015-10-07 at 15:04 +0200, Ximin Luo wrote: > Hi, > > I just saw that in the EFF messaging scorecard [1], the column for > forward secrecy gives a tick even if the application does not > actually have forward secrecy: > > "Note: For this phase of the campaign, we accept [..] forward secrecy > on the transport layer [..] and non-forward-secret end-to-end > encryption, plus an explicit guarantee that ciphertexts are not > logged by the provider. This is a compromise [..] but we prefer this > setup to having no forward secrecy at all." > > According to the changelog, this clarification was added on 2015-01 > -29, but the wording of the changelog entry seems to imply that this > criteria was *applied* in older versions of the table as well, just > not clarified. > > Together with the clarification for #1 ("Note that we are not > requiring encryption of data that is transmitted on a company > network, though that is ideal.") these caveats, if both satisfied in > the weakest way, do not give us much confidence - "SSL added and > removed here". Holes that are this big, render extra strength in the > rest of the system worth not much more than a marketing exercise, > like using 4096bit DH with MD5, and also pollutes the meaning of the > other ticks in those columns. > > I'm not going to suggest that you should change the table to be more > strict; it's your table and you can do it how you like. However, do > you have the raw data behind the tick/cross ratings? > > For example, I seem to remember being told that Threema uses forward > -secure TLS but non-forward-secure end-to-end encryption. So that's > why they have a tick on this table. But then I wonder which other > systems do this, instead of having actual forward secrecy. > > X > > [1] <a href="https://www.eff.org/secure-messaging-scorecard" rel="noreferrer" target="_blank">https://www.eff.org/secure-messaging-scorecard</a> > </div></div></blockquote></div> </div>