Evidence collection organisation

Automated evidence collection

The automated evidence collection is carried out using the tool website evidence collector, WEC (also on Code Europa EU) in version 3.9.0 on the platform Linux in version 6.1.0-41-arm64. The tool employs the browser Chromium in version Chrome/131.0.6778.139 for browsing the website.

The evidence collection tool simulates a browsing session of the web service, capturing traffic between the browser and the Internet, along with any persistent data stored in the browser. While browsing, the tool gathers evidence and performs a number of checks.

It captures screenshots from the browser to identify potential cookie banners. It also tests HTTPS/SSL usage to determine whether the website enforces a secure connection. Then, the evidence collection tool scans the first web page for links to common social media and collaboration platforms, gathering data on the overall use of potentially privacy-intrusive third-party web services.

The recorded traffic between the browser, the target web service, and involved third-party web services, as well as the browser’s persistent storage, will be analysed in a subsequent section.

Generally, the tool browses a random subset of the target web service pages starting from the initial web page. However, the browsing can also include a set of predefined web pages. The exhaustive list of browsed web pages for this specific evidence collection is given in the Annex: Browsing history.

Web page visit

Use of HTTPS/SSL

HTTP (Hypertext Transfer Protocol) is a communication standard that transmits data between a website and a user’s browser in an unencrypted format, making it vulnerable to interception and eavesdropping. In contrast, HTTPS (Hypertext Transfer Protocol Secure) extends HTTP by adding an extra layer of security through encryption, which protects the confidentiality and integrity of the data exchanged between a website and a user’s browser.

The evidence collection tool assessed the behaviour of caritas-traunstein.de with respect to the use of HTTPS.

Use of content security policies (CSPs)

Upon a browser's request for a web page, websites can specify a whitelist of mechanisms, domains, and subdomains in the Content Security Policy (CSP) metadata sent along with the requested page. Browsers must respect this whitelist when embedding components such as styles, fonts, beacons, videos, and maps.

No CSP metadata related to first-party URLs was found.

No third-party content security policy hosts were whitelisted.

Use of social media and collaboration platforms

The website evidence collection tool found links from https://www.caritas-traunstein.de/de/email/success-page to the following common social media and collaboration platforms.

Traffic and persistent data analysis

First, the browser visited https://www.caritas-traunstein.de/de/email/success-page. The evidence collection navigated and collected evidence from no additional web service page(s).

The web page(s) were browsed consecutively between 16/01/2026, 11:27:18 and 16/01/2026, 11:28:22.

During the browsing, the HTTP Header Do Not Track was not set.

For the subsequent analysis, the following URLs (hosts with their paths) were defined as first-party:

1. caritas-traunstein.de/de/email/success-page

Traffic analysis

