Privacy policy

1. Website visits

Sessions and language

The application starts a PHP session when the requested feature needs one; public GET and HEAD pages do not necessarily start a session for visitors without an existing session cookie. A session is used for login state, language and CSRF protection. The session cookie uses HttpOnly and SameSite=Lax; Secure is set over HTTPS. When a language preference is saved, the application also uses the “admin_tools_language” cookie for up to one year. The application code does not set analytics, advertising or tracking cookies.

Visit log

For an existing web path, the application may store one visit record per IP address and calendar day. Static Windows and Linux example results, the account deletion page and configured excluded IP addresses are exempt. The record contains the IP address, local-address flag, account ID if signed in, the requested path, the referrer path and the user agent. Query parameters and referrer host names are not retained. The log supports technical monitoring, security, troubleshooting and page statistics. This policy states Article 6(1)(f) GDPR as its legal basis.

New visit-log records retain only the path; query parameters are removed completely. This also applies to the stored referrer. Existing records may still contain query parameters, including earlier result or confirmation tokens. They are not cleaned automatically on the next visit. A separate, repeatable routine first shows only the number of affected records and, when explicitly run, removes query strings from the URI fields without deleting whole records.

Technical logs and retention

In non-production environments, timing measurements may appear in the PHP/server error log. Deletion errors are also logged there, and affected records are considered again during later cleanup runs. Command-line programs write processing and error messages to standard output or standard error; server-side redirection may create additional log files. When successfully run, the cleanup script deletes visit records older than 90 days. The application code does not show how often the server actually runs it. The storage location and retention of external PHP, server, mail and CLI logs are determined by hosting operations and have not been verified here. The application code also does not establish whether web-server or hosting access logs retain complete query strings; this must be checked against the actual hosting configuration.

2. Account

Registration and login

During registration, the application stores the username, email address, password hash, confirmation-token hash and expiry, the fixed total registration period of seven days, and registration and confirmation timestamps. Passwords are not stored in plain text. Confirmation links are valid for up to 24 hours and never beyond the total registration period; individual links may expire sooner. Resending a link does not extend the total period. After expiry, unconfirmed registrations are scheduled for regular automatic deletion. Accounts with AI permissions or consents, diagnostic checks, diagnostic targets, diagnostic settings or batch records may be held for review to protect that data. The email address is used for activation and account-related messages. This policy states Article 6(1)(b) GDPR as the basis for registration. At login, the submitted credentials are checked; after successful login, the application uses the account ID and language preference in the session and renews the session ID.

Password reset

For password reset, the application processes the submitted email address to check account eligibility and send a time-limited link. Only confirmed, active accounts are eligible; this does not verify an email address, extend a registration deadline or lift a block. The application stores only the SHA-256 hash of the random reset token, the account ID, and creation and expiry times in UTC. The token is valid for 30 minutes; multiple requested links remain usable until their respective expiry times. After a successful password change, every link for the account is deleted and an account-wide session version is increased, making existing logins invalid at their next protected request. Expired tokens are removed during processed reset requests and by regular cleanup. HMAC-protected rate-limit counters contain no plain IP or email addresses; entries older than two days are removed opportunistically, but not necessarily immediately. Processing supports account recovery (Article 6(1)(b) GDPR) and abuse prevention (Article 6(1)(f) GDPR). Email addresses, tokens and passwords are not stored in application error logs or visit records; the token is in the URL fragment and is therefore not sent to the web server. The application does not control retention in external mail or server logs.

Account data

The account may be associated with settings, selected diagnostic checks and user-entered targets, upload mode, retention period, and assignment data for generated batch files, uploads and results. Access to registered results is checked against the account assignment.

Email messages

The application sends activation, password reset and account security emails, and may send upload notifications to configured addresses. Depending on server configuration, messages use PHP mail() or authenticated SMTP. SMTP credentials are read from server-side configuration and the connection is protected with TLS. For non-local uploads, the notification may include the IP address and user agent. The application does not control which messages mail providers log or store, or for how long.

3. Running a diagnosis and the demo

