ProjektometrPoland’s megaproject database

Privacy

What this site knows about you.

Projektometr shows no ads, embeds no social plugins and does not profile readers. The code of this site sets no cookies. What remains is the technical handling of traffic, aggregate visit statistics, browser error reports and a feature usage counter. Each is described below: what leaves your browser, who receives it, and how long it stays there.

We process data on the basis of a legitimate interest, so you have the right to object to that processing (article 21 GDPR). It has its own section below.

Last updated: 6 September 2026.

Data controller

The data controller is Krzysztof Głuszczyk, the author and publisher of Projektometr. This is a private civic initiative, run outside any company, party or public institution.

Contact for anything to do with data, including an objection and the other rights described below: kontakt@projektometr.pl. It is the same address that takes corrections to the database.

What is collected

Five things, one at a time, with hosting covering two channels: the request to the server itself, and the network error reports your browser sends to Cloudflare on its instruction. Hosting and the typefaces are always active. The script error reports and the usage counter are switched on by deployment configuration, and while one of them is off its script is never loaded. The visit statistics work differently, as described in their own block: our code does not embed them, but Cloudflare can insert their script on its own side.

Hosting (Cloudflare)

The site is served by Cloudflare Pages. Every request to the server carries an IP address, browser headers and the address of the requested page. Cloudflare processes those to deliver the page and to protect it from abuse, including volumetric attacks and automated traffic. The code of this site keeps no application logs of its own and no visitor database of its own. What Cloudflare records on its own side follows from its configuration and its policy, not from our code. Cloudflare also adds NEL and Report-To headers to every response, an instruction to the browser to report failed connections to this site to a.nel.cloudflare.com. Such a report carries the request address, the error type, the server IP address, the response time and the referring address, and the browser sends it itself, so it arrives with your IP address. In the responses we can see, sampling of successful connections is set to zero and the policy is valid for seven days, so a report can go out even when our page is no longer open. Our code sets none of those headers and our content security policy does not reach them: Cloudflare adds them on its own side, exactly as it does the visit statistics script.

Typefaces (served by us)

The typefaces are part of this site and the font files load from this site’s own origin. There is no outside font library here, so displaying the text sends no request anywhere beyond the hosting described above. The files sit beside the rest of the assets on Cloudflare. The content security policy header allows this origin alone as a font source, so a return to an outside provider cannot happen unnoticed.

Visit statistics (Cloudflare Web Analytics)

Aggregate traffic statistics. The measurement script is fetched from a Cloudflare server (static.cloudflareinsights.com), so from a different domain than the rest of the page, and it is that script which sends the measurements to Cloudflare. Cloudflare documents that the tool stores no cookies and no other client-side state in your browser, and does not identify a person by IP address or by browser signature.

This script does not come from our code. No measurement token is configured in this build, so we embed nothing of the sort ourselves. Cloudflare adds it on its own side, in flight, as the page passes through its network, and what decides that is a setting in the hosting panel, a switch at the provider rather than a part of this code. It is set to the variant that excludes visitor data in the European Union, which per Cloudflare documentation does not process performance data for people connecting through a Cloudflare data centre located in one of the countries listed there. That list covers Poland and the whole European Economic Area, and beyond it the United Kingdom and Switzerland. For a connection from outside that region the exclusion does not apply and the measurements described below reach Cloudflare.

The dimensions Cloudflare lets us view are wider than a page-view count: country, host, page path, referring site, device type, browser, operating system and navigation type. Page performance measurement (Core Web Vitals) can additionally carry the CSS selector of the measured element, the page path, the address and size of a loaded resource, and the position and dimensions of an element that shifted.

What the dashboard shows us are aggregate numbers for the whole site, not one person’s path through it. That describes what we get to look at; it is not proof that the data is anonymous along the way.

Error reports (Sentry)

When a script fails in your browser, a technical report goes to Sentry. Until something breaks, the library sends nothing: we switched off the default mechanism that reported the mere opening of a page to Sentry.

A report contains:

  • the error message and the stack trace, that is, the places in the page code the execution passed through;
  • the address of the page it happened on, without the query string and without the part after the hash;
  • the User-Agent header, from which Sentry derives the name and version of the browser and the operating system;
  • the environment name (production or staging) and the release identifier, that is, the commit hash;
  • the language, time zone and calendar set in the browser;
  • the last few steps: moves between pages and requests to our own API, in both cases with the query string removed from the address;
  • a random report identifier, new for every event.

