After playing with Traffic types. It seems its just associating ports it finds in the traffic with most popular protocols and not actually doing any deep packet inspection. This will lead to false traffic types since for instance Kerberos uses a large amount of ports that are also associated with WireGuard.
The traffic type currently doesn’t reveal the service/app causing the traffic. Possibly because there could be multiple services at the same time generating the same type of traffic.
In this case, ports used by the service/app should be collected and grouped and shown also with the destination ip. Possible traffic types from these port usages would be helpful. But just listing possible traffic types in a most used list doesn’t help anything. for instance http/ssl is used by almost every service. But if traffic type appears when clicking on a particular destination ip. that would be extremely helpful. since now we know the ports and a hint of what it was trying to do.
Thanks for your feedback on making GlassWire break all secure communications on your PC so it can be analyzed in more detail.
Very strange and cryptic reply. How does listing Port numbers instead of just grouping possible protocols break secure communications? And what secure communications are you referring to? Sounds like you intend this as a double entendre.
Sorry, I thought you were saying we should add deep packet inspection to GlassWire. I apologize if I misunderstood.
To do proper traffic type you would have to do some form of analysis more than just looking up common port numbers associated with those protocols. And GW is bunching up the traffic types for any given timeline range. Since ports can be used by multiple different protocols. The list isn’t exactly useful for forensic use.
You only need to do two minor things to fix this. Simply show the port numbers used by any given service/app in the same dialog box where you show hosts. “then” limit the list to just traffic types used by those ports on that clicked service/app.
Currently port numbers are not even available to be reviewed. And some ports are not even associated with common protocols your tossing those into the “other” traffic type. There are plenty of redflag ports that would immediately tip off a user that something is afoot.
Spyware and virus’s #1 game is to run during idle when nobody is looking. You have solved that. Except when it comes time to determine the actual culprit should it get through via the kernel and not list a service/app or hide within the svchost with zero or negative pid’s Most smart spyware purposely uses uncommon ports.Showing the ports will be hugely helpful.