The following general rules on transfer, storage, deletion and data subject rights apply equally to Windows and Linux diagnostics unless a specific difference is expressly stated. The diagnosis runs on the system being examined. admin-tools.de receives diagnostic data only when an automatic HTTPS upload or a manual upload takes place.

Windows

The Windows batch file runs the selected checks and targets. Depending on selection, it may collect computer and user names, domain, operating-system and hardware data, local drive sizes and available storage, and total and available RAM, aggregate system CPU measurements over about five seconds, system uptime and the last kernel start when available. These storage checks do not collect drive labels, serial numbers, file paths or file contents. Other possible data includes processes and process users, window titles, drivers, mapped drives, adapter, IP, MAC, DHCP, DNS, routing and connection data, DNS cache, ARP table, proxy information, ping and traceroute results, Wi-Fi information and technical errors. User-entered targets may contain internal hostnames or IP addresses. The batch file first stores the result in a local temporary log; when automatic upload is enabled, it attempts transfer using PowerShell.

Linux

The Linux Bash script requires Bash and Python 3.8 or newer, runs as a normal user and rejects root. It installs no packages and makes no permanent changes. Depending on selection, it may collect the hostname, Linux version, kernel, CPU model, aggregate system CPU utilisation over about five seconds, system uptime and last system start in UTC, memory, total and available bytes for local filesystems, inode counts for local filesystems without collecting mount or file paths, username, processes, kernel modules, PCI devices, network shares, IP, DNS, routing, connection and neighbour data, network targets, response times, traceroute hops, Wi-Fi scans, Wi-Fi drivers and NetworkManager profile names. Ping, DNS, traceroute and TCP port checks may generate network traffic. Wi-Fi passwords, proxy credentials and process command lines are not requested. If upload fails, the log remains locally available for manual upload. Further technical details are on the Linux information page.

For explicitly configured HTTP(S) targets, the URL, transport result, HTTP status and duration may be processed. TLS checks may collect the validity period and trust or host name status; IPv4/IPv6 checks may include A/AAAA addresses and bounded TCP results for each address family. Credentials, query strings and fragments are not accepted in these URLs. Response content, cookies, full headers and complete certificates are not stored. Network probes run only on the examined endpoint.

Transfer and access links

Automatic uploads use HTTPS; manual uploads use an upload form. An individual upload token associates the log with a generated batch. The token appears in plain text in the generated batch file and submitted raw log; its hash is stored server-side for validation. Registered batch files may be reusable. The public demo uses a single-use upload token valid for 24 hours after creation. Uploadeded demo results and log downloads are available without signing in to anyone with the separate access link during its validity. Raw logs are stored in the result database up to 16 MB; uploaded files may be up to 25 MB. Diagnostic files are stored outside the public web root.

Static demo

The examples at /demo-result.php and /demo-linux.php use static, fictional values and do not run a diagnosis, upload or AI analysis. Separately, the Windows demo offers a batch download. Running that batch file on a system collects actual data from that system and starts the automatic upload. These demo uploads are not assigned to a registered account. The static preview is not an executed diagnosis and its values are not subject to the upload retention period.

4. Storage and deletion

Diagnostic retention periods

The default retention period for registered users is 90 days. Profilee settings allow a period from 1 to 300 days; a change may apply retroactively. Uploadeded demo diagnoses are retained for seven days from upload. After expiry, due uploaded diagnoses, associated database records and files are removed by the cleanup script when it runs. The application code does not establish how regularly the hosting server starts the script. Individual results can also be deleted using the deletion feature. If deletion fails, the database record remains for follow-up; file and database deletion are not atomic.

Batches without an upload

Diagnostic cleanup covers uploaded batches only. Generated batch records without an upload, unconfirmed accounts and saved account settings are not deleted by it. The cleanup code sets no automatic deletion period for demo batches that were never uploaded. Previously sent emails, external server logs and hosting backups are also not removed by diagnostic cleanup.

Account deletion

