Самое полное руководство по работе с TweetDeck :: (12) Oleg Michman 25% �� 146% ☢️ ☣️⚠️ (@CASBT_UA) / Твіттер

 

RetroShare – Page 3 – adorabilis

By User 

adorable.wordpress.com

19 min

July 20, 2014

View Original

DEFINITION

RetroShare is an anonymous, decentralized, encrypted file sharing and communication network based on the f2f paradigm .

Anonymity : any file sharing and communication activity of a network participant is not personalized either by an outside observer - due to the privacy of the network - or by an arbitrary network node - due to the anonymous tunneling of encrypted data through random and constantly changing branches of the network environment. If there is such a need, the platform allows the user to personalize himself by using identities signed by a certificate. However, outside the so-called “trusted environment” there is no information at all about network participants - it is impossible to even determine the number of nodes outside the environment. The described case can be characterized as absolute anonymity , when permitteduser data is not only difficult to detect, but in principle impossible to detect due to the specifics of f2f: the information flow is distributed only from participant to participant.

This approach takes the network to a qualitatively new level and, first of all, contributes to a significant increase in the speed of data exchange compared to other networks that provide good anonymity (see, for example, Perfect Dark), which require specific approaches to masking user activity on the network , negatively affecting its performance.

Decentralization of RetroShare: the network does not have several or one central server computer designed to connect participants with each other or exchange data between them. Each member of the RetroShare network is both a client and a server. Data encryption on the RetroShare network is provided by 2048-, 3072-, or 4096-bit asymmetric keys and a 256-bit session symmetric key. The reliability of key exchange over an open communication channel is ensured by the Diffie-Hellman algorithm .

RetroShare as a communication tool includes:

• broadcast chat within a closed group;
• public and private chats;
• email;
• forum;
• VoIP;
• broadcasting an RSS feed from the open web to the dark web.

File sharing in RetroShare allows you to:

• provide network users with anonymous access to an unlimited number of files;
• create thematic collections of files;
• provide access to certain folders to a certain group or groups of people (family, colleagues, my only friend, group1, group2, etc.);
• automatically give access to new files that appear in access folders;
• give fragments of undownloaded files to other interested participants;
• check the integrity of received files.

An auxiliary file sharing service in RetroShare is content announcement channels. Channels can be either public or private. The right to publish in channels can only be granted to its creator, or to a certain group of trusted participants to whom the creator has delegated the rights to publish. Downloading content announced in the channel can occur either manually or automatically as new announcements are published.

GENESIS

The idea for creating RetroShare is rooted in the desire to create a reliable communication tool that allows you to connect two computers directly, without the participation of any auxiliary services . Reliability refers primarily to the confidentiality of information transmission over open communication channels, and reliability is the key word here. The desire to create such a system did not seem impossible at the end of 2005, since for almost three decades within the framework of number theory, or rather, the theory of large numbers, effective algorithms for encrypting discrete information have been developed, which for a decade and a half have been widely used for strong encryption Email.

Obviously, the focus on creating only a two-way encrypted communication channel could not be considered something breakthrough - encrypted FTP has long existed, for example - and therefore connections between friends must be extensible, which would turn the data transmission channel into a data transmission network. An additional impetus for the implementation of the idea at that time, apparently, was the rapidly growing popularity of the BitTorrent protocol. Thus, genetically, RetroShare turned out to be the brainchild of strong encryption and decentralization of data exchange .

For the continued successful growth and development of RetroShare, it was necessary to use many other small and large approaches, methods and technologies: distributed hash tables (DHT), Turtle routing, universal plug and play (UPnP) for automatic port forwarding, Diffie-Hellman algorithm for exclusion compromise encryption keys, beautiful graphical shell based on Qtand much more. In the process of using the RetroShare crypto platform, some of its shortcomings were discovered, and ways to modernization appeared. So, in 2012, the developers came up with the idea of ​​​​improving the cache exchange protocol, which led to the creation of GXS - General eXchange System - designed to reduce the amount of data transferred between participants. And earlier, in 2010, public chat rooms were implemented where crypto platform participants could communicate with each other and exchange public keys, which significantly facilitated the growth of the network and made the user community more monolithic and united.

Only the author of the idea and the first developer, a user under the pseudonym DrBob, can name the exact date of birth of RetroShare, but the approximate date is January 2006. As of 2014, the estimated cost of the project was about $20 million.

