Privacy Policy – AWP Exchange Server

Service: AWP Exchange Server (the “Service”), operated at awp.exchange
Canonical URL of this policy: https://awp.exchange/privacy-policy
Last updated / Effective date: 24 June 2026

This Privacy Policy explains what personal data the AWP Exchange Server collects, why, on what legal basis, how long it is kept, and the rights you have. It is written for the site owners who install the AWP WordPress plugin and connect their site to this Service.

This policy is intentionally precise: it describes only the data practices that are actually implemented in the Service.

1. Identity and Contact Details of the Controller

The controller responsible for the personal data described in this policy is:

Operator: Dalibor Veselinović, a natural person operating under the trade name “Web Evolution”
Place of establishment: Serbia
Company registration number / PIB: Not applicable (the Operator is a natural person)
Postal address: available on request via the contact email
General/privacy contact email: support@webevolution.company

The operator is established in Serbia and is subject to the Serbian Law on Personal Data Protection (Zakon o zaštiti podataka o ličnosti, “ZZPL”), which is closely harmonized with the EU General Data Protection Regulation (“GDPR”). Where the operator targets or monitors individuals in the EU, GDPR also applies under Art. 3(2).

EU representative (GDPR Art. 27): No EU representative is currently appointed. The Operator’s processing of EU individuals’ data is occasional and low-risk, and the Operator relies on the exemption under GDPR Art. 27(2). The Operator will appoint an EU representative if and when required.

Serbian representative for foreign controllers (ZZPL Art. 44): Not applicable; the Operator is established in Serbia.

2. Data Protection Officer (DPO)

No Data Protection Officer is required or has been appointed. For any privacy matter, please use the contact email support@webevolution.company.

3. Categories of Personal Data Collected

The Service is a backend optimization service that your AWP WordPress plugin connects to. It is designed to collect as little personal data as possible. The categories below reflect exactly what the Service stores and processes.

3.1 Data you (or your plugin) submit

When your site connects to the Service, the following registration data is recorded for your tenant (account) record:

Site name (by default, the host of your site URL)
Site URL / domain of the WordPress site being connected
Administrator email address associated with the site
Optional notes (added by the operator on your record)

This registration data is stored in the Service’s tenant table (wp_awp_brain_tenants). The administrator email may identify a natural person and is therefore treated as personal data.

3.2 Credentials and secrets generated for your tenant

When your site connects, the Service generates the following credentials server-side and returns them to your site over HTTPS; you do not choose or submit them:

API key — generated by the Service for your site. The plaintext key is never stored in the database; only a SHA-256 hash and a short non-secret key prefix (the first 8 characters) are persisted, used to identify and authenticate your tenant. Note that if an optimization request presents an unrecognized key, the first 8 characters of the rejected key may appear in a diagnostic message stored in the activity log (see §3.4).
Shared secret (used to sign optimization instructions) — stored AES-256-GCM encrypted at rest when the operator’s key-encryption key (AWP_BRAIN_SECRET_KEK) is configured. The production awp.exchange deployment has this key configured, so the shared secret is encrypted at rest. (In development environments without that key, the software falls back to plaintext storage; this fallback is not used in production.) The shared secret is returned to your site in plaintext over HTTPS at connect time and is decrypted on each read so your site can verify signed instructions.

3.3 Operational/account metadata

Tenant status, plan (the default plan is the free plan), quota limit and quota used, total request count, last-seen timestamp, and created/updated timestamps. These support plan management and quota enforcement. The free plan includes a default quota of 100 optimizations (see §11).

3.4 Data collected automatically — request activity log

For each optimization request, the Service writes one row to an append-only activity log (wp_awp_brain_activity) containing:

Timestamp of the request
Target URL of the page that was optimized (a public URL on your registered site)
Rendering mode
Outcome status and HTTP response code
Execution duration (milliseconds)
Aggregated counts only: number of images, CSS selectors, and background-image overrides discovered
A free-text diagnostic error message when a request fails or is rejected (e.g. a render error code, or a notice that an unrecognized API-key prefix was presented). This field is intended for technical diagnostics and may incidentally contain a URL fragment or a truncated key prefix.

Important — what is NOT logged: The activity log does not record client IP addresses, request headers, cookies, or any per-image / per-rule detail. Beyond the fields listed above, no other request metadata is stored.

