Privacy Policy

The controller within the meaning of Art. 4(7) GDPR is:

There is no designated Data Protection Officer (DPO). The controller is directly reachable via the contact details above.

This policy covers all processing carried out in connection with the website proxima·red and its associated services, including anonymous password sharing, registered user accounts, and the authenticated vault.

3.1 Server Access Logs

What: When any page is loaded, the web server automatically records standard HTTP access log data. This typically includes:

• IP address of the requesting device
• Date and time of the request (timestamp)
• HTTP method, requested URL path, and protocol version
• HTTP response status code and bytes transferred
• Referrer URL (if transmitted by the browser)
• User-Agent string (browser name, version, operating system)

Who processes it: The hosting provider (Hostiko, UA), acting as a processor. No data processing agreement is currently in place; see Section 05. The controller does not have direct access to raw log files.

Purpose: Ensuring stable and secure operation — detecting attacks, abuse prevention, and fault diagnosis.

Legal basis: Art. 6(1)(f) GDPR — legitimate interests. The legitimate interest is the secure and reliable provision of the service.

Retention: Log files are retained for a short period (up to 7 days) and then automatically deleted by the hosting provider. The controller does not retain copies.

3.2 Session Cookie — Authenticated Users Only

What: Upon successful sign-in, Django sets a single session cookie named sessionid. This cookie contains an opaque random token that links the browser to the server-side session record. The session record stores:

• The authenticated user's internal numeric user ID
• A flag confirming successful authentication

No personal name, e-mail address, or plaintext secret is stored in the session.

Attributes: HttpOnly · Secure (HTTPS) · SameSite=Lax · max-age 30 minutes. The cookie is not set for visitors who do not sign in.

Purpose: Maintaining the authenticated session so the user can access the vault without re-authenticating on every request.

Legal basis: Art. 6(1)(b) GDPR — processing is necessary for the performance of the service contract with the user (providing authenticated access to the vault). Under § 25(2) Nr. 2 TDDDG, no separate consent is required for cookies that are strictly necessary for a service explicitly requested by the user; a session authentication cookie meets this criterion.

Retention: The session is automatically invalidated after 30 minutes of inactivity. The user can also invalidate it explicitly by signing out. Expired sessions are purged from the database by Django's session cleanup mechanism.

3.3 CSRF Token Cookie

What: Django sets a CSRF cookie (csrftoken) on all pages that include forms. It holds a random token used to verify that state-changing POST requests originate from this site and not a third-party page (cross-site request forgery protection).

Attributes: Not HttpOnly (must be readable by the JavaScript AJAX client) · Secure (HTTPS) · SameSite=Lax.

Purpose: Security mechanism required by the web framework to prevent CSRF attacks.

Legal basis: Art. 6(1)(f) GDPR — legitimate interests (technical security of the service). Under § 25(2) Nr. 2 TDDDG, no consent is required; the CSRF cookie is strictly necessary for the secure operation of a service explicitly requested by the user.

Retention: Session-scoped; deleted when the browser session ends or on sign-out.

3.4 Anonymous Password Shares

What: When a visitor creates a password share without an account, the server stores in the database:

Field	Content
id	UUID (randomly generated, not linked to any person)
encrypted_data	AES-256-GCM ciphertext of the secret (Base64)
iv	Initialization vector used for encryption (Base64)
encrypted_title	AES-256-GCM ciphertext of the optional title (Base64), if provided
title_iv	IV for the title ciphertext (Base64), if provided
created_at	Timestamp of creation
expires_at	Expiry timestamp (1 hour · 1 day · 1 week · 4 weeks — chosen by the creator)
access_count	Number of times the share was retrieved
created_by	NULL (no account linked)