The code limits what reaches that report. Clicks and key presses are not recorded: by default the library stores the CSS path of the element you hit, and that collection is switched off here. Console entries are switched off in the same way, and session replay is not enabled. From the report we delete the IP address field, the Referer header and the X-Forwarded-For header, and the query string is stripped from the request address, from the stack trace and from the record of recent steps, because the link that brought you here could have carried a token or an email address.

What this does not guarantee. The IP address is visible to Sentry servers from the connection the report travels over, and deleting the address field does not change that. The report carries no instruction that would stop Sentry from filling the address in on its own side either: our code deletes the whole user container from the event and switches off the library default that collects personal data, which is not the same as explicitly setting the address field to null. Whether the address is stored is decided by the "Prevent Storing of IP Addresses" setting in the Sentry panel, a switch at the provider rather than a part of this code. Nor do we claim that a report contains nothing pointing at a person: the text of an error message comes from the page code, and the library does not check what ended up in it.

The Sentry library loads only after the page has rendered, and only when error reporting is enabled in the deployment configuration. It is not switched off by Do Not Track or Global Privacy Control: those govern the feature usage counter alone, described below.

Feature usage counter

Our own counter, cookieless. It sends events to our own /api/ev address, on the same domain. No outside script takes part in it, but the request itself travels through Cloudflare, like every other request to this site.

An event carries a short name from a closed list (a filter change, a map interaction, opening a project card, switching language, switching theme, following a source link, clicking the coffee button) and a few labels with very few possible values: which filter, which value, which kind of interaction, and which language. The server rejects anything not on that list and adds one field of its own: whether the request came from production or from staging. The stored row contains no page address, no identifier and nothing you typed into the search box.

The address of the page you are viewing is in neither the event body nor the stored row, but the browser attaches it itself, in the Referer header: for requests within the same domain it sends the full address. That header is ignored when the row is written, yet it does reach Cloudflare together with the IP address, exactly as with every other request to the site.

The counter honours the Do Not Track and Global Privacy Control signals: if your browser sets either of them, it sends nothing at all.

Cookies and browser storage

The code of this site sets no cookies. It does store three small entries in browser storage, so your settings survive a move to another page:

  • megalo-theme: the chosen theme, light or dark;
  • megalo-lang: the chosen language of the site;
  • megalo-explore-return: the return address to the project list with your filters kept. This one lives in session storage and disappears when you close the tab.

The entries stay in your browser. They are read only by the page code running on your own machine, to restore your setting; they are not sent to the server. If the feature usage counter is enabled, the chosen theme and the chosen language go to it as an event at the moment you switch, so the same values appear in the aggregate statistics. They are taken from your click, though, rather than read out of browser storage.

You can clear the entries in your browser settings at any time. You then lose the remembered theme, the remembered language and the saved return to the project list with your filters kept.

The statement about cookies covers our code and reaches no further. Cloudflare, as the hosting and traffic protection provider, can set technical cookies of its own, for instance __cf_bm for bot protection or cf_clearance for browser verification, when those features are enabled in its dashboard. The full list is in the Cloudflare cookie documentation.

Legal basis and purposes

The processing described above rests on the legitimate interest of the controller, article 6(1)(f) of the GDPR. The purposes map onto the individual elements like this:

  • hosting and traffic protection: delivering the page and defending it against abuse and overload;
  • visit statistics: knowing the scale and origin of traffic, and how the page performs;
  • error reports: finding and fixing breakage in the reader’s browser;
  • feature usage counter: knowing which parts of the database people use;
  • correspondence to the contact address: answering a message, including a correction to the database and a request under the GDPR.

We ask for no marketing consent, because we do no marketing. We build no profiles and take no automated decisions about you.

Providing data is neither a contractual nor a statutory obligation. The IP address and browser headers are technically necessary, being part of every connection: without them the server cannot send a response back. The visit statistics, the error reports and the usage counter are not needed to display the content, so blocking them on your side closes nothing off in the site. Writing to us is voluntary, but without a return address we cannot answer.