TERMINOLOGY

Darknet , or dark network, or dark network is a private file-sharing communication network in which connections and data exchange are carried out only between nodes with established mutual trust.

The term “mutual trust” has no relation to a similar concept accepted in everyday life . Establishing trust in the dark network is the mutual exchange of certificates between two dark network nodes for the subsequent creation of a private encrypted data transmission channel. In reality, two participants with “established mutual trust” in the human sense may not trust each other at all. The exchange of certificates and the connection of nodes creates an additional branch in the dark network topology, through which it becomes possible to anonymously tunnel data intended both for a neighboring node and for completely strangers, or, in other words, remote nodes. The data tunneling protocol does not provide information about the number and characteristics of remote nodes; according to the f2f paradigm, it is not possible to obtain such data under any conditions.

The term “private” is understood in two senses:

• closed to access and use of resources by third parties - entry to outsiders is prohibited;
• All data is transmitted from node to node in encrypted form - eavesdropping is excluded.

Establishing a private connection in the dark network is carried out according to a specially developed protocol that defines the essence, properties and characteristics of the network. The protocols of all existing dark networks are necessarily based on asymmetric encryption and authentication . Additional algorithmic features of protocols for establishing trust and data exchange are directly related to the tasks that the communication network is designed to solve, and can differ significantly from network to network.

Due to the fact that the darknet involves the establishment of an encrypted connection between specific nodes , it is sometimes said that it is a network of trusted participants, or a network of friends - friend-to-friend (f2f, cf. p2p ). The RetroShare cryptonetwork is a darknet, a dark network in which mutual trust is established through the exchange of personal certificates between participants. Here you can clearly reflect the difference between f2f and p2p networks:

• in f2f networks - private networks - an attacker or any outsider does not have the opportunity to connect to the network node he is interested in (the user’s computer) until the user himself expresses his good will;
• p2p networks - public networks - do not have the ability to block network connections initiated by unknown persons or organizations .

In fact, f2f networks in general and RetroShare in particular guarantee the user the anonymity of any activity, thanks to a specific structure and topology (f2f paradigm), and also naturally limit any destructive practices on the part of third parties. Anonymous p2p networks are relatively easy to analyze and collect a large amount of data, including the IP addresses of all network participants without exception . This does not mean that it is very easy to de-anonymize the activities of participants, but the very fact of participation in such a network cannot be hidden.

In addition to the RetroShare crypto platform, the class of functioning and developing dark networks also includes FreeNet and GNUnet .

Attention!

Despite the similarity of terms, dark networks ( darknets , private f2f networks) should not be confused with the dark Internet ( lost Internet , <article deleted>) and the deep Internet ( invisible, remote Internet). The dark, or lost, Internet is a part of the Internet that cannot be connected to using standard means and protocols that currently exist. The Lost Internet typically involves archaic departmental communications networks that have been in operation since the 70s and 80s to this day. The Deep Internet is a part of the Internet that operates using standard protocols, but is not indexed by search engines and is unknown to anyone except a limited circle of people. The Deep Internet is largely associated with criminal activity by individuals or groups of individuals on the Internet.

A friend is a participant in the f2f network with whom a mutual exchange of certificates has been carried out, which algorithmically means establishing an encrypted connection with one of the network nodes . The appearance of the term is associated with the earliest stage of development of the cryptonetwork, when the latter really consisted only of people who knew each other personally.

Currently, the term “friend” does not correspond to the technical background of the platform, is an anachronism and often misleads users regarding the specifics, capabilities and potential of RetroShare. Instead of the term “friend”, it is recommended to use a term that more accurately corresponds to the real state of affairs - “ network node ”, “ trusted participant ”, “ trusted peer ” or simply “ peer ”.

User certificate is a text structure containing:

• unique public key (2048-, 3072- or 4096-bit number);
• location ID (128-bit number);
• internal IP address and access port of the user computer;
• external IP address and access port of the user computer;
• location (text string).

The value of the external IP address can be arbitrary and does not correspond to the real IP address. If it is necessary to establish a connection, RetroShare has the ability to determine the real IP address of the participant via DHT or discovery service. An internal IP address is useful if some of the trusted participants are on the local network. The location identifier is the lookup value in the DHT, which is used to establish the IP address of the potential trusted participant and make the connection. The location is set with the goal of using the same public key on different computers.

