Your computer may be communicating with remote systems even when you are doing nothing that requires the internet.
The applications may be legitimate. The connections may be legitimate. The remote organizations may be legitimate.
But who decided that the communication should happen now?
This question is at the center of my paper, Who Decides When an Application Needs the Internet?. It concerns network visibility, user intent, and the distinction between understanding a connection and deciding whether it is wanted.
1. Purpose is not permission
Modern applications communicate for many reasons: authentication, software updates, synchronization, licensing, telemetry, cloud functionality, and content delivery.
These may all be legitimate technical purposes.
But consider a different question: What is the user trying to do right now?
If I am editing a local document, performing a calculation, or designing a figure, I may not expect external communication to be necessary for that task.
Using an application does not necessarily mean I have consciously decided that every network interaction it initiates should occur at every moment.
A technical purpose explains why an application may communicate. It does not necessarily establish whether the user wants that communication now.
2. Seeing a connection does not reveal its meaning
Suppose a tool shows which applications on a Windows computer are communicating with remote systems.
We may be able to observe:
- The application or process associated with a connection.
- The remote IP address.
- Information about the remote network or organization.
- Changes in the observed network state.
That is useful information, but it has limits.
An observed connection does not necessarily tell us what information was exchanged, why it was exchanged, or what conclusions could eventually be drawn from it. Encrypted protocols such as TLS also limit what can be inferred from network observation alone.
Three distinctions are important:
Unexpected does not mean harmful.
Legitimate does not mean wanted.
Unknown does not mean dangerous.
A network connection is evidence of communication, not proof of malicious behavior.
At the same time, the absence of an obvious attack does not mean that communication has no privacy implications. Many ordinary observations, accumulated over time, may reveal patterns of activity that no single connection explains.
Visibility is evidence. It is not certainty.
3. A snapshot is not a history
Network activity changes continuously.
An application may open a connection, close it, and later connect to another remote system. Looking at the current state tells us what is observable at that moment, but not necessarily what happened while we were not looking.
This distinction matters when designing network-monitoring tools.
In WhoIsConnected, the Logger compares successive observations and records connections discovered as new, closed, or present in the initial state.
It provides a history of observed changes, not continuous packet capture.
A connection that begins and ends entirely between observations may never appear in that history.
This is an important limitation to communicate clearly to users:
Current state is not history. Observed history is not continuous capture.
4. Why application-level control matters
One application may communicate with several external systems for different purposes.
Instead of evaluating every remote connection in isolation, we can ask a broader question:
Do I want this application communicating externally while I perform this task?
This changes the focus from individual network endpoints to the application the user recognizes.
WhoIsConnected uses this application-oriented approach. Users can examine observed external connections and apply reversible network restrictions using underlying Windows Firewall mechanisms.
The practical process is:
Observe → Decide → Act → Observe again
After applying a restriction, the user can observe what changes.
A function may stop working. Another may continue normally. Either outcome provides information about the relationship between the application and its external communication.
The goal is not to label every connection as good or bad. It is to help the user make a decision with the information available.
5. Control under incomplete information
We rarely have complete information about every application connection.
But users often know something that network-monitoring software cannot determine on its own:
They know what they are trying to accomplish.
That knowledge supports several possible choices:
- Allow: I want this communication.
- Observe: I want to understand it better.
- Stop: I want to stop the application.
- Remove: I no longer want the application installed.
- Restrict: I want to continue using the application while limiting its external communication.
These are not equivalent actions, and they may have different consequences.
The useful principle is that control can become part of the investigation.
A reversible restriction lets the user observe the result, reconsider the decision, and restore access when needed.
6. AI can assist, but it cannot supply user intent
AI-assisted analysis can help interpret application, process, and remote-network information.
It may summarize observable properties, identify patterns, and suggest possible actions.
But an analytical system does not automatically know why the user opened an application, whether an online feature is expected, or whether synchronization is wanted at that moment.
That distinction is central to human-centered control:
AI contributes analysis. The user contributes intent.
An analytical recommendation should support the user's investigation, not replace the user's decision.
7. A practical five-step method
The paper proposes a simple method for investigating application network activity:
- EXPECT: What am I trying to do, and what external communication do I expect?
- OBSERVE: Which applications are communicating, and where?
- INVESTIGATE: What can I learn about the application, process, and remote network?
- DECIDE: Does this communication fit what I want to do?
- OBSERVE AGAIN: What changes after my decision?
The final step matters because the result becomes new information.
The method is a cycle rather than a one-time judgment:
EXPECT → OBSERVE → INVESTIGATE → DECIDE → OBSERVE AGAIN
8. What this means for developers
This raises questions not only for users, but also for software developers.
When our applications communicate externally, how clearly do we explain that behavior?
Can users distinguish between network access required for a feature and communication that is optional?
Can they understand what may stop working if access is restricted?
And can we design applications that respect the difference between a legitimate technical requirement and the user's immediate intention?
These are questions about software architecture, usability, privacy, and trust—not merely about detecting suspicious traffic.
Conclusion: When should the door be open?
A house can have doors without keeping every door open all the time.
Software can have legitimate reasons to communicate without requiring every connection to be unquestioned.
The purpose is not to disconnect permanently. It is to make communication visible, understandable where possible, and subject to informed decisions.
What am I trying to do right now, and which network connections do I need to do it?
That is the question I believe should remain with the user.
About the project and paper
I am the developer of WhoIsConnected, a Windows application developed by MOBILOTECH to help users explore application-level network activity. It provides connection visibility, supplementary application and network information, repeated observation, analytical assistance, and reversible network-control capabilities.
This article is adapted from my September 2026 paper:
Taskin Sakarya — Who Decides When an Application Needs the Internet? Network Visibility, User Intent, and Informed Control.
Read the complete paper on Zenodo
A question for the DEV community
Should applications explain more clearly which network connections are essential, which are optional, and what happens when users restrict them?
I'm interested in how other developers approach this question in their own software.
Top comments (0)