Note on IP addresses: During the initial site-connection step, the source IP address of the connecting request is used transiently to rate-limit (throttle) repeated connect attempts. The IP value itself is not stored: it is hashed into the name of a short-lived WordPress transient (key form awp_brain_connect_rl_<md5(IP)>) whose stored value is merely a counter and which expires after 60 seconds. The raw IP is never written to the activity log, the tenant record, or any persistent store. (Site-ownership verification and protection against server-side request forgery, “SSRF”, are handled separately by URL validation — same-host, HTTPS-only, and public-IP checks — not by this IP throttle.)

3.5 Data processed during optimization (transient only)

Optimization involves two flows of data, both processed transiently — neither is written to the tenant record or the activity log.

(a) Data your site sends for each optimization. An optimization happens in two quick steps:

Your plugin sends the post ID, post type, target URL (a public permalink on your registered site), your site’s CSS-optimization settings (the values of the awp_css_* options), the post’s CSS “safelist” (a per-post list of selectors to preserve), and the chosen optimization mode options. The Service renders that page to discover which images appear on it.
The Service returns the list of those on-page image URLs, and your plugin sends back metadata for only those images — for each: its URL, pixel dimensions, MIME type, and the URLs of its already-generated size variants.

No image files/binaries and no server file paths are sent (URLs and metadata only), and the image metadata is limited to the images on the page being optimized — not your whole media library. All of it is used only to compute the optimization result and is not stored.

(b) Page content fetched and rendered server-side. To produce the result, the Service also fetches and renders the public page at the target URL server-side. During this step it handles, in memory only and never stored:

the fetched page HTML;
the rendered DOM (after the page’s own client-side JavaScript runs);
extracted image elements and URLs;
extracted CSS stylesheets and selectors;
extracted background-image URLs.

This rendering happens in a local, sandboxed, non-root headless Google Chrome process on the operator’s own server (no third-party rendering service is used). The Service does not store rendered pages, screenshots, HTML, or any DOM serialization. Only a JSON summary of the optimization candidates is used internally, and the final manifest returned to your site is a signed instruction set (per-viewport image identifiers and CSS strings) — not a copy of your page or any screenshot.

Two short-lived temporary files drive the render worker: a job/input file (the render instructions) and an error/console file (which receives the render worker’s standard-error stream, including any console output forwarded from the rendered page). Both are deleted immediately after each render and never retained.

3.6 Billing data (paid “Unlimited” plan), if/when offered

No paid plan is currently offered through this Service; “Unlimited” exists only as an internal plan label, and no billing data, payment processor, or checkout is integrated. No billing data is collected.

If a paid plan is offered, billing-related data (e.g. billing name, billing email, and payment-method identifiers handled by the payment processor) is processed solely to take payment and meet tax/invoicing obligations. Full card data is handled by the payment processor, not stored by the Service. See Section 5 (Recipients) and Section 7 (Retention).

3.7 Support correspondence

If you contact the operator for support, the operator processes the contact details and content of that correspondence to respond. Support is available at support@webevolution.company.

4. Purposes of Processing and Lawful Basis

For each purpose below, the lawful basis under GDPR Art. 6 (and the equivalent ZZPL provision) is identified.

Purpose	Data used	Lawful basis
Register your site, authenticate requests, and provide the optimization service	Tenant registration data (§3.1), API key hash and shared secret (§3.2), target URL, page-scoped image metadata and CSS settings, and transient page content (§3.5)	Performance of a contract — Art. 6(1)(b)
Manage free/paid plans and enforce the optimization quota	Plan, quota limit/used, request count, activity counts (§3.3, §3.4)	Performance of a contract — Art. 6(1)(b); and legitimate interests — Art. 6(1)(f) for quota enforcement
Security, abuse/fraud prevention, SSRF protection, rate-limiting	Transient source IP at connect time (§3.4 note), activity status/HTTP codes/error diagnostics (§3.4)	Legitimate interests — Art. 6(1)(f)
Operational analytics and reliability (aggregated request counts, durations, error rates)	Activity log aggregates (§3.4)	Legitimate interests — Art. 6(1)(f)
Take payment for the paid plan (if offered)	Billing data (§3.6)	Performance of a contract — Art. 6(1)(b)
Keep tax/invoicing records (if a paid plan is offered)	Billing/invoice records (§3.6)	Legal obligation — Art. 6(1)(c)
Optional marketing or non-essential analytics, if any	As applicable	Consent — Art. 6(1)(a)