The IP address present in the personal certificate is not a direct element of addressing in the dark network and is necessary to establish a private encrypted TCP connection with the network. The address of the packet recipient is the identifier of the public encryption key, which can be personalized - in the case of using a certificate - or anonymous - in the case of using a separate pair of public and private keys. The second option is used for anonymous tunneling of encrypted data, when the pair of encryption keys used is not tied to the user’s personal certificate, and therefore is not a de-anonymizing element of the network protocol.

Keys intended for anonymous sharing can be created either automatically, for example, when sharing files, or manually, for example, when creating a message on a forum or in a chat on behalf of an anonymous identifier. The number of anonymous key pairs created is unlimited; you can manually synthesize as many of them as you like.

RetroShare version 0.6 has several exciting changes:

1. the contents of the certificate are unreadable by humans due to special mixing and coding of the fields included in it;
2. the connection can be made through hidden services of the anonymous Tor network; There are no IP addresses in this case; see details here .

It should be noted: both in the regular RetroShare network and in the network based on Tor hidden services, the anonymity of the user’s file-sharing and communication activities is guaranteed by anonymous tunneling of data through randomly reconfigured transmission channels . The reasons why it makes more sense to use Tor hidden services are listed in the article on connecting to the network (section " Objective function ").

A trusted environment is a complete set of network nodes with which a private encrypted information transmission channel has been established.

The immediate environment is the union of the trusted environment and the trusted environments of each trusted participant.

The immediate environment limits the ability to send email within the network. File sharing and, in the presence of a large trusted environment, the distribution of forums and channels are not limited to the immediate environment, but cover the entire network. Public keys (not certificates!) of the immediate neighborhood are available in the “Key Array” tab of the global “Friends” section.

An anonymous tunnel is a virtual encrypted data transmission channel based on a chain of connected nodes with established mutual trust; neither the source of the information packet nor its recipient knows which nodes it passes through; an outside observer cannot determine either the initiator of the chain creation or the target node. Anonymous data tunneling involves the use of encryption keys that are not tied to a personal certificate . When the tunnel is rebuilt, the encryption key pair is automatically changed to another, even if communication is initiated with the same node as before. The essence and properties of anonymous tunnels in RetroShare are identical to the chains of the Tor network, except that in Tor the length of the chain is limited to 6 nodes, and in RetroShare the number of intermediate nodes is in principle unlimited and they constantly change during the transfer of even small files.

Anonymous tunnels are created and destroyed without user interaction. At any time, an active tunnel can be destroyed due to the disconnection of a transit node from the RetroShare network. The farther the source and receiver are topologically from each other, the greater the likelihood of tunnel destruction and the less likelihood of creating a stable data transmission channel. Structurally, the data generated by various RetroShare services (chat, mail, file sharing, etc.) do not differ from each other - GXS (RetroShare General eXchange System) is used everywhere. Consequently, some encrypted data during transmission masks other encrypted data, which prevents the enemy from performing a statistical analysis of the traffic. (Principle adopted by another f2f network, GNUnet.)

 Content announcement channels , or channels for short, are a RetroShare service in the form of a list of messages, each element of which contains:

• the headline of the message;
• message logo;
• text message body;
• information about the file, files, collection being posted;
• controls.

The right to publish in a channel has either only its creator, or the creator and a certain group of trusted participants to whom the rights to the channel have been delegated. Channels can be either public, when its content is distributed from subscriber to subscriber, or private, when its content is available for viewing only by persons predetermined by the creator.

The Turtle router is a key low-level element of the RetroShare core, providing the creation and destruction of tunnels, the transmission of search queries, the functioning of chats and forums, and the distribution of content. In RetroShare v. 0.6 The Turtle router, called the global router, has undergone a major overhaul and currently has little in common with its original algorithm.

Managing trusted participants . Set: global tab “Friends” → context menu of a friend → “Details about a friend”.

1. Trust is a term defined in the “web of trust” model, or web of trust . RetroShare does not play any direct role in the functioning.
2. Anonymous tunnels : accept/reject requests to create a tunnel from this participant. It is recommended to always take.
3. Detection : give/don't give this participant information about my trusted participants. A very useful option when someone adds a trusted participant from an array of keys. The decision on admission is made based on the accepted security concept.
4. Forums and channels : allow/prohibit the sharing of existing forums/channels with this trusted member. It is recommended to allow.
5. Direct source : allow/deny direct access to downloading files and exchanging network packets carrying information about channels/forums/publications. The decision on admission is made based on the accepted security concept.

