Cookies and browser storage

1. In short

This website sets no cookies of its own and runs no tracking of any kind. It keeps a short list of things in your browser: the theme you chose, the searches, filters and car parks you have looked at or saved, a note of the bookings this tab has just confirmed or reviewed, and — only while a card payment is in flight — the email address from your booking. None of it measures anything, and none of it ever leaves your browser. The one page that takes a card also loads the payment processor’s script, which sets cookies of Stripe’s own to keep fraud out; section 2 itemises all of it. There is still no consent banner: nothing here is measurement, nothing here is shared with anyone, and the lists in section 2 can be cleared from the page they appear on. Section 3 gives the reasoning in full.

2. What this site actually stores

A short list of values, all of them written by this site’s own code and readable by no other site. In detail:

• Your theme choice. Press the light-or-dark toggle in the header and the word “light” or “dark” is kept in local storage under the name “parkena-theme”, so the next page — and the next visit — opens in the theme you chose. It stays until you press the toggle again or clear this site’s data, it identifies nobody, and it is never transmitted anywhere.
• During a card payment, the email address from your booking form, in session storage, under “parkena:book:pay-email:” followed by the booking reference. Paying can route you through your bank’s approval page and back, and the return trip must not carry your email address in the web address, where it would sit in your browser history and in access logs along the way. So the address waits in your browser instead, is removed when the payment completes, and dies with the tab in any case. Before that, from the moment you first press Reserve, the same tab keeps a random booking code for each stay you are booking, in session storage, under “parkena:book:request-key:” followed by the car park and the dates. It is what makes pressing Reserve again — after a double-click, a lost connection, a changed price or a reload — bring back the same booking rather than a second one, and what stops anyone else who knows your details from being handed your booking. It holds nothing about you, it is sent nowhere except with your own booking request, it never appears in a web address, and it dies with the tab.
• The searches, filters and car parks you have looked at, so the site can hand them back on your next visit. Four names in local storage: “parkena-recent-searches” holds your last five airport-and-date searches, “parkena-viewed-lots” the last five car parks you opened, “parkena-saved-lots” up to twenty you saved yourself, and “parkena-filters:” followed by an airport’s own name holds the filters you set on that airport’s results — the facilities, the handover and the highest total you wanted — until you press Clear filters. Each of them holds only what its card or its filter row already shows you: an airport, your dates, a car park’s name and operator, the total you were shown, a facility you ticked. Nothing in any of them identifies you and none of it is ever sent anywhere. Every card in the three lists carries a button that deletes it, and an entry leaves its list by itself once its drop-off date has passed — the drop-off, not the pick-up, so an entry goes while the stay it remembers is still running. The site prunes it the next time the list is read.
• Two short memos a tab keeps about bookings you have just handled, both in session storage and both gone the moment you close the tab. “parkena:reviewed” lists up to twenty references of bookings you have posted a review for in this tab, so the review form is not offered again for a stay you have already written about. “parkena:book:confirmed:” followed by a booking reference marks a confirmation screen this tab has already seen, so that reloading it cannot count the same booking twice — and, as this list says below, there is nowhere on this site for such a count to go. Both hold booking references and nothing else, neither identifies you, and neither is ever sent anywhere.
• A ten-minute note, in session storage under “parkena-coverage-v1”, of how many car parks were found at each airport while you have been looking — and whether that count ran to the end — so that moving from one page to the next does not ask the same question over and over. It holds each airport’s own name, a number for each, and the time the count was taken; it identifies nobody, is never sent anywhere, and dies with the tab.
• Beyond those, nothing: no cookies set by this site — not for preferences, not for sessions, not for measurement — no service worker, no analytics, no tag manager, no measurement pixel, no A/B testing tool, no heatmap, no session recording.
• No advertising or attribution identifiers, and no fingerprinting.
• No embedded map, video, font service, social widget or comment system. Every font the pages load is served from this domain, and so is every script but one — the payment page loads Stripe’s, described below. So is every image, except the photographs operators upload of their car parks, which come from the database host described below.

The site talks to two other hosts. When you search for parking or make a booking, your browser asks the database for prices and writes the booking; those requests carry no cookie and set none. The photographs operators upload of their car parks are loaded from that same host. And on the booking page alone, the card form is Stripe’s: the page loads Stripe’s script, your card details go into that form and travel to Stripe directly, and Stripe sets its own cookies as part of telling real cards from fraud. Those cookies are Stripe’s, exist only so the payment you asked for can happen, and are the reason a payment provider appears on this page at all. Everything else is a static file.

