question: rendez-vous server

[lammel-hub]

Is your feature request related to a problem? Please describe. I am currently trying to understand any potential privacy issues. The most obvious risks are connected with the use of Tokens.

The reason is that the IP address and port number is shared via a "rendez-vous server" (RVS) in the diagram "Connection establishment" of Dayon! Support

Trying to understand online documentation does not help, as it is too technical for me, but I have the following questions that you might be able to answer.

1. Who runs the RVS? Is it Dayon!, a third party, or is it an "anonymous P2P network" you rely on? (pardon my poor tech speak)
2. The Token is somehow mapped to the Assistant (IP address+port only). Is this "within" the RVS, or where is that mapping made?
3. The diagram seems to indicate that the comms to and from the RVS is encrypted. If so, how/type of encryption?
4. How long is a Token valid/kept at RVS?
5. What happens after a Token is considered invalid? Is it forgotten and never to be reused, or could it be recycled?

Additional context Based on your answers I may be able to make a privacy assessment according to the European rules (GDPR) and suggest an updated privacy statement for Dayon (if deeemed necessary).

[RetGal]

1. Well, currently I'm running the RVS hosted in Switzerland and payed by me. In version 13.0.1 I added support for self hosted RVS, thus now everyone could run own instances of RVS. But the assistant and the assisted require an additional configuration file in order to use them: https://github.com/RetGal/Dayon/issues/67#issuecomment-1880044195
2. The RVS consists of a simple PHP script with an SQLite DB, which holds just one table. There the generated token, the time the token was generated, the I address and the port of the assistant is stored. As soon as the assisted connects with the RVS, it's IP address is also stored in this table.
3. All the connections to the RVS are made via https.
4. The token have a configured lifetime of 7 days, after that they are automatically deleted from the DB. This is also the reason the tokens can be that short.
5. After a token has been deleted, there is a good chance, that an identical new token will be generated after some time. This causes though no issue. The very worst that could happen would be this scenario: An assisted enters an old token, which has been deleted and regenerated since. So the assisted will then connect to the RVS and receive the IP address and the port of the assistant who generated the new token. If the assistants Dayon! is accidentally waiting for incoming connections at exactly that moment and also accepts the connection, then the assisted will be connected to the wrong assistant. But that's a pretty unlikely scenario, as usually the assisted will contact the assistant by phone or some other means, before he tries to connect to him - as the assistant needs to be at his computer awaiting his connection..

[lammel-hub]

Thank you so much for your kind and concise answers.

1. Use of Token means use of RVS: (a) Your separately run RVS would be considered a data processing by a 3rd party in a country that fulfils the European Privacy Regulations. Great! To understand this specific case better I would need know: is the hosted RVS (script + DB) running in an environment that has physical and logical security measures that meet an assessed threat level? (No need to specify sensitive details here; A simple yes is OK - or a longer maybe/no with some thoughts.) (b) Privacy-by-Design would be to connect without a 3rd party RVS. Self-hosted solution is a viable option. Great! (c) Privacy-by-Design would be to connect without using a Token at all. This is a viable option. Great!

2. Understood. Thank you.

3. Understood. Great!

4. 7 days lifetime of Token: (a) As I understand the protocol, IP of both parties are kept in the DB. Are both tied to the same 7 days lifetime (deleted simultaneously with the Token) or are they running "individual 7 days lifetimes"? (b) Is there a definitive use case for 7 days, or could other time limits be considered?

5. After reading up on the RVS I believe there might be several risks to consider: (a) Your case - "accidental reuse" (b) "Spam" - where a malicious attacker could fill the DB with identities that assisted accidentally connects to (c) Attacker could perhaps "discover peers" and thereby look for assisted and assistants in DB to try attacks on them? Note: This is beyond my technical understanding.

The identified risks above need not be resolved - only identified - to be able to make a privacy risk assessment

Note Outside the scope of this analysis, the RVS should be configured to withstand simple DOS attacks

[RetGal]

Thank you!

1. (a) Yes, they are hosted on a server at Switzerland's leading hosting company
2. (a) The whole entry is being deleted
3. (b) It's configurable. I didn't think too much about the TTL. The main focus was on generating rather short tokens. With the current user base and TTL of the token, the token are never got longer than 4 chars (including one check digit -
   thus 33^3 possible unique tokens). The length of the token automatically increases when a collision is detected during the generation.
4. (b) I mitigated this by adding a configurable limit of tokens per assistant address. (thanks for the link!) But as already stated earlier, the typical assisted wont blindly connect to a random assistant, as he/she/it will contact him/her/it before that using mail/phone/etc. (c) You could discover IP addresses and port numbers of assistants by querying the RVS with random tokens. Nothing more.

[RetGal]

@lammel-hub off topic, but I plan to create a new release including all those great improvements.

Would it be possible that you have a brief look @ https://github.com/RetGal/Dayon/blame/master/src/main/resources/Babylon_sv.properties ? (especially at those added within the last 5 days)

[lammel-hub]

Thanks! I will absolutely check it out, but I will be travelling from tomorrow early morning, and won't be back until Tue. So will look at it from mobile, hope that is ok?

[RetGal]

Yes, of course! There is absolutely no rush :)

[lammel-hub]

couldn't help myself, have just adjusted, so sv_SE is now ready for your approval. I have never made a "fork" or "pull request" before, but I guess you will find it - if not, ls let me know.

On another note: Did you see my question on issue #67 ?

PS. Will look at the risk assessment next week again.

[lammel-hub]

Have a second follow-up on #67 🙏

[lammel-hub]

Great work on Butter Beard II! I am currently catching up on all the GitHub messages.

Regarding #93 (this issue):

• Do all Tokens on the same RVS get the same life span (currently 7 days) or could this be configured separately per Token?
• Based on your previous answers and the answer to this "last" question I believe I can make a proper proposal for this matter

[RetGal]

Yes, there is just one configurable "token lifetime" which is valid for all tokens generated by a specific RVS.

Important rectification concerning the token lifetime: After reviewing my own code, I realized that every time an assisted contacts the RVS with a token, the lifetime of this token is extended.

The original idea behind this "extended" lifetime was, that the assistant can reuse previously generated tokens, instead of generating new ones for each session. (which doesn't hurt the assisted from a past session, as the token just resolves to the assistants IP address and port number)

[lammel-hub]

thanks for reviewing the code. I will formulate an update privacy statement based on your answers.

[lammel-hub]

I close this issue and open a new, based on this discussion