How long the data is kept

We keep no store of reader data ourselves. The periods below are set by the providers and come from their documentation rather than from a decision of ours; we also say what their documentation does not establish.

  • Visit statistics (Cloudflare Web Analytics): seven days for unsampled data, after which Cloudflare keeps a sample of around ten per cent for long-term storage. Its documentation gives no final deletion date.
  • Feature usage counter (Cloudflare Workers Analytics Engine): three months, per the documented limits of that service.
  • Error reports (Sentry): thirty days on the free plan and ninety days on paid plans, per the Sentry retention table.
  • Hosting and traffic protection data (Cloudflare): Cloudflare publishes no figure for the plan this site runs on. Security events are visible in the dashboard for the last twenty-four hours, raw request logs are not available on this plan at all, and the internal retention period is described by the Cloudflare privacy policy, which gives criteria instead of durations.
  • Correspondence: we keep it as long as the matter it concerns is open, and messages about GDPR requests for as long as they may be needed to show the request was handled.

We cannot delete a single row from those datasets, because none of them carries an identifier by which the row could be found. What we can do is switch a given measurement off entirely.

Right to object (article 21(1) GDPR)

Because we process data on the basis of a legitimate interest, you have the right to object to that processing. You may do so at any time, on grounds relating to your particular situation.

Send your objection to kontakt@projektometr.pl. We consider it and either stop processing the data it concerns, or demonstrate compelling legitimate grounds which override your rights and freedoms.

A caveat about what an objection can change in practice. We keep no identifiers, so we cannot tell your traffic from anyone else and a measurement cannot be switched off for one person. An objection upheld here means switching a given measurement off altogether, for everyone, or showing why we are not switching it off.

You can switch the feature usage counter off yourself, without writing to us: turn on Do Not Track or Global Privacy Control in your browser. That switch reaches the counter and nothing else. Our code does not tie error reporting to those signals, and what the visit-statistics script does with them is up to Cloudflare rather than up to us. You can stop both on the browser side, by blocking the Sentry and Cloudflare scripts.

Your other rights

To the extent that the data described above can identify you, you have the right to:

  • access to your data and a copy of it (article 15 GDPR);
  • rectification of inaccurate data (article 16 GDPR);
  • erasure of your data (article 17 GDPR);
  • restriction of processing (article 18 GDPR);
  • object to processing (article 21 GDPR), described in the section above.

The right to data portability (article 20 GDPR) is not on that list, and its absence is not an oversight: it applies to processing based on consent or on a contract, and we rely on a legitimate interest.

How far the other rights reach depends on the dataset. The visit statistics, the feature usage counter and the error reports hold no account and no identifier by which one person’s data could be found, and article 11 of the GDPR does not require us to collect extra information solely to make that possible. What can actually be pointed at is correspondence sent to the address above, and that is what a request for access, rectification or erasure covers.

You also have the right to lodge a complaint with a supervisory authority. In Poland that is the President of the Personal Data Protection Office.

Who processes the data

Beyond your own browser, the technical data described above reaches parties who process it on our instructions, on the terms of their own data processing agreements:

Transfers outside the European Economic Area

Both providers are United States companies and part of the processing may happen outside the European Economic Area. The basis for the transfer is the same for both:

  • Cloudflare, Inc. states that it is certified under the EU-U.S. Data Privacy Framework and relies on that certification, falling back on the European Commission standard contractual clauses with supplementary measures should the certification lapse or be invalidated.
  • Functional Software, Inc. states the same: compliance with the Data Privacy Framework, and standard contractual clauses in the module that covers processing carried out on our behalf, should the framework fall away.

The text of the safeguards sits in the data processing agreements of both providers, linked above; the standard clauses are incorporated into them rather than published separately. Data Privacy Framework certification is renewed annually, so its current state is a matter for the programme register, not for this document.

Cloudflare serves traffic from a distributed network, so a request from Poland usually terminates at a node in Europe. We cannot guarantee that for every single request: the tools that force processing into a chosen region are a paid enterprise add-on at Cloudflare and do not cover this site.

Changes to this page

This page describes the state as of the date given at the top. If a new tool arrives or one disappears, a new version of the description replaces the previous one in the same place, without separate notice.