The “Discovery” parameter can be set globally for all users in the “Settings → Server → Network Configuration” section.

IMPORTANT !

Point 5 plays a special role in terms of anonymizing the activities of a participant in the dark network . When adding a new certificate, be sure to consider and monitor the installation of this option. Two possible situations:

1. Direct access is allowed : when encrypting a network packet, the private key of your certificate is used ; your trusted circle knows for sure that you are the source of the content being sent; the immediate environment and other network participants have no information about the source of the information packet. This way you are not an anonymous source to your trusted environment.
2. Direct access is prohibited: when encrypting/decrypting a network packet , a randomly generated key pair that is not tied to your certificate is used ; your trusted environment, your immediate environment, and other network participants do not have information about the source of the packet. Thus, you are an anonymous source for your trusted environment and other users of the dark web.

The need for direct access is due to the fact that in some cases it is advisable to be sure that the content comes from that specific person and not from an anonymous source.

Network Visibility :

In the RetroShare crypto platform, it is possible to set the different nature of the client-server behavior on the network - network visibility. The type of network visibility is determined based on the user's accepted security concept.

1. Public mode is a type of client-server behavior in which the latter allows any  trusted participant  to broadcast information about other trusted participants, and is also involved in a distributed hash table (DHT), which means that information about the participant’s IP address is available to both network users and outside observers. Knowledge of the IP address by third parties does not mean that they have access to information transmitted on the cryptonetwork: they will only know the fact that this user may be connected to the RetroShare network. Participation in DHT does not provide any other information. Access to transmitted data without knowledge of the participant’s private key is prohibited. The mode implements reliable mechanisms for searching and connecting new trusted participants and is useful at the initial stage of forming a group of trusted participants. Once the required volume of the trusted environment has been achieved, it is recommended to switch to a mode that excludes working with DHT: private or darknet.
2. Private mode is a type of client-server behavior in which only the discovery service functions , and the user’s IP address does not appear in open networks. This mode is optimal from the point of view of security and efficiency of client-server operation.
3. Reversed mode : The client-server participates in DHT propagation, but does not broadcast information about trusted participants. The mode is used temporarily when it is necessary to quickly find and connect to a user when his certificate contains a false IP address.
4. Darknet mode , or “dark network” mode: information about the IP address of the crypto platform user is not available, the client-server does not broadcast any data about its trusted environment. Recommended in cases where the highest network security is required.

Network activity . Sets the amount and type of traffic transmitted through this node, as well as some features of client behavior:

• Normal mode : everything is broadcast at the highest possible speed; The client's behavior is normal.
• Without anonymous : prohibit the transit of other people's traffic through the node. The mode reduces traffic and processor load.
• Game Mode : Same as normal mode, but does not display pop-ups on the screen.
• Economical : Client-server operates as normal, but all types of traffic are limited.

 ADVANTAGES

The positive features, properties, characteristics and capabilities of the RetroShare crypto platform can be divided into three large groups:

1. efficient file sharing;
2. extensive communication opportunities;
3. high degree of security.

An assessment of both the advantages of the RetroShare network and its disadvantages is the result of a comparison with existing networks and data transmission systems.

File sharing

The first thing that catches your eye and makes a strong impression when you connect to the RetroShare network is its extremely powerful and convenient system for searching and sharing files on the network. On the client’s side, there are ample opportunities to refine the results:

• search by name or fragment of a name;
• search by extension or extension fragment;
• search for trusted participants along the path to the file;
• search by SHA1 hash of a file or collection;
• search by creation date and file size;
• search with or without case sensitivity,

on the server side, this is the above-mentioned ability to give various files or folders to various predefined groups of trusted participants , which is basically impossible in existing p2p networks . If the user does not need to differentiate levels of access to his own resources, then it is possible to establish a basic anonymous access mode. In this case, the resources are available for download by all users logged into the network. On the other hand, the same folder can be accessed by the “Family” group only anonymously, even though all members of this group are trusted, and by the “Friends” group - directly, with the ability to have information about who is from the trusted environment is the true source of data. Outside the trusted environment, files, if allowed by the user, are always accessible only anonymously. The simplest examples are given here, but in real situations it is possible to implement much more sophisticated ways of sharing local resources.

