The programmers/developers from Tripmode (and tools like that) should completely redesign how their tools are working so they check what really is causing the data traffic.
The real underlying issue is the order in which filters are stacked in the kernel, including the Avast packet forwarder.
If Avast is the first in line and forwards the packets from there, others won't see them as they are sent from the original app. Once proxied by the web filter, packets go back into the kernel as sent from the Avast proxy where they appear as sent from its process. Not sure of how we can find out what the original app was.
If TripMode is the first in line, packets are seen twice. Once from the original app before they get forwarded then a second time as they come back into the kernel from the Avast proxy. Traffic get attributed to both the app and Avast, but at least the apps can be blocked individually.
Stacking order seems to not be alterable through the network kernel extensions themselves. Only workaround we found on initial testing is that the last loaded extension seems to get placed as the first filter in line.
Suggestions are very welcome on how to fix this issue and make TripMode play well with Avast.
The single webkit process issue is fixed for the most part in an upcoming TripMode release, but Apple unfortunately does not provide a public API to retrieve which XPC helpers match a given app so it is done heuristically.