request jobs generation
All checks were successful
continuous-integration/drone/push Build is passing
All checks were successful
continuous-integration/drone/push Build is passing
This commit is contained in:
@ -46,7 +46,13 @@ Some of them might be marked as trusted.
|
||||
Random delays and random payload padding might be set for each forwarding step, making the overall message tracking much more difficult, even for organizations having capabilities of global network surveillance.
|
||||
It is strongly advised to use trusted servers as your first node and message server (the one that holds your incoming messages).
|
||||
|
||||
\subsubsection{Presence protocol for direct messaging}
|
||||
\subsubsection{Message lookup obfuscation}
|
||||
Your device will request for messages using conversation keys on a very regular basis to youy messaging(s) server(s).
|
||||
The device will check for conversation keys for all your contacts. If you check that option, it will also check for hidden contact keys.
|
||||
In case of data interception on your device link, in order to prevent statistical analysis, every request might be answered with random data.
|
||||
Moreover, some random keys will be added to your requests list.
|
||||
|
||||
\subsubsection{Presence protocol for direct messaging TBC}
|
||||
A presence service associating your conversation keys to your IP address for direct peer to peer connection is also provided.
|
||||
The presence protocol is simply activated by setting a flag in the message poll requests.
|
||||
If that flag is set, your encrypted IP will be published on the server, allowing your only your peer(s) to decrypt it and directly communicate with your terminal.
|
||||
|
Reference in New Issue
Block a user