3. Why there is no cookie banner

European rules require your permission before anything that is not strictly necessary is stored on or read from your device. The theme is a preference you set yourself, by pressing a button whose whole purpose is to be remembered. The stashed email address is what lets the payment you started finish, and the booking code is what keeps one press of Reserve one booking. Stripe’s cookies are what let a card be taken at all — fraud prevention is not an extra on a payment, it is the condition of one. The lists and filters in section 2 are the one thing here that is a convenience rather than a necessity, and this page will not pretend otherwise: they are written by your own searching, filtering and saving, they are shown to nobody but you, each of them can be cleared where it appears, and clearing this site’s data removes the lot at once.

A banner would still be easy to add, and adding one would be worse than useless. A consent request that asks nothing teaches people to dismiss consent requests, including the ones that matter on other sites. So there is no banner, and this page is here in its place.

4. What the site does to keep it that way

The pages are served with a small set of instructions to your browser, and they are in the repository as a plain text file rather than in someone’s configuration panel:

• Geolocation, microphone and camera are switched off for the whole site by policy. The site cannot ask for your location even if some future script tried to.
• The site refuses to be displayed inside a frame on another site.
• Referrer information sent to other origins is trimmed to the bare origin, and never sent at all when leaving HTTPS.
• Browsers are told to reach this site only over HTTPS.

5. What the layer underneath may set

The application sets nothing; the network in front of it is a separate question that this repository cannot answer on its own. The site is served through Cloudflare, and Cloudflare can set strictly necessary security cookies — bot and abuse protection — depending on how the account is configured. That configuration is not part of the code, so this page does not pretend to know its state.

[ TO BE COMPLETED BEFORE LAUNCH — confirm which cookies, if any, the hosting layer sets in production, and either list them here by name and purpose or switch them off ]

You do not have to take any of this on trust, and it is a good habit not to: open your browser’s developer tools, look at the storage or application tab, and see the list for yourself. On this site it should show exactly what section 2 lists — the theme word, the lists and filters once you have searched or saved something, the payment email while one is in flight, a booking code for each stay you have pressed Reserve on, the two booking memos once this tab has confirmed or reviewed a booking, the ten-minute coverage note once a page has counted what is listed at an airport, Stripe’s cookies if you have reached the payment step of a booking — and nothing else, apart from anything the hosting layer added.

6. The operator console is different

Operators sign in to a separate application on its own address. It has to remember that you are signed in, so it keeps a session token and the operator you last worked in inside your browser’s local storage. That is strictly necessary — without it every page you open would ask you to sign in again — and it is not measurement of any kind. While you take up an invitation to join an operator, the tab you opened the invitation link in also keeps that invitation — its code and the address it was sent to — in session storage under “parkena.pendingInvitation”, so that creating your login or signing in does not lose it. It is removed as soon as the invitation is used or turns out to be dead, and dies with the tab in any case. And when Stripe sends you back to the console because a link for setting up payouts had expired, the tab notes the moment it opened a fresh one, under “parkena:stripe-link-renewed-at” in session storage, so that it opens a fresh link by itself only once instead of bouncing you between the two sites; it holds that time and nothing else, and it too dies with the tab. When you go from the setup wizard to Stripe to set up payouts, the tab also notes which car park you were setting up — its identifier, or that it was a new one — under “parkena:stripe-return-lot” in session storage, so that coming back from Stripe reopens that car park and not another; it holds that and nothing else, is removed as soon as the wizard has read it on your way back, and dies with the tab in any case.

Signing out removes the session token and the operator; clearing the site’s data in your browser removes all of it. The session-storage entries also go when you close the tab — the invitation sooner still, as soon as it is used or turns out to be dead.

7. What would change this

The list below is what would change this page. It is here so that whoever makes one of these decisions finds the sentence they are about to make untrue:

• Adding analytics of any kind, including a self-hosted one that stores anything on the device.
• Embedding a map, a video player or a review widget from another company.
• A second payment provider beside Stripe, or Stripe coming to store more than the fraud-check cookies described above.
• Giving travellers accounts, which requires a session.
• Remembering anything across visits beyond what section 2 lists: a language, a currency, a dismissed notice.
• Any advertising, retargeting or attribution measurement.

If one of them ships, this page is updated before it does, and anything that is not strictly necessary arrives with a real consent request — one where refusing is exactly as easy as accepting, and where nothing is stored until you have chosen.

8. Related

The privacy notice covers the details you type into a booking — what is collected, who receives it and how long it is kept. This page is only about your device.

Privacy notice →