Cookies

Last updated 28 August 2026

This page lists every cookie UnivMenu sets, what each one is for and how long it lasts. There are five, they are all strictly necessary to do something you asked for, and there are no others. It covers every country we operate in: none of them needs a different answer.

The short version

Five cookies, all strictly necessary. One keeps you logged in, three remember a choice you made on purpose, and one ties a sign-in to the browser that started it.
There are no advertising cookies, no analytics cookies and no third-party cookies anywhere on UnivMenu — including on a published menu, which sets none at all.
There is no cookie banner, and none is required. A banner asks consent for cookies that are not necessary. We do not set any.
The cookies are set by the owner portal at portal.univmenu.com. The marketing site you are reading now writes none.
You can delete or block all of them in your browser. The only thing that breaks is staying logged in.

Every cookie we set

sid — your session. Written when you log in, so the portal knows the next page is still you. Deleted when you log out, and it expires on its own after 30 days. It cannot be read by JavaScript.
lang — the language you chose. Written only when you pick a language yourself, so the site does not ask twice. A guess never writes it. Lasts a year.
country — the country you chose. The same rule, on a price, rewards or menu-creation page: only an explicit choice writes it, and it always beats what we would otherwise guess. Lasts a year.
oidcb — the sign-in binder. Written for ten minutes when you start a sign-in with Google or another provider, and destroyed the moment you come back. It exists so that the sign-in that returns is the one this browser started, and it is what stops somebody else finishing it. It cannot be read by JavaScript.
kds_view — which screen a kitchen tablet is on. Written when a cook picks a view, so that the tablet by the pass opens on the same screen tomorrow. It is a setting of one piece of glass, not of a person. Lasts a year.

Full detail — why each one is necessary

A cookie is strictly necessary when the thing you asked for cannot be done without it. sid is the clearest case: HTTP does not remember who you are between two pages, so a logged-in service either sets a session cookie or asks for the password again on every screen. It is written only after a successful log-in, it is marked HttpOnly and SameSite=Lax so that neither a script on the page nor another site can reach it, and it is destroyed when you log out.

oidcb is the same argument at a smaller scale. A sign-in with an outside provider leaves our site and comes back; the cookie is the only thing that proves the browser coming back is the one that left. It holds a random value, nothing about you, lives for ten minutes and is deleted as soon as the sign-in finishes or fails.

lang, country and kds_view record a choice you made deliberately, which is what makes them necessary rather than convenient: without them the choice would not survive the next page, and you would be asked again every time. None of them is written unless you choose. None of them identifies you, none is shared, and each can be changed by choosing again.

None of the five is used to build a profile, to measure you, to advertise, or to follow you to another site. No outside party can read any of them: they are first-party cookies, and no third-party script runs on our pages.

Where you are, and why that is not a cookie

Prices and rewards differ by country, so a page that shows them has to know which country your request came from before it can pick which figures to print.
It asks our own server, which looks the address up in a table on our own infrastructure. No outside service ever sees your address.
The answer is country-level only — a country, never a city, a street or a person — and it is not stored. It picks the page and is forgotten.
A country you choose yourself always overrides it, and that choice is the country cookie above.

What a published menu does

A menu page is a static file. It sets no cookie at all, loads nothing from anybody else, and carries no advertising or analytics code.
It makes one request, and it is to us: it asks our own server which dishes the kitchen has marked unavailable, so a sold-out dish can be greyed out. No cookie and nothing about the reader goes with it, and if the answer does not arrive the page carries on unchanged. Our server records that request in its ordinary logs, including the address it came from, for seven days. The privacy policy says the same thing at greater length.
A guest reading a menu needs no account and is asked for nothing.
The dietary and allergy filters a guest taps stay inside that guest's own browser. They are never sent anywhere, so they never reach us.
An order a guest builds travels in the code the waiter scans. It does not pass through our servers.

Controlling them

Every browser can show you the cookies a site has set, delete them, and refuse new ones. That control is real, it is yours, and it does not depend on us offering you a second one.
If you delete or block ours, the site keeps working — you will simply be logged out, and the language, country and kitchen-view choices will be asked again.
There is no banner to dismiss, because there is nothing here to consent to.

If this ever changes

If we ever set a cookie that is not strictly necessary — an analytics cookie, say — we would ask you first, before it was set, and you would be able to say no and carry on using the service.
This page would be updated before that happened, not after.
Questions: hello@univmenu.com.

Privacy → · Terms of service → · Refunds →