Legitimate-interests balancing: Where the operator relies on legitimate interests (security, quota enforcement, reliability), it processes only the minimal, mostly aggregated/transient data described above, does not store IP addresses or page content persistently, and considers this proportionate and not overriding your interests or fundamental rights. You may object as described in Section 8.

If the operator relies on consent for any optional purpose, that processing does not begin until consent is given and you may withdraw it at any time (Section 9).

5. Recipients and Sub-processors

The Service runs on infrastructure operated for the operator. The only third party that processes personal data on the operator’s behalf in the Art. 28 sense is the hosting provider; with that provider the operator commits to having an appropriate data processing agreement (GDPR Art. 28 / ZZPL equivalent) in place. The remaining items below are software components that run locally on the operator’s own server and do not, by themselves, transmit your data to any third party.

Hosting / processing infrastructure (sub-processor):

ContraTeam — VPS hosting provider (Ubuntu/Debian, KVM) on which the Service, its rendering engine, and its database run. The hosting region is Serbia, and the operator commits to having an appropriate Art. 28 DPA in place with this provider.

Local software components (not third-party data recipients):

MariaDB — local database engine on the same server (stores tenant and activity data).
Google Chrome / Chromium (stable) — runs locally on the server to perform rendering; the browser binary is downloaded from Google’s distribution servers during setup. Page rendering does not send your data to Google.
Node.js and Playwright-core — local components that orchestrate the headless browser on the server.
Let’s Encrypt / Certbot — issuance and renewal of the TLS certificate for awp.exchange.

Outbound calls that carry your data — and only these:

Site-ownership verification (Connect): the Service makes an outbound HTTPS request to the verification/callback URL you provided (on your own site’s host) to confirm you control the site. The source IP of your connecting request is read at this step only, and is handled transiently as described in §3.4.
CSS fetch (Optimize): the Service fetches the public page URL you submitted (with optimization temporarily disabled) to read its stylesheets.

Both calls go only to public, HTTPS URLs that you control. The Service makes no calls to analytics platforms, advertising networks, webhooks, or telemetry services with your data.

Payment processor (paid plan): Not applicable — no payment processor is currently integrated. The payment processor will be specified when the Unlimited Plan is made available.
Transactional email provider (if used): Not applicable; no third-party transactional email provider is used.
Error-logging / analytics providers: None used by the Service for client data.
Offsite backup provider: Not currently used. The backup script contains a disabled (commented-out) option to copy encrypted backups offsite to Backblaze B2 (a US-based provider). This is not deployed. If it is enabled in future, it would constitute an onward transfer (see §6), this policy would be updated to name Backblaze B2, and an appropriate transfer mechanism would be put in place.

6. International Data Transfers

The operator is established in Serbia, which does not hold an EU adequacy decision as of the effective date of this policy. Consequently, when personal data of individuals in the EU is sent to the operator in Serbia, this constitutes a transfer to a third country under GDPR Arts. 44–49.

For such transfers, the operator relies on:

EU Standard Contractual Clauses (SCCs) as the transfer safeguard, supported by a Transfer Impact Assessment; and
the data-minimizing technical measures described in this policy (hashing of keys, encryption of the shared secret at rest, no persistent IP logging, no storage of page content).

A copy of the relevant transfer safeguards can be requested at support@webevolution.company.

Onward transfers by sub-processors: Personal data processed by the Service is currently hosted only with the hosting provider in Serbia; no onward transfer outside that region currently occurs. The Service’s backup process keeps encrypted backups locally on the server only; the optional offsite copy to Backblaze B2 (US) described in §5 is disabled. Should any sub-processor (for example a future offsite backup destination or payment processor) process data outside Serbia or the EEA, the operator will rely on an appropriate transfer mechanism for that onward transfer and update this policy accordingly.

7. Retention Period

