In order to simplify the user interface, I've been thinking about whether we can in a simple way communicate how secure/safe/private the current conversation is. My proposal is that we calculate a number from 0 to 100, that is a combination of several different features, such as:

• Is OTR used?
• Which version of OTR?
• Is encryption required?
• Is the peer authenticated or not?
• Is Tor used?
• Is TLS used?
• Is the crypto used to connect to the server forward secret and of high quality?
• Is the TLS certificate valid?
• Is the quality of the TLS certificate good?
• Are you connecting to a Tor Hidden service?

There are probably some other things we can add here. But once we have this number we can do a few different things (and even offer different options)

• We can display a smiley figure with a frown/smile that depends on how good the value is
• We can display the number itself (people love gamification "see if you can get a rating of 100")
• We can change the background color of each "message" to go from red to green depending on how safe the connection was when the message was sent/received

I kinda like the last one, because it's a very strong indicator. It won't work for red-green colorblind people, of course, but thinking about it this way might be helpful.

If we do this, we can also provide an explanation, if someone clicks on the number for example, we can do a drop down with
"For added security, install Tor - CoyIM will use Tor automatically once installed"
"For added security, consider moving your account to a server that provides better transport security, for example xyz.com, blah.com or somewhere.org"

We have access to Snap Docker Preview and we can use docker images to build and test:

sudo docker build -t twstrike/coyim ./ci/Dockerfile
sudo docker run --rm twstrike/coyim

• Conversation windows
• Configuration dialogs

We are also interested in a list of features

(without the compat layer and so on), using the otr3 features directly

