View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009212 | GNUnet | messenger service | public | 2024-09-23 15:34 | 2024-09-24 17:55 |
| Reporter | thejackimonster | Assigned To | thejackimonster | ||
| Priority | normal | Severity | minor | Reproducibility | sometimes |
| Status | assigned | Resolution | open | ||
| Product Version | Git master | ||||
| Target Version | 1.0.0 | ||||
| Summary | 0009212: messenger service might log identifiable information | ||||
| Description | I would open this as follow-up issue of: https://bugs.gnunet.org/view.php?id=9179 It was mentioned that logging might contain identifiable fields which could be masked to improve user privacy. So potentially it should be verified which data is necessary on each log level to have since most logging on service level has been done for debugging purposes and the checking for bugs. Potentially it might be ideal in the end to avoid all logging during production since even timestamps could be used to trace an identity or communication between devices. | ||||
| Steps To Reproduce | Any logging during active usage of the Messenger service. | ||||
| Tags | No tags attached. | ||||
|
|
Thank you thejackimonster. My concern was the unique ID's that are captured in the logs may be used to identify or contact a node. I understand GNUnet is complex, so forgive me if it was a naive request. What do the various ID's that are displayed in the log files mean? Is there some documentation that details this? |
|
|
There's probably a lack of documentation right now. You either have peer identities which only indicate which peers make a connection to potentially exchange messages or you have member IDs. But the member IDs are essentially used to reduce access in hash maps. Because technically member IDs are not unique by design but practice. That means those IDs could still collide by accident or intent (in case of an attack) which causes a fallback to identify a member by its used public key (to sign messages). Following of such a conflict the members with a duplicate member ID each generate a new random unique ID and switch to them. Also member IDs are completely individual to each chat room. They won't identify anyone across them. Your public key might do that but it should not get logged. You could also use different keys for different chats if you want to avoid getting tracked across chats. Additionally you can use a key which is publicly known to all peers that doesn't identify anyone because everyone has access to it (therefore everyone could potentially use it). I think before latest patches, member IDs were most likely get logged for debugging purposes. That's reduced now. But it's not like these could be trusted to identify an individual user. I would even imagine that it's more likely an attacker would match timestamps to track a user and their communication. So any logging in production might be an issue, I assume. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-09-23 15:34 | thejackimonster | New Issue | |
| 2024-09-23 15:34 | thejackimonster | Status | new => assigned |
| 2024-09-23 15:34 | thejackimonster | Assigned To | => thejackimonster |
| 2024-09-24 11:00 | Eric E | Note Added: 0023362 | |
| 2024-09-24 17:55 | thejackimonster | Note Added: 0023368 |