Data category	Retention
Activity log (request log, §3.4)	30 days by default (configurable by the operator via a retention setting). A daily automated job deletes rows older than the retention window. The operator’s committed maximum retention for this log is 90 days.
Tenant / account record (§3.1–§3.3)	Kept for the life of your account/connection. There is no automatic deletion; it is removed on request or by the operator via administrative action.
API key hash / shared secret (§3.2)	Kept while the tenant is active; can be regenerated/rotated at any time (by re-connecting your site or by the operator).
Transient page content (§3.5)	Not retained — processed in memory; the temporary render job file and error/console file are deleted immediately after each render.
Connect-time IP throttle (§3.4 note)	60 seconds — the IP value is not stored; only a short-lived hashed-key counter, which expires automatically.
Rate-limiting / concurrency / render-slot state (optimize side)	Temporary only — held in short-lived WordPress transients keyed by tenant (rate-limit default 60s; per-tenant concurrency lock 120s; global render slot 300s) and not persisted.
Backups	Encrypted server backups are retained as the 7 most recent archives; the oldest is deleted on each new backup run (see “About backups” below).
Billing / invoice records (if a paid plan is offered)	Not currently applicable (no paid plan is offered). If a paid plan is later introduced, billing/invoice records will be retained for the statutory tax-retention period as required under Serbian tax law.
Support correspondence	Retained as needed to handle the request and for a reasonable follow-up period.

About backups: Daily server backups are created on the server. Each backup contains a full dump of the Service database (awpexchange) — including the tenant table, and therefore your site URL and administrator email and the hashed/encrypted credentials — plus the server configuration file (wp-config.php), which contains database credentials and signing/secret material. Because of this, your tenant data (including your administrator email) also exists inside backups for up to seven backup cycles even after the live record is changed or deleted (see §8). Backups are encrypted with AES-256 (symmetric GPG). The decryption passphrase is stored only as a root-owned file on the server, never in the database — so a database-only leak cannot decrypt the backups. Backups are stored outside the web root; the encrypted archives can be listed, downloaded, and deleted by the operator through an authenticated administrative page, but remain unreadable without the root-held passphrase.

8. Your Data-Subject Rights

Subject to the conditions in GDPR / ZZPL, you have the right to:

Access the personal data held about you;
Rectify inaccurate or incomplete data;
Erase your data (“right to be forgotten”);
Restrict processing in certain circumstances;
Data portability — receive certain data in a structured, machine-readable format;
Object to processing based on legitimate interests.

To exercise any right, contact support@webevolution.company. The operator will respond without undue delay and within one month of the request (extendable by two further months for complex requests, with notice). Identity verification may be required to protect your data.

Note that deleting your tenant record will disconnect your site from the Service. Backups and erasure: when data is erased from the live system, copies may persist in the encrypted backups described in §7 until those backups rotate out (up to seven backup cycles). During that window the backed-up copies are not used for any active processing and remain encrypted; they are removed automatically as the backups rotate.

9. Right to Withdraw Consent

Where processing is based on consent (e.g. any optional marketing or non-essential analytics), you may withdraw that consent at any time, without affecting the lawfulness of processing carried out before withdrawal. To withdraw consent, use support@webevolution.company or the relevant control where the consent was given.

10. Right to Lodge a Complaint

If you believe your data has been handled unlawfully, you may lodge a complaint with the Serbian supervisory authority:

Commissioner for Information of Public Importance and Personal Data Protection (Poverenik) — Republic of Serbia.

If you are in the EU, you may additionally complain to the supervisory authority (Data Protection Authority) in your country of residence or place of the alleged infringement.

11. Is Providing Data Required?

Providing the site registration data (site URL and administrator email) is necessary to create a tenant and use the Service — without it, your site cannot connect or be optimized. The API key and shared secret are generated automatically by the Service when you connect; you do not supply them. Submitting a target URL is necessary for each optimization request. The free plan permits a default of 100 optimizations; if a paid plan is later offered, providing billing data would be necessary to subscribe to and pay for that plan. If you do not provide the required data, the corresponding part of the Service cannot be provided.

12. Automated Decision-Making and Profiling

The Service does not make solely-automated decisions producing legal or similarly significant effects about you.

Some automated logic exists for operational purposes only: quota enforcement (counting optimizations against your plan limit) and abuse/rate-limiting (throttling and blocking requests that exceed limits or fail security checks). These determine only whether a given optimization request is served and have no legal or similarly significant effect on you as an individual.