In the case of a visit to a very simple web page with a given URL (e.g. http://example.com/home.html), the browser sends a request to the web server configured for the domain specified in the URL (e.g. example.com). The web server, also called the host, then sends a response in the form of, e.g. an HTML file (e.g. the home.html file), which the browser downloads and displays. Most web pages nowadays are more complex and include content such as images, videos, and fonts, or embed elements like maps, tweets, and comments. To assemble and show the whole web page, the browser sends further requests to the same host (first-party) or even different hosts (potentially third-party) to download the required content. A web page is often composed of dozens of elements, and due to the complexity of website architecture, website administrators are often not fully aware of all third parties involved in the functioning of their websites.

The evidence collection tool extracted lists of distinct first- and third-party hosts from the browser requests recorded in each browsing session (with DNT signal set and without). These lists are presented below and aim to help by providing a comprehensive overview of all the hosts from which the browser requests elements. Note that subdomains (e.g. admin.example.com) of first-party domains (example.com) are, by default, considered third-party domains, whereas all URLs in the path (e.g. example.com/anysubpage) are treated as first-party by the automated evidence collection tool. More information about hosts and the distinction between first-party and third-party can be found in the glossary in the Annex: Glossary.

A number of techniques allow hosts to track browsing behaviour. A first-party host may instruct the browser to send requests solely for the purpose of providing information embedded in the request (e.g. cookies) to a given first-party or third-party host. These requests are often responded to with an empty file or a 1x1 pixel image. Such files requested for tracking purposes are commonly referred to as web beacons.

The evidence collection tool compares all requests against signature lists compiled to detect potential web beacons or annoyances such as in-page pop-ups. Positive matches with the lists EasyPrivacy (easyprivacy.txt) and Fanboy’s Annoyance (fanboy-annoyance.txt) from https://easylist.to are presented in the Annex: All potential web beacons. The list of web beacon hosts contains hosts of those requests that match the signature list EasyPrivacy. Note that the result may include false positives and may be incomplete due to inaccurate, outdated or incomplete signature lists.

Cookies are small text files stored on a user’s browser that allow websites to track and store information about the user’s interactions. However, they are limited in capacity and are transmitted with every HTTP request. Local storage objects, on the other hand, offer a more modern method for websites to store larger amounts of data locally on a user’s browser, with better control over data access and expiration. Both cookies and local storage objects can be used for tracking purposes.

Eventually, the evidence collection tool logged all identified web forms that potentially transmit web form data using an unencrypted connection.

First-party hosts

1. caritas-traunstein.de

Requests have been made to distinct first-party host(s).

Third-party hosts

1. www.caritas-traunstein.de
2. api.kiprotect.com
3. cdn.matomo.cloud
4. caritasnahamnaechsten.matomo.cloud

Requests have been made to distinct third-party host(s).

First-party potential web beacon hosts

No first-party potential web beacons were found.

Third-party potential web beacon hosts

1. cdn.matomo.cloud
2. caritasnahamnaechsten.matomo.cloud

No third-party potential web beacons were found.

Web forms with non-encrypted transmission

No web forms submitting data without SSL encryption were detected.

Persistent data analysis

The evidence collection tool analysed cookies after the browsing session. Web pages can also use the persistent HTML5 local storage. The subsequent section lists its content after the browsing.

Cookies linked to first-party hosts

No first-party cookies were found.

Cookies linked to third-party hosts

In total, 3 third-party cookie(s) were found.

Local storage

The local storage was found to be empty.

Annex

Browsing history

For the collection of evidence, the browser navigated consecutively to the following 1 web page(s):

1. https://www.caritas-traunstein.de/de/email/success-page

All potential web beacons

The data transmitted by beacons using HTTP GET parameters are decoded for improved readability and displayed beneath the beacon URL.

fanboy-annoyance.txt

easyprivacy.txt

"action_name": "Anfrage erfolgreich",
"idsite": 1,
"rec": 1,
"r": 865050,
"h": 11,
"m": 27,
"s": 53,
"url": "https://www.caritas-traunstein.de/de/email/success-page",
"_id": "3352b2131c471ae5",
"_idn": 1,
"send_image": 0,
"_refts": 0,
"pv_id": "rxEIWm",
"pf_net": 0,
"pf_srv": 94,
"pf_tfr": 2,
"uadata": {
  "formFactors": [],
  "fullVersionList": [],
  "mobile": false,
  "model": "",
  "platform": "Linux",
  "platformVersion": ""
},
"pdf": 1,
"qt": 0,
"realp": 0,
"wma": 0,
"fla": 0,
"java": 0,
"ag": 0,
"cookie": 1,
"res": "800x600"

"idsite": 1,
"trackerid": "QZO9D9",
"url": "https://www.caritas-traunstein.de/de/email/success-page"

Glossary

Do Not Track (DNT for short, HTTP)

The Do Not Track header is the proposed HTTP header field DNT, which requests that a web service does not track its individual visitors. Note that this request cannot be enforced by technical means on the visitors’ side. It is upon the web service to take the DNT header field into account.

Filter Lists

Browser extensions commonly referred to as Adblockers have been developed to block the loading of advertisements based on filter lists. Over time, these filter lists have been extended to also block the loading of web page elements associated with tracking web page visitors. For this evidence collection, publicly available tracking filter lists are used to identify web page elements that may track the web page visitors.

First-Party

In this document, first-party is a classification for resource links, web beacons, and cookies. To be considered first party, the resource’s domain must match the domain of the inspected web service or other configured first-party domains. Note that the resource path must also be within the path of the web service to be classified as first-party.

Host (HTTP)

The HTTP host is the computer that receives and responds to browser requests for web pages.

Local Storage (HTML5)

Most web browsers allow web pages to store data locally in the browser profile. This local storage is specific to the website and persists through browser shutdowns. As embedded third-party resources may also have access to first-party local storage, it is classified both as first- and third-party.

Redirect (HTTP)

A request for a web page may be answered with a new location (URL) to be requested instead. These HTTP redirects can be used to enforce the use of HTTPS. When visitors request an HTTP web page, they are redirected to the corresponding HTTPS web page.

Request (HTTP)

To download and display a web page identified by a URL, browsers send HTTP requests with the URL to the host computer specified as part of the URL.

Third-Party

Links, web beacons and cookies that are not first-party (see above) are classified as third-party.

Web Beacon

A web beacon is one of various techniques used on web pages to unobtrusively (usually invisibly) track web page visitors. A web beacon can be implemented as a 1x1 pixel image, a transparent image, or an empty file requested alongside other resources when a web page is loaded.

Web Beacon Host

The host in the URL of a request of a web beacon is referred to as the web beacon host.