The main part of the settings for access to local resources is set by the folder management wizard - an icon in the form of a folder with a plus sign at the top left of the graphic window - and looks something like this:

Three basic modes of access to resources are set by one or more access flags:

1. green folder – access to files ( viewing the folder structure and downloading files ) is allowed only to friends from groups (the strictest access);
2. blue folder – access ( viewing the folder structure and downloading files ) is allowed to everyone in the trusted environment; The “blue” folder completely overlaps the “green” one in providing access to shared resources;
3. blue mask - anonymous access ( only downloading files ) is allowed to any network participant . This is the widest range of access. Searching for files shared in this way is only possible through an anonymous network search service or via a direct link.

The clarifying part of the access settings is determined by the rights of each specific trusted peer, set by clicking the icon with a shield view at the top left of the client’s graphical interface.

Communication and connection between participants

The material is well presented in the corresponding section of the article about RetroShare in the Russian-language Wikipedia.

Safety

RetroShare is a very user-friendly system. On the one hand, it operates according to basic algorithms, including mandatory encryption of all types of traffic with an unchanged asymmetric key, a one-time symmetric session key and other specific approaches, on the other hand, all further guarantees of anonymity and confidentiality fall on the shoulders of the user . This especially applies to the user-implemented security concept, methods for expanding network connections, and the topology of the created subnet. Of course, absolute security is impossible and, first of all, this is due to the human factor, but out of all the many existing crypto networks, RetroShare potentially gives the best results in terms of anonymity, confidentiality , and therefore security. As an additional advantage, we should again mention the significantly higher file transfer speed in comparison with known networks and data transfer systems.

To achieve potential safety in RetroShare:

1. You should not publish your own certificates either in forums and chats within the network, or, especially, in open networks - you are revealing the fact of using the cryptonetwork;
2. You should not accept certificates from other participants if you are not sure of their reliability ;
3. in the network configurator, enable either private or darknet client-server mode - your IP address will not appear anywhere on the open network.

Look for opportunities to transfer certificates either in person or through trusted channels or methods of transfer of information. The inaccessibility of your certificate to third parties and the reliability of trusted contacts is the basis on which your security is based. If you are not sure about a trusted peer, do not allow it to connect directly - Direct Source - and disable the discovery service for it. You won't hide the fact that you are using RetroShare from him, but you will significantly limit his knowledge of you, your resources, and your trusted environment.

Let us remind you once again: in almost all non-f2f networks, the enemy has the opportunity to compile a complete list of IP addresses of all network participants , which means revealing not only the very fact of using the network, but also in some cases de-anonymizing their activities using certain analysis methods. And only in f2f platforms, knowledge of the IP address is limited to only a small group of participants, and it is fundamentally impossible to detect other participants when DHT is disabled , since data in RetroShare is transferred from trusted to trusted and nothing else.

DISADVANTAGES AND LIMITATIONS

There are two groups of RetroShare disadvantages:

1. disadvantages associated with the friend-to-friend concept;
2. shortcomings of the graphical interface and client implementation.

If the second group of shortcomings is largely related to user preferences and mistakes of developers, which means it can always be leveled out, then the first group is fundamentally irremovable and you need to remember this when you work in the RetroShare crypto platform. The disadvantages of RetroShare associated with the concept underlying it can be considered features of the crypto platform.

Disadvantages associated with the f2f concept