13. Cookies and Tracking Technologies

The plugin-to-Service connection is an authenticated API integration, not an embedded interface; the optimization API calls themselves do not set cookies on your visitors.

For any web dashboard or account pages hosted at awp.exchange, the following applies: the optimization API sets no cookies on your visitors; the Operator’s admin area uses only strictly-necessary WordPress session/login cookies; no analytics or marketing cookies are used.

14. Children’s Data

The Service is a technical, business-oriented tool and is not directed to children. It is not intended for, or directed to, individuals under the applicable age of digital consent (16 under GDPR by default, or the lower age set by national law where applicable). The operator does not knowingly collect personal data from children. If you believe a child’s data has been provided to the Service, contact support@webevolution.company and it will be deleted.

15. Security Measures

The operator applies technical and organizational measures appropriate to the risk (GDPR Arts. 32–34 / ZZPL equivalents), including:

Encryption in transit: all data exchange occurs over HTTPS/TLS (certificates via Let’s Encrypt). Both the connect callback and the page fetch require HTTPS, and credentials returned at connect time are transmitted only over HTTPS.
Encryption / hashing at rest: API keys are stored only as SHA-256 hashes (plaintext never persisted); the per-tenant shared secret is AES-256-GCM encrypted at rest (the production deployment has the key-encryption key configured); backups are AES-256 (GPG) encrypted with a passphrase stored outside the database. The shared secret is decrypted only in memory when needed to verify signed instructions.
Data minimization: no IP addresses, request headers, or page content are persistently stored; the activity log holds only request outcomes, aggregated counts, and short diagnostic error messages.
Server-side, in-process rendering: page rendering runs locally on the operator’s server (sandboxed, non-root browser process); rendered content and the render worker’s temporary job and error/console files are transient and deleted immediately after each render.
SSRF and abuse protections: the connect and optimize endpoints require public HTTPS URLs on your own registered host, reject private/internal/metadata addresses, and apply rate-limiting and concurrency controls.
Access controls: backups are kept outside the web root with restricted file permissions and are managed only through an authenticated administrative page; the backup passphrase and the key-encryption key are stored on the server (root-held / configuration only), never in the database. Note that the backup set includes the database dump and the server configuration file containing credentials, which is precisely why the backups are encrypted at rest and the passphrase is held only by the root account.

Breach handling: In the event of a personal-data breach likely to result in a risk to individuals, the operator will notify the competent supervisory authority and, where required, affected individuals, in line with GDPR Arts. 33–34 and ZZPL.

16. Controller vs. Processor Roles

For your account, registration, and billing data, the operator (Web Evolution) acts as a data controller.
For any personal data of your own end users that may be contained in the website content processed through the Service, the operator acts as a data processor acting on your instructions. In that capacity, a separate Data Processing Agreement (GDPR Art. 28 / ZZPL equivalent) is available on request at support@webevolution.company.

Note that the Service is designed so that page content is processed transiently and not stored, which minimizes any end-user personal data the operator handles as a processor.

17. Changes to This Privacy Policy

The operator may update this policy from time to time. The “Last updated / Effective date” at the top of this document reflects the current version. Material changes will be communicated by updating this page and, where appropriate, notifying the administrator email on file. Continued use of the Service after the effective date of an update constitutes acknowledgment of the revised policy, to the extent permitted by law.

18. Contact for Privacy Inquiries

For any privacy question or to exercise your rights, contact:

Operator: Dalibor Veselinović, a natural person operating under the trade name “Web Evolution”
Privacy email: support@webevolution.company
Postal address: available on request via the contact email
EU representative: None appointed; the Operator relies on the GDPR Art. 27(2) exemption and will appoint one if/when required.
Serbian representative for foreign controllers: Not applicable; the Operator is established in Serbia.

This Privacy Policy describes the data practices of the AWP Exchange Server backend service at awp.exchange. The AWP WordPress plugin is the client interface that connects your site to this Service. The plugin code distributed on WordPress.org is licensed under the GPL; that license covers the plugin code only and does not grant rights to the hosted Service, which is governed by its own Terms of Service and this Privacy Policy.