Privacy policy

Which cookies are used by this website?

This website does not use any cookie.

As for every other website, the web servers that serve this website will receive some information about the client that made the request. This is require for the proper communication between the client (your machine) and the server and is therefore not avoidable. Some of those information are also logged for metrics and security reasons.

More specifically, the following data about every loaded object is logged:

  • date: The date on which the event occurred in the format yyyy-mm-dd (in UTC).
  • time: The time when the server finished responding to the request (in UTC).
  • x-edge-location: The edge location that served the request.
  • sc-bytes: The total number of bytes that the server served to the viewer in response to the request, including headers.
  • c-ip: The IP address of the viewer that made the request.
  • cs-method: The HTTP access method: DELETE, GET, HEAD, OPTIONS, PATCH, POST, or PUT.
  • cs-uri-stem: The portion of the URI that identifies the path and object, for example, /images/daily-ad.jpg.
  • sc-status: An HTTP status code. For a list of HTTP status codes, see RFC 2616, Hypertext Transfer Protocol—HTTP 1.1, section 10, Status Code Definitions.
  • cs(Referer): The name of the domain that originated the request.
  • cs(User-Agent): The value of the User-Agent header in the request.
  • cs-uri-query: The query string portion of the URI, if any.
  • x-edge-request-id: An encrypted string that uniquely identifies a request. In the response header, this is x-amz-cf-id.
  • x-host-header: The domain name requested by the viewer.
  • cs-protocol: The protocol that the viewer specified in the request.
  • cs-bytes: The number of bytes of data that the viewer included in the request (client to server bytes), including headers.
  • time-taken: The number of seconds (to the thousandth of a second) between the time that an edge server receives a viewer’s request and the time that the edge server writes the last byte of the response to its output queue as measured on the server.
  • x-forwarded-for: If the viewer used an HTTP proxy or a load balancer to send the request, the value of c-ip is the IP address of the proxy or load balancer. In that case, x-forwarded-for is the IP address of the viewer that originated the request.
  • ssl-protocol: The SSL protocol that the client and the server negotiated for transmitting the request and response.
  • ssl-cipher: The SSL cipher that the client and the server negotiated for encrypting the request and response.
  • cs-protocol-version: The HTTP version that the viewer specified in the request.

Is it possible to connect the log data to real people?

This is a point open for debate. The two information that are present in the logs which might help identify the user behind a request are:

  • the time and date of the request
  • the IP address of the request

In the logs the User Agent also appears, but since it’s a string set by the requester, it can be faked so it would be pointless to use it to identify a requester.

In some jurisdictions, it is possible - given the IP address and the date/time - to identify the ISP contract that was using that IP at that moment, and therefore identify the physical person that signed the contract. In some jurisdictions, this is enough to consider the user identifiable, in many other this is not, since many ISP contracts are shared among multiple people (ie: the members of a single family), not counting possible unauthorized accesses.

The requester IP address is a required information that the server needs to have to correctly reply to the client, so it is not avoidable that the server (and potentially others in between) have the information.

The usage of proxies, VPNs, Tor, or similar systems might allow a client to navigate without leaking its IP address to the server or other third parties.