• Significant load on the central processor and RAM. Working with large numbers, which are an integral part of certificates and private keys, requires a considerable amount of computer RAM and computing resources of the central processor. Considering that the RetroShare crypto platform encrypts not only file sharing, but also messages in forums, channels and chats, then on weak machines such a load can create certain problems in the operation of the client-server. As an example: with the number of trusted peers - 50 and connected - 18, several dozen channels, several hundred forums, active chats, the amount of RAM allocated for the client was 420 MB, and the constant load on the central processor (Intel, 2 cores; 2. 8 GHz) – 2…6%. Of course, the numbers are approximate, but this is the order.
• The comparative slowness of the spread of forums and channels across the network . The transmission of forums and, in particular, content announcement channels are not a high priority in the operation of the Turtle router. First of all, chats are broadcast and tunnels are laid for file sharing. Therefore, messages from both services, depending on the network load and its topology, can reach the interested party from several minutes to several hours. The above does not apply to the immediate environment. There, content is distributed almost instantly. Content is distributed from subscriber to subscriber. If the network is not extensive, a channel or forum may “stall” in some node when the owner of the node has not subscribed to a particular resource. If the resource is filled with interesting unique content and has many subscribers, then no problems arise with the distribution of the channel or forum. This feature, de facto, is a naturally organized protection against spam on the network: useless or empty channels will not be distributed: their distribution will stop within the trusted environment.
• Unstable file transfer speed from a very distant source - 5 or more jumps. There is one peculiarity here. The Turtle router is a very flexible algorithm, and the RetroShare network topology is very branched and chaotic in its structure. At the first moment, Turtle can indeed build a tunnel to the source that is unsuccessful in terms of distance, but, as a rule, after some time more “closer” paths are found and then both the data exchange speed and the channel itself stabilize. In nine cases out of ten, a reliable data transmission channel is established within 1–10 minutes at a speed close to the maximum throughput of the recipient’s Internet channel.
• The difficulty of exchanging certificates in a secure manner . Since it is highly undesirable to publish personal certificates in open sources, the problem of transferring them to a potential trusted peer arises. Currently, the most secure means for transmitting RetroShare certificates are encrypted email and encrypted messaging services. It is clear that in this case, too, the problem of the authenticity of the correspondent arises. However, based on the real situation, you can always choose the most appropriate certificate exchange option for a particular user. But, as mentioned above, the most reliable way is to transfer the certificate in person.

Disadvantages of the GUI and client implementation

• Interface overload .
• Lots of fine-tuning client-server settings . With an ill-considered approach, this situation can lead to de-anonymization of a network participant. This especially applies to cases of file sharing or distribution of content through channels, when by mistake a private announcement can be made in a public channel. Remember! ONCE PUBLISHED IN A FORUM OR CHANNEL, IT IS IMPOSSIBLE TO REMOVE FROM THE NETWORK. Before you publish anything, look again at what you are publishing and what publishing mode is selected: private or public.
• Unpresentable appearance of forums by default. For people who respect not only content, but also form, there are difficulties in bringing the content of a published message into the proper form. The difficulty is that it is better to type the text of the message in a word processor and only then copy it into the forum.
• Lack of ability to set font size and type in channels .
• Lack of ability to monitor and analyze traffic structure . It is not clear from the status bar which part of the traffic is private and which part is transit. There is no visualization of different types of traffic.
• Inability to unhash files of a certain type .

PRACTICAL RECOMMENDATIONS

• For security reasons, the nickname in the chat must be different from the nickname in the certificate.
• If possible, do not publish your own certificate in chat rooms and under no circumstances on forums.
• Observe chat conversations. At some point, it will become clear who you shouldn’t be wary of and who you shouldn’t trust.
• Silent people in chats cannot be considered people who should be trusted. Therefore, if you would like to exchange certificates with someone, identify yourself in some way, at least in general, non-binding phrases. By doing this, you will show that you are a living person who deserves attention. In the RetroShare community, it is considered good manners to indicate why you joined the platform, as well as where you heard about it.
• Find in the forums links to certificates of hosts that are constantly connected to RetroShare - the so-called “24/7 VPS” - and send emails with your certificate to several of them through the internal RetroShare mail service. Perhaps they will respond to you and you will have reliable round-the-clock contact with the network.
• Help two or three of your friends connect to RetroShare. You will have nodes with absolute trust.
• If you have multiple computers at home or work, you can create one gateway node that provides access to RetroShare, and connect your main computer to that gateway. Thus, all communications with the network will be carried out by the gateway computer, and it will be your only peer that you can absolutely trust. This approach will have the greatest effect if two computers are located in different buildings or even in different localities, that is, they are significantly separated in space.
• Try to make trusted contacts among people who are geographically far from you: for example, Brazil, South Africa, USA, Canada, Australia, etc. Be wary of making trusted members from Eastern European countries or repressive Asian regimes, unless, of course, they are your real friends.
• Beware of exchanging certificates with people who trust everyone.
• Upon reaching the required number of trusted participants - no more than 60...80 - enable either private or darknet mode in the client-server.
• Organize your distribution of folders and files carefully. Make sure that shared folders do not contain documents, pictures, etc., the tags of which may include your name or other information about you.
• Think before you act. In a decentralized system, nothing can be undone.

Просмотры: