Closed lammel-hub closed 6 months ago
Thank you so much for your kind and concise answers.
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!
Understood. Thank you.
Understood. Great!
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?
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
Thank you!
@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)
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?
Yes, of course! There is absolutely no rush :)
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.
Have a second follow-up on #67 🙏
Great work on Butter Beard II! I am currently catching up on all the GitHub messages.
Regarding #93 (this issue):
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)
thanks for reviewing the code. I will formulate an update privacy statement based on your answers.
I close this issue and open a new, based on this discussion
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.
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).