The encryption key is never transmitted to the server. It is embedded solely in the URL fragment (#), which browsers do not include in HTTP requests.

Purpose: Providing the password-sharing service.

Legal basis: Art. 6(1)(f) GDPR — legitimate interests. The legitimate interest is providing the password-sharing service as explicitly requested by the user. No account or contract exists for anonymous shares; the user initiates the transaction voluntarily and the server processes only what is technically necessary to fulfil that specific request.

Retention: Each share is automatically deleted when its expiry timestamp is reached. A background job (delete_expired) runs every minute in production. A share is also deleted immediately when it is accessed after its expiry time. The maximum retention period is 4 weeks.

3.5 Registered User Accounts

What: When a visitor creates an account, the server stores:

Field	Content
user_id	8-digit numeric identifier, randomly generated
password_hash	Argon2 hash of a client-derived authentication secret
auth_salt	Public KDF salt for the client-side auth secret derivation (Base64)
vault_salt	Public KDF salt for the client-side vault key derivation (Base64)
created_at	Account creation timestamp
updated_at	Timestamp of last account modification

There is no name, e-mail address, or any other identifying attribute. The user's account password is never transmitted to or stored by the server. The browser derives a separate authentication secret (via PBKDF2-SHA256, 100,000 iterations, domain-separated) from the password and the auth_salt; only this derived secret is sent during sign-in. The server stores its Argon2 hash. Possession of the hash does not allow the server to derive the vault key.

The auth_salt and vault_salt are public inputs published by the /auth/salts/ endpoint. For unknown user IDs, deterministic decoy salts are returned so that the endpoint is not an account-existence oracle.

Purpose: Providing authenticated access to the vault and associating password shares with an account for management purposes.

Legal basis: Art. 6(1)(b) GDPR — processing is necessary for the performance of the service contract.

Retention: Account data is retained for as long as the account exists. Users may request deletion of their account (see Section 08). When an account is deleted, all associated SharedPassword records and the encrypted vault blob are cascade-deleted.

3.6 Encrypted Vault Blob (ServiceData)

What: Authenticated users who save data to the vault cause the server to store a ServiceData record:

Field	Content
user	Foreign key to the User record
encrypted_data	AES-256-GCM ciphertext of the user's vault contents
iv	12-byte initialization vector for the encryption (binary)
created_at · updated_at	Timestamps

The vault is encrypted with the vault key, which is derived entirely in the browser from the account password and the vault_salt. The vault key is stored only in sessionStorage for the duration of the browser session; it is never sent to the server. The server stores only opaque ciphertext.

Purpose: Persisting the user's vault across devices and sessions.

Legal basis: Art. 6(1)(b) GDPR — performance of the service contract.

Retention: As long as the account exists. Cascade-deleted with the account.

3.7 Rate-Limiting Counters

What: To prevent abuse, the service enforces per-IP rate limits on sensitive endpoints (share creation: 60/h; share retrieval: 120/h; vault access: 100/h; vault updates: 20/min; data export: 10/h). Rate-limit counters are keyed on the client IP address and stored in a shared in-memory cache (Redis in production). The IP address used for rate limiting is derived from the X-Forwarded-For header (resolved for the configured number of trusted proxies).

Purpose: Abuse prevention and protection of service availability.

Legal basis: Art. 6(1)(f) GDPR — legitimate interests (service security and availability). The counters are ephemeral; they hold no content associated with a user's identity beyond the IP address and a hit count.

Retention: Counters expire automatically in accordance with the rate-limit window (minutes to hours). No persistent log of IP addresses is maintained by the application itself.

Under § 25(1) TDDDG, storing information on a user's device or accessing information already stored requires the user's consent unless an exception applies. Under § 25(2) Nr. 2 TDDDG, consent is not required if the storage or access is strictly necessary for the provision of a telemedia service explicitly requested by the user.

proxima·red sets exactly two cookies:

Cookie	Purpose	Necessity	Consent required?
sessionid	Authentication session	Strictly necessary	No
csrftoken	CSRF protection	Strictly necessary	No

No marketing, analytics, profiling, or tracking cookies are set. No consent banner is shown because no consent-requiring storage operations occur.

Processor	Role	Data involved	Safeguard
Hostiko (UA)	Infrastructure, server, access logs	IP address, request metadata	No DPA currently in place. A DPA has been requested; the provider has confirmed EU-only data residency and added DPA support to their roadmap.

No other third-party processors receive personal data. No third-party scripts, fonts, analytics services, CDNs, or social media integrations are used.

The hosting provider has confirmed that server infrastructure and all associated data processing is located within the EU (Warsaw, Poland). No formal transfer mechanism has been established with third countries, as no such transfer is understood to take place.

Data	Retention period
Server access logs	Up to 7 days (deleted by hosting provider)
Session cookie / session record	30 minutes inactivity timeout; deleted on sign-out
CSRF cookie	Browser session
Anonymous password shares	Up to the chosen expiry (max 4 weeks); deleted automatically at expiry
User account data	Until account deletion
Encrypted vault blob	Until account deletion
Rate-limit counters	Minutes to hours (automatic expiry)

Under the GDPR you have the following rights. To exercise any of them, contact signal@proxima.red. A response will be provided within one month (Art. 12(3) GDPR).

Right	Article	Notes
Access	Art. 15 GDPR	Request confirmation of and access to personal data held about you.
Rectification	Art. 16 GDPR	Request correction of inaccurate or completion of incomplete data.
Erasure	Art. 17 GDPR	Request deletion of your account and all associated data. Note: encrypted vault data cannot be decrypted by the server; deletion removes the ciphertext.
Restriction of processing	Art. 18 GDPR	Request that processing be restricted under certain conditions.
Data portability	Art. 20 GDPR	Receive your personal data in a structured, machine-readable format where processing is automated and based on consent or contract.
Objection	Art. 21 GDPR	Object to processing based on legitimate interests (Art. 6(1)(f)). This applies to server log processing and rate-limiting.
Withdrawal of consent	Art. 7(3) GDPR	Not currently applicable (no processing relies on consent).

Practical note on access and portability requests: Account data held by the server consists of a random 8-digit ID, an Argon2 hash, and two public KDF salts — none of which reveals the account password or vault contents (which remain encrypted). Authenticated users can export their vault data via the account page, which returns the encrypted blob; decryption happens in the browser.

Requests relating to server log data will be forwarded to the hosting provider, as the controller does not retain copies.

You have the right to lodge a complaint with a data protection supervisory authority (Art. 77 GDPR). The competent authority for the controller (located in Saxony, Germany) is:

You may also contact the federal authority:

This policy will be updated if processing activities change. The "Last updated" date at the top of this document reflects the date of the most recent revision. Continued use of the service after a material change constitutes acknowledgement of the updated policy.