The golang verson available at debian is old (reason: http://blog.labix.org/2013/06/15/in-flight-deb-packages-of-go)

$ docker run -i -t debian:wheezy bash -c "DEBIAN_FRONTEND=noninteractive apt-get update && apt-get install -y golang && go version"
go version go1.0.2

Installing a different go version on wheezy using godeb also fails (reason: http://stackoverflow.com/a/26845235)

$ docker run -i -t debian:wheezy bash -c "DEBIAN_FRONTEND=noninteractive apt-get update && apt-get install -y golang git bzr && export GOPATH=/gopath && mkdir $GOPATH && go get github.com/niemeyer/godeb && $GOPATH/bin/godeb list"
error: Get https://code.google.com/p/go/wiki/Downloads: x509: certificate signed by unknown authority

We can instruct the user to install the testing version (similarly to pond install instructions) and it should work.

foo@tails $ apt-get install -y -t testing golang && go version
go version go1.4.2 linux/amd64

But go get still have problems to download packages from golang.org/x/. Replacing them by their github.com/golang/ counterparts fix the issue.

Related build https://travis-ci.org/twstrike/coyim/jobs/82831870

With random server, random username and id and password.

This article https://theintercept.com/2015/07/14/communicating-secret-watched/ has a bunch of steps. Almost every single manual one is a place where something can go wrong, so we should identify those places and figure out automatic ways of doing things

• Message support i18n
• UI support i18n (can be less?)

Manual section related to testing GTK+ applications (version 2)

https://developer.gnome.org/gtk2/stable/gtk2-Testing.html

According to the spec:
A valid JID is a string of [UNICODE] code points, encoded using [UTF‑8],

AFAICT, this is not what our code is doing...

We noticed something weird today. coyim hanged during the Starting TLS handshake and did not time out.

We suspected something was wrong with my Tor, then we found this in the logs

Sep 22 10:20:39.000 [notice] Your system clock just jumped 2034 seconds forward; assuming established circuits no longer work.
Sep 22 10:22:53.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:5222. Giving up. (waiting for circuit)
Sep 22 10:22:59.000 [notice] No circuits are opened. Relaxed timeout for circuit 41 (a General-purpose client 3-hop circuit in s
tate doing handshakes with channel state open) to 139912ms. However, it appears the circuit has timed out anyway. 14 guards are
live.
Sep 22 10:23:00.000 [notice] Tor has not observed any network activity for the past 2181 seconds. Disabling circuit build timeou
t recording.
Sep 22 10:23:00.000 [notice] Our IP address has changed.  Rotating keys...
Sep 22 10:23:00.000 [notice] Tor now sees network activity. Restoring circuit build timeout recording. Network was down for 2181
 seconds during 1 circuit attempts.
Sep 22 10:23:01.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Sep 22 10:23:01.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Sep 22 12:41:57.000 [notice] Catching signal TERM, exiting cleanly.

The weirdness happened during the time in between the last two lines on the log.

After restarting Tor, everything worked fine.

We should at least timeout the connection when it takes too long to do the TLS handshake.

Github pages?

Including possibility of manually trusting a cert. These are the specific pieces of functionality I think we need:

• Trusting the certificate temporarily
• Setting for manual approval of everything
• Show connection info per account, right click or something
• Look at parents of certs
• Save more than one valid cert
• Pin certs
• Recognize the google situation
• Edit list of saved certs
• Certs are saved per account

What do we plan to have as the default UI: GUI or CLI?

We can use build tags to enable the alternative UI (or disable the default UI).

For instance, pond client defaults to GUI. If you want to build a CLI version, you can use the build tag nogui: go get -tags nogui github.com/agl/pond/client

XMPP supports signing up from the client.

When you attempt to send a message after the other end has closed the OTR channel, you receive a cannot send message because secure conversation has finished error.

This is intended to protect us from accidentally sending a message through an unencrypted channel. The protocol says we should store the message for possible retransmission once when the channel is restored. Should we implement this? Where (client vs protocol)?

This is a very confusing moment, and an opportunity to improve the experience.

Somehow warn the user when it's about to disclose personal information.

Does it mean we should trust personal information to the app?

See:
agl/xmpp-client@8dc345f

Since our configuration file is not compatible, this causes slight issues.

At the moment, the only way to start a GUI instance is if you have a config file containing a saved password (on the file).

We need to have a "setup wizard" similarly the one existing in the CLI version. It would also be nice to have a simple version of an "account manager" screen. For now, it could be a simple form to edit the current account.

This might be too restrictive. We should revisit.

Should we really save passwords? Is this only interesting on a multi-account scenario?

The feature of file transfer is quite complicated, and we will implement it using several different issues, for implementing the different parts of XEPs we need - and also define the potential new standards we would need to support good encrypted support.
The issues tracking this work are:

• #377 - Out of band transfers
• #378 - Stream Initiation
• #379 - File transfer profile for stream initiation
• #380 - SOCKS5 Bytestreams
• #381 - In-band bytestreams
• #382 - Support transferring folders
• #383 - Support encrypted transfers
• #384 - Design the experience of file transfer

We will for the moment NOT implement Jingle support - it's a large, complicated beast, and since we are not planning on supporting audio or video, Jingle feels a bit like overkill.

For the encrypted data, we will in general derive the encryption key from the OTR extra symmetric key. We will likely not use the "usage" field of the extra symmetric key for anything else than the most basic tying things together.

See: agl/xmpp-client#91

twstrike/otr3 sexp parser supports files with multiple private keys. We should integrate that in the UI.

Even possible?

For example, I need to use CTRL+C , CTRL+V instead of CMD+C and CMD+V

We should randomize the order and random delay between each account connecting to their servers, to minimize fingerprinting and leak-over attacks

Adium's UI does not allow you to restart the OTR channel after the other end terminates it unless you terminate the channel on your side.

I can think of 2 possible reasons for this:

• Making sure all data structures are freed/wiped before starting another conversation
• Making sure you will reveal the final MAC keys before you start a new conversation

We are currently doing this differently. Should we do not?

The second reason seems to be reasonable enough for me, but nothing prevents me from not ending the conversation on my side. Restarting the AKE will not wipe the the reveal MAC keys, and the final MAC keys will be revealed as soon as you send the next encrypted message. But again there's no guarantee this will happen.

I'm concerned about this being a responsibility of the client rather than the protocol. Having retransmission builtin the protocol (see #47) would move this responsibility to the protocol, but would not fix it.

xmpp-client has an OTRAutoTearDown config which seems to be used to address this issue.

We are currently using a modified version of mattn/go-gtk which is GTK+ 2. That would be another open source contribution.

By the way, pond uses its own go-gtk which has been migrated to GTK+ 3.

I think we should start doing user testing soon. Maybe aim for the week of Oct 5, or Oct 12?
We should figure out what questions are most important for us to get answers too, and start thinking about how to find the right audience to ask. For technical users, we can ask TWers, but we should find at least 5 non-technical people that can help us with this as well. Let's coordinate with Bridget about how to get the most out of this.

OTR3 is supporting InstanceTag for multi devices, but we also do some change on Client to make it possible

• main 15.8% ->
• xmpp 13.2% -> 19.9% -> 28.6% -> 32.9% -> 42.2% ->
• session 0% ->
• config 14.6% -> 14.1% ->
• ui 55.9% ->