It’s been a long time since our last release, but we’ve been busy 😉 Below is a summary what’s new in the software.
Group-based privacy for channels/forums/posted
Forums, channels and posted threads (and any entity represented by a a “GXS group”) can now be limited in their distribution. This happens in two different ways: limitation to a group of pseudo-anonymous identities (the ones in People), or limitation of a group of friend nodes (the ones in Network). The choice is available when creating, or when editing the properties of a forum:
Both features considerably enhance the privacy of media that uses them. They stand for the base architecture element of a future social network layer.
External circles represent sets of pseudo-anonymous identities. A new tab in “People” allows you to create/modify them. A lot of options and handles are available there, for maximum flexibility. The downside is that the whole thing can be a bit scary 😉
People need to meet two conditions in order to be a member of a circle: they need to “apply for membership” and they need to be “granted as member”. Only the administrator of a circle can grant you, by adding you in the “invitee” list. This two-way membership not only allows people to request membership, but also prevents arbitrary circles to be created in order to spam unwanted information/data through neighbour nodes.
The GUI displays circles for which you are a member (a.k.a. “Circles I belong to”) and other circles. The bullet displays information about your status. Yellow means that you’re either applied and are waiting to be accepted, or invited and have the possibility to accept to be a member.
A contextual menu in each circle and each invitee/member of a circle allows you to act appropriately. This can be used to e.g. request membership for one of your identities, or grant membership if you’re the administrator of a circle.
Tooltips on each circle tree entry give information about:
- Circle ID: This allows you to disambiguate which circle you’re dealing with.
- Visibility: who can see this circle. A circle can indeed be restricted to another circle (see “self-restricted circles” below).
- Your role: you are either a “user”, or an “admin”. The later means you created the circle, which allows you to grant membership, and invite people to be a member.
- Distribution: unlike e.g. forums, circles spread automatically. Unless restricted to another circle, they are made visible to your neighbour nodes, so that people in this node can e.g. request membership to that circle.
- Status: states whether you are a member or not.
Security of circle-restricted forums/channels/… is ensured by encrypting the data for the message IDs, and group Meta Data (e.g. forum IDs, etc) for the set of members, using envelop encryption. Doing so, only people which are true members of the circle are able to see and handle that data, and to request and send message content. With this system, circles can contain anonymous IDs as well as signed IDs.
Now, let’s complicate this thing a bit further: since circles are also “GXS groups”, they can be themselves restricted to other circles, including themselves. With this, we can create “self-restricted” circles, which will only be visible to people in the “invitee” list. As such, the administrator of the circle not only limits the membership of people but also who can be aware that this circle even exists. For obvious reasons self-restricted circles are propagated encrypted to the “invitee” list, instead of the list of full members.
Many (Probably non all tested 😦 ) options potentially exist in this system, including pairs of circles restricted to each other, the possibility to limit the distribution of pseudo anonymous identities to a particular circle, the possibility to limit circle distribution to a local group of nodes, etc. Not all of them are made accessible by the GUI, but can be used right away by plugins to implement a new types of media.
Groups of neighbor nodes
Groups of neighbor nodes are what we call “Local groups”. They have been used already for limiting the access of shared file lists. In v0.6.1, they can also be used to limit the distribution of forums/channels/posted as well.
Since node groups are only known by the owner of the Retroshare node (they are not shared with friends), they force the node to work as a hub for message distribution. All friends in the group receive posts and information about the media, and only forward information back to the “originator” of the media, which will then share them with other nodes in the group.
Use cases include sharing personal information with friend nodes only. This may apply to photos (yes,there is a “photo-album” plugin, currently unfinished…) and your holiday movies to share with e.g. your family members, etc.
Groups of neighbor nodes can be managed in the Network tab, from the right-click menu in the list of friends.
2 – Work on RTTs and packet slicing
We have identified two major problems causing unstable round-time-trip measurements (a.k.a. RTT) : many small packets would cause an overhead due to padding in SSL encryption, and seldom large packets would block a stream with a given friend for an arbitrary long time when the bandwidth is highly challenged. We fixed this in two ways:
- small packets (< 512 bytes) are grouped before being sent to SSL. This was easy since the data stream is anyway sliced into proper packets on the other end.
- large packets are sliced into 512 bytes chunks, in a backward compatible manner. Old peers will not accept sliced packets, which is detected on the other side and cause only entire packets to be sent. When both ends of the SSL tunnel agree, packet slicing happens.
This optimization has been done in order to be able to provide better VOIP in the future (See below), but it also drastically impacts the whole software.
3 – WEB Interface
The WEB Interface part has been improved. Here’s a non exhaustive list of changes:
- possibility to paste of Retroshare links
- improved responsiveness
- switched WEB API from React to Mithril
- chat lobbies are available now
4 – Identities
Since Identities represent users beyond friend nodes, they had to deserve special care so as to make them sufficiently SPAM-proof:
- The diffusion of forum messages (and any GXS-based group message in general) can be limited to signed identities, or even identities signed by known nodes. If not, a strictly positive reputation of the message signer is needed for the message to spread.
- The software now allows to automatically ban identities based on their node signature (“People->Person->Auto ban…”).
These two options together (handled by the forum’s administrator) allow to severely reduce SPAM, at the expanse of a bit less anonymity. As far as reputation is concerned, each user can also change the threshold below which identities are banned (Options->People).
Finally Retroshare now offers the opportunity to create a new signed identity when creating a new node/location, which should help newcomers to get ready to use internal forums/chat/messages right away.
5 – Various features/improvements
The full list of improvements since v0.6.0 can be seen in the change log. The most important ones are summarized below:
- New icon set. This is a matter of taste or course 😉
- ability to define which instance receives system URL calls when running multiple Retroshare on the same computer
- auto-removal of messages in unsubscribed forums/channels
- separation of public/private RSA keys in GXS
- per-neighbour node bandwidth limits, to be changed in “Network->peer details” options
- improved chat widget (added new functions)
- fixed annoying crash on quit, due to faulty memory management
- fixed unit tests. Can be run using “make tests”.
- cache for sqlite3 access of group meta data, improving forum speed.
- usage of banned IPs in LibBitDHT
- Several bug fixes 😉
6 – Future developments (as planned)
The next features to come will be the following, with “priority”:
- differential file list exchange and removal of the old cache system (high)
- end-to-end encryption for anonymous tunnels (high)
- variable bit rate in VOIP (high)
- better (yet backward compatible) serialization code. There’s a lot to do here (medium).
- usage of external circles (or simply an admin list) to cryptographically control the access to chat lobbies (and independently for read and write access)
- opening/documenting the API for plugin developpers.
As usual, many thanks to all the developers and testers who contributed to this milestone, with a special mention to the anonymous persons who spent a lot of energy helping us improving our forum SPAM-resistance strategies… More seriously, G10H4ck, Phenom, Jenster, Jolavillette, Beluga, Zener, Sehraf, AC, ASmith, etc. stand among the people to thank.
May the privacy be with you!
Release files: https://github.com/RetroShare/RetroShare/releases/tag/0.6.1
I thought creating a new GPG Key pair with this version would be using RSA 4096. But instead it’s only RSA 2048, how come?
The option to increase PGP key size is available if you check the “advanced” box, at the expense of larger certificates.
Sure but I thought 4096 was gonna be the default key size. I am a bit disappointed because to recommend RS to my family I’ll have to explain to check the “advanced box”, select 4096 and then create an account. In my opinion 4096 should be the default.
Since I first started to use PGP in 1998, I always used the key length 4096 bits. Revelation from Edward Snowden in 2013 showed that using RSA 4096 is not “insane”.
I don’t understand why if we could use something reasonable, we choose something less reasonable. Computing power has only increased during all those years.
So even if nothing changes in next release about this, I just wanted to express it.
HI is there a problem with 6.1 QT5 32 bit system running on 64 bit OS 7 windows. All my friends are showing off line when I know they are on line. Also no chat rooms show up. Can you give me any suggestions or maybe I have to change some settings. We are a rather large group and we need retroshare to work on 64 bit systems.
yes. Try the Qt4 version. Some people have problems with the qt5 one, and we don’t know why.
Surprised to see a development target “variable bit rate in VOIP (high)”. The developers should have been aware of the weakness inherent to variable rate encoding, rendering encryption less viable for the protection of the contents. Is this supposed to be an optional or the only mode of operation? Is it wise to go for some extra efficiency by sacrificing privacy?
I agree with you that this might allow better traffic analysis (As suggested here https://www.schneier.com/blog/archives/2011/03/detecting_words.html). Retroshare tunnels however carry all sorts of packets at the same time (not only VOIP), so such a analysis would become highly unreliable. But as you say, it’s probably best to keep constant size packets all along if the bandwidth allows to do so.
Thanks for your reply Cyril.
Also the developer time is valuable for other changes, hardly for this questionable one.
When the bandwidth is precious, using more cpu intensive compression or sacrificing some quality can help. Someone suggested using Codec2, it looks extremely efficient, with a constant bit rate.
Bonjour! Cela fait 2 ans que j’utilise différentes versions de retroshare et c’est vraiment un logiciel excellent merci pour tout votre travail.
Hier voulant tester la fonction CAM avec une amie avons décidés de passer a la dernière version de retro proposée ici^^
franchement je doit avouer que le son passe trés bien et que la qualité video est au rv.
Seulement mon amie a un ordinateur portable avec une cam integré sur l’arriere du capot et c’est cette cam qui démarre par défaut on a cherché pendant une bonne heure a switcher de cam dans les paramètres windows (windows 8) et dans les paramètres retro on a malheureusement pas trouver comment faire…
Du coup on es retourné sur gmail (qui est très mauvais en terme de qualité audio vidéo)
Auriez vous une petite idée de la marche a suivre? 😉
Merci par avance 🙂
petit UP ^^ on as toujours pas trouvé de solutions je comptes sur vous merci beaucoup par avance 😉