Account deletion can be requested in the profile. A confirmation link valid for 24 hours is sent to the registered email address. Deletion occurs only after explicit confirmation on the linked page; opening the link alone is not enough. A new link replaces the previous one; expired or used links are invalid. The application stores a verification value and the link expiry with the account. The confirmation email contains no diagnostic data. This processing supports secure account termination; this policy states Article 6(1)(b) GDPR as its basis. On successful deletion, the application removes the account, account settings, associated batch records even without an upload, stored files, raw logs, structured results and directly assigned visit records from the application database and file storage. Deletion cannot be undone within the application. If deletion fails, successful completion is not confirmed; another attempt may be needed.

Deletion within the application, including cleanup of unconfirmed registrations, does not remove files already downloaded to user devices, sent emails, technical server or mail logs, or existing hosting backups. Visit records not assigned to the account and technical session or abuse-prevention data are not completely removed. The application does not provide control for deleting individual records from backups. Operational documentation in the data processing agreement states that Hostinger currently keeps daily backups in France for seven days; the application does not control or verify these arrangements. Statutory retention duties remain unaffected where they apply in an individual case.

5. Optional AI analysis

Requirements and consent

AI is optional and available only when the account has been administratively enabled and an active, current consent exists for the provider and information version. Enablement and consent are separate requirements. Consent is given in the account and can be withdrawn there. It covers the initial analysis and follow-up questions described here; you or your organisation must also check that you are authorised to transmit the included data.

Data sent to the provider

For an initial analysis, the application sends a JSON request to the Perplexity Agent API endpoint. It contains structured diagnostic values, findings, check details and ping measurements, and, when present, a raw log redacted by the application and limited to 100,000 characters. The raw log may be omitted when the input budget is constrained. The application does not send the uploaded file or credentials as such. Diagnostic values and raw logs may nevertheless contain personal, confidential or internal information. Redaction is not anonymisation and may miss content.

Local storage

The application stores the JSON request text without the Authorization header and a payload snapshot locally. Valid provider responses are checked and stored as analyses. Partially valid responses are filtered to individually evidenced findings and marked incomplete. A fully invalid response may be stored as provider text for troubleshooting; it is not displayed as an analysis or used for follow-up questions. Dialog messages are also stored locally. These AI records follow the deletion rules for the associated diagnosis.

Follow-up questions

A follow-up may include the stored analysis, a bounded diagnostic context without the raw log or explicitly excluded secret fields, up to 20 stored completed dialog messages and the new input as an unconfirmed user statement. Text is redacted and shortened again; automatic redaction may miss content. Before each transfer, the server rechecks administrative enablement and current consent.

Withdrawal

Withdrawal in the profile blocks new analyses, follow-up questions and queued requests not yet sent to Perplexity before the provider call. Analyses and dialogs already stored locally remain visible and follow the diagnosis deletion rules. Regular diagnosis and evaluation remain available without AI.

Provider and possible processing outside the EEA

The provider is the Perplexity Agent API. Perplexity states that it uses computing infrastructure in North America, so processing outside the EEA is possible. According to Perplexity, request, billing, security and usage metadata may be processed. The application does not control these operations. Published statements about non-retention or non-use for model training for the Chat Completions API are not presented as a promise for the Agent endpoint used here. The provider documents do not establish final project-specific privacy clearance; the processing location and specific third-country guarantees have not been fully verified. AI answers may be wrong, incomplete or outdated and must be checked.

Technical details and the current information version are available on the AI information page. Provider information retrieved on 2026-09-26: Privacy & Security · FAQ · Perplexity DPA

6. Recipients, roles and your rights

Hosting and business roles

Diagnostic files are stored in the application’s server-side file storage; database data is held in the configured MariaDB/MySQL database. Operational documentation in the data processing agreement names Hostinger for hosting. Application code cannot establish the actual server location or operation. For business customer diagnoses, the customer generally determines the purpose, checks, targets and authority for the examination and informs data subjects. admin-tools.de provides the technical application. Whether processing on behalf of a controller applies depends on the specific agreement. Further hosting information is in the data processing agreement.

Rights and contact

Subject to statutory requirements, data subjects have rights including access, rectification, erasure, restriction of processing, data portability and objection. In a business context, the customer is generally the first contact. Requests may be sent to info@admin-tools.de; a complaint may also be lodged with a data protection supervisory authority. This policy will be updated when features, processing or legal requirements change.

Terms of use · Data processing agreement · AI information page