From CodeRabbit review of #537 (comment on `application.yml` device-classification lists).
`DeviceClassifierService.addToProfile` adds each conversation's nDPI app to BOTH endpoints' profiles, so endpoint-agnostic protocol names in `server-apps` / `iot-apps` (e.g. `DNS`, `SSH`, `SMB`, `MDNS`) also credit the client side of the flow: a workstation that queries DNS collects a `Server app "DNS"` vote, an mDNS-chatty laptop collects IoT votes.
Proposed direction: gate server/IoT app signals on serving direction — e.g. only score `server-apps` for a host when the app was observed on a conversation where that host was the responder (or the host carries a matching detected service role), rather than on plain profile membership. Client-leaning lists (mobile/desktop apps) are fine as-is.
This is classification tuning with quality implications either way, so it deserves its own change with before/after checks on the sample captures rather than a drive-by edit.
🤖 Generated with Claude Code
From CodeRabbit review of #537 (comment on `application.yml` device-classification lists).
`DeviceClassifierService.addToProfile` adds each conversation's nDPI app to BOTH endpoints' profiles, so endpoint-agnostic protocol names in `server-apps` / `iot-apps` (e.g. `DNS`, `SSH`, `SMB`, `MDNS`) also credit the client side of the flow: a workstation that queries DNS collects a `Server app "DNS"` vote, an mDNS-chatty laptop collects IoT votes.
Proposed direction: gate server/IoT app signals on serving direction — e.g. only score `server-apps` for a host when the app was observed on a conversation where that host was the responder (or the host carries a matching detected service role), rather than on plain profile membership. Client-leaning lists (mobile/desktop apps) are fine as-is.
This is classification tuning with quality implications either way, so it deserves its own change with before/after checks on the sample captures rather than a drive-by edit.
🤖 Generated with Claude Code