ricochet-im / ricochet Goto Github PK

Open preferences, select a contact, modify the nickname field. Changing to another contact or closing the window won't apply the change. It does apply if you press enter in the field.

There should also be a button to apply that change.

Instead of having only one onion address that one can copy to give out to contacts, there could be an option to do like in Bitcoin wallets, where you can generate a new one for each contact (or reuse each address as often as you want) and have all transactions (in Ricochet's case, all buddies) on the same list.

That would allow using Ricochet for anonymous posts to web boards and forums, for example, or Craigslist (although it should be balanced against the off chance of one hidden service influencing the perceived bandwidth of the other and thus being correlatable, which might be a much smaller threat than tying everything to a single handle).

IM clients are expected to provide good notifications. It would be useful to support the notification frameworks on Linux (freedesktop) and OS X, at least.

Other notification features could be useful too, like new message badges on toolbar/taskbar icons.

The windows binary is currently built only for 64bit windows, which excludes some older installations. It might be worth offering 32bit as well.

PGP encryption is probably one of the best encryption standards that has withstood a lot of strong attacks.

It may be desirable if it where possible to include a way to use the the advanced secure PGP/GPG standards (such as a 4096 key lengths) to further secure the Onion Encryption and to authenticate users.

• Add a contact as nickname 'XXX'
• Have that contact go offline
• Open a message window with them
• Note the banner: 'XXX is not online. Your messages will be delivered as soon as possible.'
• Change their contact name to 'NEWNICK'

Expected outcome:

• Note the banner: 'NEWNICK is not online. Your messages will be delivered as soon as possible.'

Actual outcome:

• Note the banner: 'XXX is not online. Your messages will be delivered as soon as possible.'

Tails is Debian based and most of its software is configured to be routed through Tor. It is unclear if Torsion would run as expected by default. One concern is that it may direct the traffic through Tor before starting a the hidden service circuit.
Desired circuit:
user > guard > middle > rend-point < middle < middle < guard < user

Since torsion is packaged with a Tor client it might be configured to send its tor traffic out through a default network, which in Tails could be understood to be Tor, which could result in Tor going through Tor.
Tor within Tor circuit:
user > guard > middle > exit-node > guard > middle > rend-point < middle < middle < guard < user

For a basic example for TorChat in Tails setup: http://pastebin.ro/PcF3YA3p

Allow Ricochet to be configured to stay in the system tray, and show notifications when interesting activity occurs.

Torsion needs a couple of new functions.

First, it would be nice to have password protection similar to Bitcoin password protection.

Second, an option to send files would be nice.

Third, an OTR plug-in wouldn't hurt for additional security.

Lastly, additional encryption would never hurt.

Torsion should adopt a more open license, similar to other Tor components.

See, for instance, https://gitweb.torproject.org/tor.git?a=blob_plain;hb=HEAD;f=LICENSE.

Difficult to describe.

Easiest thing to do is see the screenshot: http://w00t.dereferenced.net/p/i/imgbin20100925-4030-mjl53d-0.jpg

'Reject' button overlaps the nickname field, and there is no spacing.
Slightly odd looking amount of space between 'reject' and 'accept', too.

Note: I am not expert on encryption, so my understand could be misguided.

Tor Hidden Services are encrypted end to end it, but I see two problems with this encryption:

1. Tor Hidden Service Encryption standards is not top of the line encryption. I don't believe it has been updated in ten years.
2. If one of the users private keys is compromised then all the conversations that was relaying under that encryption key could be read.

Off The Record should provide Perfect Forward Secrecy (https://en.wikipedia.org/wiki/Forward_secrecy#Perfect_Forward_Secrecy) to negate this unlikely but still dangerous possibility.

Note: This is probably beyond the scope of Torsion's design goals, but in attempt to solve some anonymity problems here is a rather long winded idea.

This topic is discussing a theoretical feature/enhancement to solve two issues:

1. A user's network might momentarily drop due to their ISP or VPN experiencing problems or a directed attack at them or their ISP/VPN. This is bad for anonymity as adversaries may use this to deanonymize the user.
2. The user may wish to go offline for several hours (ex. school, work, sleep, etc) and still want to be able to receive messages without keeping their computer on.

Technical/protocol changes:
A new mode OMS would require:

1. Server software or for the client to be able to optionally (at user's discretion) double as server software.
2. In the Torsion client when the users selects to activate OMS mode they locate three OMS servers with both a long uptime and reliable reachability.
3. A DHT or another means of the OMS servers of keeping record of uptime and reachability so that clients can discover them.

Scenario:

1. Bob wants to be able to receive messages even when is connection is lost or when he is offline for several hours.
2. Bob wants to be able to keep his torsion buddies from knowing when he is online and/or when is VPN/ISP has dropped his connection -- preventing correlation between his own location and his anonymous torsion identity.
3. Alice wants to talk to Bob or leave a message for Bob.
4. Carlie, Dave, Edith, Fanny, and Garth all decide to run the Onion Messaging Server (OMS) which means each of these are running their own Tor Hidden Services.
5. Bob, in torsion, changes his 'receive mode' from Onion Instant Messaging (OIM) to Onion Messaging Server (OMS).
6. Bob's client discovers (using DHT or another means) Carlie, Dave, Edith, Fanny, and Garth all running Onion Messaging Servers.
7. Bob's client selects the three most reliable with some randomization.
8. Bob's client notifies his friends which three servers his messages should be sent to.

In OMS mode:

1. Bob's Hidden Service goes offline, even if he is at his computer running Torsion.
2. Bob's Torsion no longer attempts to connect to his friends' Hidden Services.
3. Alice is no longer able to see him online, but once she gets the info on which three servers he is collecting messages from she can leave messages for him there.

Randomly between 6-12 hours the client sends out updated info to friends on which servers to reach them on. This could be directly or perhaps though those same servers with a signed message.

Basic layout idea:
Alice > Server1 >
Alice > Server2 > Bob
Alice > Server3 >

Message splitting, storage, and retrieval:

1. The message is encrypted so that only the Tor Hidden Service owner (of that private key) can read it.
2. Messages are similar to One Time Pad. The data-stream is randomly split into two streams that when combined reconstruct the original message.
3. Similar to the raid mechanism for reconstruction data when some of it is missing the two streams are both partly Xor'ed so that a third stream can be used to reconstruct the two streams in full data if one of them is lost.
4. Before sending the encrypted and split/Xor'ed message to a server the result is again encrypted with the public key of the recipients tor hidden Service and signed by the sender's key. This ensures that server will know who to give the message to and for the receiver to know the message is authentic before looking for the other parts and wasting time attempting to decrypt it.

Cons:
This method allows for the middle anonymous servers to hold encrypted message data. It is not ideal that the server can see quite a bit of info in this scenario. The server knows who sent the message, when they send it, can easily determine about how big the message is, to whom the message was sent, and when, if ever, the recipient retrieved that stored message.

Other thoughts:
After 50 hours a friend's three selected Onion Messaging Servers are considered outdated and no longer a trustworthy way to reach that friend. For example, if the user is offline for 20 hours the friends client and the receiver's servers should still allow incoming messages. The server's messages could time out after 50 hours and at the time also show that the peer is no longer available. This time would ideally be randomized by at least a few hours to prevent knowing exactly when a peer went offline (ex. exactly 50 hours ago, or always at 10pm).

An alternative to using three unknown servers is using a single or few friends to store the message. This has similar problems to the three unknown servers and goes back to giving your friends potentially a lot of info about you that you might prefer they didn't have.

If one of the three servers goes offline can the other two know about it? And if so can they recreate a new third server? This seems like an security issue as if the servers could know if one when offline they must know their address, which means they might be able to collude to recreate the source encrypted message. This is not critically bad, but it is not exactly great. I2P might be able to do this by having new tunnels with new b32 addresses that cannot be linked back to a particular host, but that might also have other problems.

See: http://w00t.dereferenced.net/p/i/imgbin20100925-4030-mjl53d-0.jpg

Appears as:

Date Moments ago (...)
:

instead of:
Date: Moments ago (...)

What are the accepted ways of donating to the project? It would be good to make this more public. I want to make sure I can do something to keep this project alive, even if it's my insignificant 5 usd/month. I'm trying Gittip, but it's currently unclaimed: https://www.gittip.com/on/github/ricochet-im/. Thanks!

From a brief investigation, it should be possible to offer static binaries for specific Linux distributions that can be run without needing a system copy of Qt5. With a little extra work, it may even be possible to get binaries usable between several distributions.

This is a very important step towards encouraging adoption.

Since my ID is already a hidden service, could Ricochet use it to serve a password-protected javascript web interface?

It would work as a "bouncer" that I can access from anywhere that has a Tor Browser (as long as the computer that has Ricochet is on), which would make it super convenient, optionally keeping state across remote sessions and maybe even allowing usage from mobile browsers (asynchronous experience).

We want Ricochet packaged for:

• Debian
• Ubuntu
• Fedora (and other redhat systems)
• Arch

In addition to writing the packages, each of these needs someone that is willing to volunteer to keep them up to date.

Being able to transfer files would be a useful feature, to enable whistleblowers, etc.

The friend request option isn't always working. Friend categories will be nice. Timestamps in the chat box will be a cool addition. Ignore, block, and go invisible options may be helpful. Automatic response when away is another thing to consider.

The timestamp presented when a contact was last seen should be kept up to date in more places.

It is a bit misleading to go offline and see '57 minutes ago' or so when you come straight back on, when you've been speaking with them for an hour or two. :)

Instead of doing what it says it should do on the box, this launches the configuration wizard (?).

When clicking on Vidalia in the wizard, it helpfully tells you to start Vidalia.

Sounds like a missing feature! :p

Entity escaping in 1.0.1 is apparently overly careful. Some characters like " show up in chat as ".

Preferably quickly, so perhaps also tie it to a hotkey?

Helps get to critical mass. It's been easy getting people to install and use Ricochet the first time, but they often don't have immediate reason to open it and quickly forget about it.

I configured a name for myself.

While this name is not propagated to others (as expected), I do expect to see it used consistently in the UI on my end. Currently, this is not the case, as in conversations, I show up as 'Me:'

Whonix is Debian based and its gateway VM would be need to setup to run the hidden service while the workstation VM runs the UI and backend that directs its connected to the gateway where the Tor client is running.

Example on how TorChat is setup in Whonix: http://zo7fksnun4b4v4jv.onion/wiki/Chat#TorChat

There are a few problems that make it difficult to debug issues with bundled Tor:

• The error message can be empty in one case from TorProcessPrivate::processFinished
• Any logs/output are not available in the UI via StartupStatusPage
• There is no hint as to what the user should do next to solve their problem

This is turning up in one case from OS X Mountain Lion, cause unknown.

Settings are currently written in INI form via QSettings. This includes important, potentially irreplaceable information like the contacts list.

QSettings is a known-buggy mess of technical debt. Most notably, it truncates before writing and on a variety of read errors, meaning all settings can easily be lost (https://bugreports.qt-project.org/browse/QTBUG-21739).

JSON + QSaveFile is a much safer solution that is still easily readable and hand-modifiable.

It would be good to be able to have configurable sound events on an incoming message, contact goes on / offline.

Proper internationalization is a requirement. I started on the code for this and set up https://www.transifex.com/projects/p/torsion/ already.

Ricochet currently only publishes one hidden service per client. There are a lot of things that could be improved if we could publish more of them simultaneously, or rotate them automatically.

Before that can happen, I need to understand the implications it might have for anonymity. In particular:

• Assuming the adversary knows they are related, does publishing >1 hidden service from the same client harm anonymity?
• Assuming the adversary can follow them through changes, does switching hidden service addresses harm anonymity (e.g. by effectively increasing the guard rotation interval)?
• How easily can an adversary determine that >1 hidden services are linked? How does this apply for various adversaries, e.g. simple clients, guards, ISPs, HSDirs?
• At what point does publishing services start to negatively impact the Tor network?

There should be [optional] audio alerts when messages are received and in other relevant cases (message sent? contact online?).

The first step will be finding some suitably licensed generic audio, or figuring out how to use platform audio resources.

ricochet.im needs a proper SSL certificate. This is currently waiting on hearing back from a CA about a no-cost cert, but they aren't being fast..

Find someone to create a nice application icon. Minimum sizes of 256x256, 128x128, 32x32, and 16x16. 512x512 preferred.

Ideas welcome

Specs: Torsion v1.0.0-10-g2c52502 on Debian 7 (64bit) in VirtualBox:

Repro Steps:

1. Open the Torsion binary and successfully connect to the Tor network.
2. Click the "Add Contact" button/icon.
3. Click into the "ID:" field and attempt to enter any text or any thing from the clipboard.

Results: The user is unable to enter any text into the "ID:" field.

Expected Result: The user is able to enter text into the "ID:" field.

Terminal output:
#user runs "./Torsion" from terminal while in the path with the binary.
OpenGL Warning: Failed to connect to host. Make sure 3D acceleration is enabled for this VM.
qrc:/ui/MainWindow.qml:92:5: QML Loader: Binding loop detected for property "active"
#user clicks the "Add Contact" button/icon
qrc:/ui/AddContactDialog.qml:19:38: Unable to assign [undefined] to QString

Notes:
The text courser flashes in the "ID:" field as if it is waiting for user input. User is able to write text in the "Name:" field and in the "Message:" field.

Possible related issue:
In Preferences the user is unable to edit or enter IDs.

Repro Steps:

1. Open the Torsion binary and successfully connect to the Tor network.
2. Click the "Torsion Preferences" button/icon.
3. While on the "Contacts" tab click into the "ID:" field and attempt to enter any text or any thing from the clipboard.

Results: The user is unable to click into the "ID:" field. The courser will not appear in that field, and the user is unable to enter a ID for a contact.

Expected Result: The user is able to enter text into the "ID:" field. Alternatively, if the user is not meant to type ids here or edit them here, the ID field should not be a box (even grayed out slightly). It should just be the contacts id without the surrounding box, as the box indicates it can be changed at this location.

Specs: Torsion v1.0.0-10-g2c52502 on Debian 7 (64bit) in VirtualBox:

Repro Steps:

1. Open the Torsion binary and successfully connect to the Tor network.
2. Click the "Torsion Preferences"
3. When you have no contacts press the "Remove" button.

Results: The Torsion binary crashes (terminal crash output provided below).

Expected Result: System does nothing if no contacts are available. System continues without critical error.

Terminal output:
#user runs "./Torsion" from terminal while in the path with the binary.
OpenGL Warning: Failed to connect to host. Make sure 3D acceleration is enabled for this VM.
qrc:/ui/MainWindow.qml:92:5: QML Loader: Binding loop detected for property "active"
#user clicks the "Torsion Preferences"
qrc:/ui/ContactPreferences.qml:42: TypeError: Cannot read property 'nickname' of null
qrc:/ui/ContactPreferences.qml:51: TypeError: Cannot read property 'contactID' of null
qrc:/ui/ContactPreferences.qml:58: TypeError: Cannot call method 'readSetting' of null
qrc:/ui/ContactPreferences.qml:67: TypeError: Cannot call method 'readSetting' of null
#user clicks the "Remove" button.
qrc:/ui/MessageDialogWrapper.qml:4:1: Type MessageDialog unavailable
qrc:/QtQuick/Dialogs/WidgetMessageDialog.qml:42:1: module "QtQuick.PrivateWidgets" is not installed
Segmentation fault
#end of crashlog.

Notes:
Note that this same crash also occurs if the binary is run from GUI as opposed to terminal.

Specs: Torsion v1.0.0-10-g2c52502 on Debian 7 (64bit) in VirtualBox:

Repro Steps:

1. Open the Torsion binary and successfully connect to the Tor network.
2. Click the "Preferences" button/icon.
3. Click the "Tor" tab.
4. Wait 3 minutes looking for a notice about "Closing stream for '[scrubbed].onion': hidden service is unavailable (try again later)."

Results:
The Torsion program is making onion connections when the user has no contacts. This is worrying.

Expected Result: The Torsion program only make authorized onion connection attempts.

Notes:
Perhaps these unexplained and failing onion attempts are expected behavior as Torison could be using a Hidden service for updates or for some other reason, but I don't recall any comment in the design or protocol documents mentioning it. Could it be attempting to connect to my own published ID (similar to how Torchat does it by default)?

Is there an easy way to have the hidden service private key at more than one computer (home/work)? Export/import key might be enough.

If you try and run the current static version of the torsion client on Tails it fails as it looks like the client was built on a 64 bit system:

amnesia@amnesia:/torsion$ file Torsion
Torsion: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, not stripped
amnesia@amnesia:/torsion$ ldd -v tor
not a dynamic executable
amnesia@amnesia:/torsion$ ./Torsion
bash: ./Torsion: cannot execute binary file
amnesia@amnesia:/torsion$ ./tor
bash: ./tor: cannot execute binary file
amnesia@amnesia:~/torsion$

The ability to do a /me (like in other protocols such as jabber and IRC) would be great, as it is often missed.

WIP concept to improve on the contact list UI:

The indicators on top are presence controls. I'm not sure there's much value in a global "offline" presence. I'm not fond of the icons or the behavior for the add contact dialog and preferences.

I have ideas bouncing around about creating contact groups, publishing a hidden service per group, and moving the presence controls onto each individual group. That would allow some separation, selectively controlling online status for different groups of contacts, and might help with a few other design questions. It's not a solid enough idea to turn into a real suggestion yet.

Specs: Torsion v1.0.0-10-g2c52502 on Debian 7 (64bit) in VirtualBox:

Repro Steps:

1. Open the Torsion binary and successfully connect to the Tor network.
2. Click the "Add Contact" button/icon.
3. Click into the "ID:" field and paste a valid id from the clipboard: (torsion:rs7ce36jsj24ogfw)

Results: The font for your own ID and the peers id can become illegible (see attached screenshot)

Expected Result: The fonts remain legible.

Notes:
This could be a result from the copied text font. (gedit: Monospace [size 11]). The torsion contact link was copied from the file "README" opened in gedit under gnome. The README file is packaged in the Torsion v1.0.0-10-g2c52502 for Debian 7 compressed file.

It is a common feature of IM clients that, if you click an IM window (or even focus it in some cases) that focus will be restored on the text input, to easily write a message to a contact.

This makes it a lot less painful to write a message, especially when doing other things, so I'd like to see it.

Hello,

I run QT creator, i have error compilation "Project ERROR: libcrypto development package not found".
-->8--------------------------------------------------------------------------------------------------------
11:26:24: Exécution des étapes pour le projet Torsion...
11:26:24: Débute : "/home/creaprog/Qt/5.2.1/gcc_64/bin/qmake" /home/creaprog/Documents/torsion/Torsion.pro -r -spec linux-g++ CONFIG+=debug CONFIG+=declarative_debug CONFIG+=qml_debug
Project ERROR: libcrypto development package not found
11:26:24: Le processus "/home/creaprog/Qt/5.2.1/gcc_64/bin/qmake" s'est terminé avec le code 3.
Erreur lors de la compilation/déploiement du projet Torsion (kit : Desktop Qt 5.2.1 GCC 64bit)
Lors de l'exécution de l'étape "qmake"
11:26:24: Temps écoulé : 00:00.
-->8--------------------------------------------------------------------------------------------------------

The name 'torsion' was chosen at random some years ago, and has three major problems:

• It vaguely implies a relationship to Tor that doesn't exist, when it should be clearly independent
• There is an unpleasant association with a testicular condition
• It's not very searchable

If a better name can be chosen, it would be good to change this as soon as possible.

Detect URLs in chat, style them, and make them clickable.

To handle clicked URLs, present the user with a choice (in a popup of some kind) between using the default browser (discouraged), launching a custom executable, or copying to the clipboard. Allow one of these options to be made the default, and provide all of them in a context menu on URLs as well.

If 'tor://' URLs are implemented for torbutton as was discussed, that could also be a worthwhile option.

It would be nice to have a unified window mode similar to some newer instant messaging clients. That should be a fairly simple QML project.

Supporting avatars is a 'usual' IM feature, and a useful one.

Careful attention must be paid to security issues, such as malformed images.