What are communication logs?
Internet communication does not necessarily disappear completely on the spot.
Records about communication may remain on websites, servers, DNS, ISPs, routers, firewalls, and similar systems.
These records of communication are generally called "communication logs."
Communication logs may include not only the content of a communication, but also surrounding information such as communication time, source IP address, destination, accessed URL, browser information, cookies, and DNS queries.
When thinking about anonymity, it is not enough to ask only whether the content is encrypted.
That is because even when the content cannot be read, metadata associated with the communication can become a clue for tracking.
Where communication logs remain
Communication logs are records about communication.
For example, when you access a website, the web server may record "when," "from which IP address," "to which URL," and "with what kind of browser information" the access occurred.
However, communication logs do not remain in the same way in every environment. Which information is recorded changes depending on server settings, application design, cloud services used, network configuration, and log retention policy.
The important point is that internet communication has multiple observation points. Different kinds of logs may remain in different places, such as the website, DNS, ISPs, routers, internal networks, and cloud infrastructure.
| Where logs may remain | Information that may be recorded | Main purpose |
|---|---|---|
| Web server | Access time, IP address, URL, User-Agent, referrer, and similar information | Access analysis, incident response, attack detection |
| Application | Login history, operation history, error details, account ID, and similar information | Abuse prevention, service operation |
| DNS resolver | Queried domain name, query time, requester information, and similar information | Name resolution, network management |
| ISP or network operator | Connection time, assigned IP address, traffic volume, some destination information, and similar information | Network operation, connection management |
| Router and firewall | Destination, traffic volume, blocked communication, internal device information, and similar information | Network management, security measures |
Why logs remain
Logs do not exist only to monitor users. In many cases, logs are recorded to operate services and networks stably.
When an error occurs on a website, administrators check logs to investigate which URL, at what time, and what kind of error occurred.
Logs also become important evidence for investigation when suspicious events occur, such as unauthorized login, heavy access, vulnerability scans, malware infection, or suspected information leakage.
| Purpose | How logs are used | Example |
|---|---|---|
| Incident response | Investigate causes of errors or outages | Check whether 500 errors are increasing on a specific URL |
| Security measures | Detect suspicious access | Check whether many login attempts occurred in a short time |
| Abuse prevention | Investigate clues to terms violations or attacks | Check abnormal requests or unnatural access sources |
| Service improvement | Understand usage | Check frequently viewed pages and high-access time slots |
Logs are a basic mechanism for protecting services. At the same time, because logs may contain information about user behavior, they can also become a privacy risk depending on how they are managed.
Logs that remain on websites
When you access a website, access logs may remain on the web server.
Typical access logs include source IP address, access time, HTTP method, URL, status code, User-Agent, referrer, and similar information.
An example URL is as follows.
URL example : https[:]//example.com/article/network-log
Here, example.com is an example domain often used for explanation.
On the website, even when communication uses HTTPS, the site receives the accessed URL path and query, cookies, and sent request information. HTTPS is a mechanism that makes content harder to read on the communication path; it does not prevent the destination website itself from receiving request information.
However, information received by the web server and information actually stored as logs are not the same. s, request bodies, and similar data may or may not be recorded depending on server and application settings.
| Information | Content | Caution |
|---|---|---|
| Access time | When access occurred | May become a clue matched with other logs by time |
| Source IP address | Which IP address connected | Through a CDN or proxy, the direct source may be an intermediary server |
| URL | Which page or API was accessed | Query strings may include identifiers |
| User-Agent | Browser, OS, app type, and similar information | May become material for inferring the usage environment |
| Cookie | Identifying information the site stores in the browser and receives from it | May be used to identify return visits from the same browser or login state |
| Referrer | Which page the user moved from | May not be sent, or only part may be sent, due to Referrer-Policy and similar mechanisms |
| Status code | Request result | Processing result is visible from 200, 301, 403, 404, 500, and similar codes |
When a website uses a CDN, load balancer, or reverse proxy, the source IP address visible to the web server may be the IP address of the intermediary server rather than the actual user. In this case, the original client IP address may be recorded in headers such as X-Forwarded-For or in CDN-side logs.
Logs that remain in applications and authentication systems
Server-side logs are not limited to web server access logs.
Records about user operations and system behavior may also remain in login functions, payment functions, admin screens, APIs, databases, error monitoring tools, and similar systems.
For example, a service with a login function may record information such as the following.
- Successful login
- Failed login
- Password change
- Two-factor authentication attempt
- Session issuance
- Account settings change
- Access to an admin screen
Services that provide APIs may record which API endpoint received a request, from which account or IP address, and at what time.
These logs are used to detect unauthorized login, account takeover, permission abuse, abnormal API use, and similar problems.
Records that may remain with ISPs and network operators
When connecting to the internet, user communication usually passes through the network of an ISP or access provider.
On the provider side, records about connections may remain, such as when a contracted line was connected, which IP address was assigned, and how much traffic occurred.
On home lines and mobile lines, the IP address assigned to a user may not be fixed and may change over time. Therefore, information about "which contracted line was using this IP address at this time" relates to records on the provider side.
Also, on mobile lines and some other lines, a system may be used where many users share one global IP address. In this case, not only the IP address but also information such as time and port number may relate to identifying the connection.
However, the existence of provider records and anyone being able to freely view that information are separate matters. ISP and network-operator logs are usually not something ordinary users can freely inspect.
Records related to DNS
When accessing a website, the browser or OS needs to convert the domain name into an IP address. This mechanism is called DNS.
For example, when accessing the following URL, the device looks up the IP address corresponding to example.com.
URL example : https[:]//example.com
DNS query records may retain which terminal or network made a query for which domain name.
DNS logs do not record the body text of a web page itself. However, they may show information about "which domain someone tried to access."
One caution is that where DNS queries are recorded changes depending on the environment. If you use your ISP's DNS, the query may reach the provider's DNS resolver. On the other hand, if the browser or OS uses another DNS resolver or encrypted DNS, the query destination changes.
In other words, when thinking about DNS logs, you need to look at "which DNS resolver was queried."
Router and firewall logs
Communication logs do not remain only with websites and ISPs.
Records about communication may also remain on home routers, company or school network equipment, cloud firewalls, proxy servers, gateways, and similar systems.
In organizational networks, records may be kept showing which device connected to which external server and when. These are used to investigate malware infection, unauthorized access, information leakage, insider abuse, and similar issues.
On the server side as well, multiple logs may exist, such as OS authentication logs, firewall logs, SSH logs, application logs, and cloud audit logs.
For example, the following kinds of logs are important in server administration.
| Log type | Content that may be recorded | How it is used |
|---|---|---|
| Authentication log | Successful login, failed login, source IP address, and similar information | Checking unauthorized login and brute-force attacks |
| Firewall log | Allowed and blocked communication, port number, destination, and similar information | Detecting suspicious communication and attacks |
| Proxy log | Access from internal devices to external sites | Internal communication management and investigation |
| Cloud audit log | Administrative operation, API execution, permission change, and similar information | Tracking setting changes and permission abuse |
| Application log | Errors, operation history, processing results, and similar information | Incident response and abuse investigation |
In this way, communication logs are not only "records of accessing a website"; they exist across networks and systems as a whole.
Relationship between HTTPS and logs
HTTPS is an important mechanism for encrypting content in transit and confirming that the communication partner is the intended party.
However, using HTTPS does not mean that no one can know any communication information.
The main target protected by HTTPS is content that could otherwise be visible to third parties on the communication path. For example, form input, page body, many HTTP headers, URL paths and queries, and similar content normally become harder to read on the communication path.
On the other hand, the destination web server decrypts the communication and processes the request. Therefore, the website receives the accessed URL, cookies, User-Agent, login information, submitted form content, and similar information.
Also, even on the communication path, connection time, source IP address, destination IP address, traffic volume, and some information about the TLS connection may be observable.
In other words, HTTPS is very important, but it is not a mechanism that erases all log issues.
| Observer | Information that may be visible | Information harder to see |
|---|---|---|
| Website side | URL, cookies, User-Agent, submitted content, login operations, and similar information | Content you do not want third parties on the communication path to see |
| Third party on the communication path | Source IP, destination IP, communication time, traffic volume, and similar information | Page body, form content, URL path and query, and similar information |
| DNS resolver | Queried domain name, query time, and similar information | Web page body and specific operation details |
| Router and firewall | Destination, traffic volume, allow/block result, and similar information | Body text inside HTTPS and many HTTP headers |
Logs are not necessarily bad
Communication logs are information that needs attention from the perspective of anonymity and privacy. However, logs themselves are not bad.
Without logs, it becomes difficult to investigate server outage causes, detect unauthorized access, respond to account takeover, investigate malware infection, and operate services stably.
What matters is why logs are stored, what scope is recorded, how long they are stored, and who can access them.
The existence of logs and anyone being able to view them freely are separate matters. Properly managed logs are important information for protecting services, but excessively stored logs or poorly managed logs become privacy risks.
Logs become clues for anonymity
When thinking about anonymity, it is insufficient to look only at whether the content is encrypted.
Even when content cannot be read, information such as communication time, source IP address, destination, DNS queries, cookies, User-Agent, and referrer may be recorded in other forms.
These pieces of information may not directly identify an individual by themselves. However, when multiple records are combined, they may become material for inferring whether records appear to come from the same user, the access route, the behavioral timeline, the source network, and similar information.
| Information | What may be learned | Anonymity caution |
|---|---|---|
| Access time | When communication occurred | May be matched with other records by time |
| IP address | Which network connected | May become material for inferring line, region, organization, and similar context |
| DNS query | Which domain someone tried to access | Becomes a clue to the destination even if the page body is not known |
| Cookie | Whether access came from the same browser | May be used to identify return visits or login state |
| User-Agent | Browser or OS type | May be treated as a feature of the usage environment |
| Referrer | Which page the user came from | Part of the movement route may be known |
| URL query | May include search terms, identifiers, session information, and similar data | If it remains in server-side logs, it becomes a clue to behavior content |
For anonymity, "the content is not read" and "communication traces do not remain" are not the same.
Even when content is encrypted, surrounding information about the communication may remain. For that reason, thinking about anonymity requires organizing not only encryption, but also where and what kinds of logs may remain.
Summary
Communication logs are records about communication.
Various kinds of information about communication may remain on websites, applications, DNS, ISPs, routers, firewalls, cloud infrastructure, and similar systems.
Representative information includes access time, source IP address, URL, User-Agent, cookie, referrer, DNS query, destination, traffic volume, authentication history, and operation history.
Logs are used for incident response, security measures, abuse investigation, service improvement, and similar purposes. Therefore, logs themselves are an important mechanism for operating internet services safely.
At the same time, from the perspective of anonymity, logs may become clues for tracking. That is because even when content is encrypted, source, destination, time, DNS queries, cookies, User-Agent, and similar information may be recorded in other forms.
Understanding the basics of communication logs makes it easier to organize what may be recorded on the internet. And when thinking about anonymity, it becomes possible to consider not only whether content is visible, but also where surrounding information about the communication may remain.