Join UsHire Us

Cookie Policy

Version 1.0.2In force from Ever Technologies LTD

What this policy covers

This Cookie Policy explains the cookies and similar technologies we use on ever.tech and in the Ever Tech website — the public website, the documentation, the signed-in application, and any desktop or mobile application we publish for it. The product-specific section below lists what is actually in use on each of those surfaces.

It sits alongside our Privacy Policy. The two documents answer different questions, and it is worth knowing which one you are reading:

  • This policy is about your device. What we store on it, what we read back from it, why, and how you control that.
  • The Privacy Policy is about the information itself. What we do with personal data once we hold it, the lawful basis for each purpose, who receives it, how long we keep it, and the rights you can exercise over it.

Where something described here involves personal data, the Privacy Policy governs that processing. Nothing in this policy narrows the rights that document gives you.

What this policy does not cover

Other people's sites and services. Our pages link to third-party sites, and our Service connects to third-party tools when you ask it to. Once you are on someone else's site, their cookie notice applies, not ours. We have no control over what they store on your device.

Your own workspace, your own site, your own people. Where you use the Service as a customer to run something of your own — a workspace for your organisation, or a site we provision for you — the pages you publish and the people you invite are yours. This policy is not your cookie notice to your own visitors or personnel, and our banner is not your consent mechanism. Providing those is your responsibility, on your own domain, under your own control.

A copy you run yourself. Where the software behind the Service is published as open source and you run your own deployment, this policy describes the service we operate — not yours. You choose what your deployment loads and what it stores on your users' devices, and only you can describe it to them.

Cookies and the other technologies that behave like them

A cookie is a small text file that a website asks your browser to keep and hands back to a server on later requests. It is the oldest way of doing this, and the best known — but it is only one of several, and the rules that matter here do not turn on which one is used.

The law we work to attaches to storing information on your device or reading information back from it, whatever the mechanism. So wherever this policy says "cookies", read it as covering all of the following.

The technologies

  • Cookies — as above. Set by the site you are visiting, or by another provider whose code runs on the page.
  • Local storage and session storage — key-value storage inside your browser. Larger than a cookie, not sent automatically with every request, and it can hold exactly the same kind of identifier.
  • IndexedDB and the browser cache — structured storage and cached files. Ordinarily used to make pages load faster and to let parts of the Service work offline, but capable of holding an identifier too.
  • Pixels, beacons and tags — a tiny image or a short script whose only job is to load. The act of loading it tells the provider that a page was opened, or an email read, along with your IP address and browser details. A pixel often stores nothing at all and still reports on you.
  • Tracking parameters in links — identifiers added to a URL so that a click can be attributed to the campaign or message that produced it.
  • SDK identifiers in desktop and mobile applications — an installed application has no cookie jar. It stores identifiers in its own application storage instead, and may use identifiers the operating system provides: an advertising identifier, an installation identifier, or a push notification token.
  • Device and network characteristics — your IP address, screen size, language, time zone, fonts and browser version. Individually unremarkable; combined, they can form a fingerprint that recognises a device without storing anything on it.

First-party and third-party

First-party means we set it, on our own domain, and it goes to our servers.

Third-party means it belongs to another company whose code we have chosen to run on the page — an analytics provider, an embedded video player, a bot-protection service. Their technology reports to them, not to us, and they decide what it does. Note the awkward part plainly: a third-party resource embedded in our page discloses your IP address, your browser and the page you were on to that provider, even when it stores nothing on your device at all. Loading it is the disclosure.

Some third-party technologies are deliberately set up to look first-party — served from a subdomain of ours, or routed through our own servers. Where we do that, we say so in the table below rather than letting the appearance stand.

Session and persistent

Session items are discarded when you close the browser or the application. They are typically what keeps you signed in and moving through a single visit.

Persistent items survive until they expire or you delete them, which is what lets us recognise a returning visitor, remember your preferences, or remember that you refused something. Each entry in the table below states how long it lasts.

Why we use them

There are six reasons, and each one maps to one of the categories in the next section. We have written the category next to each so you can see immediately which ones you control.

  • To sign you in and keep you signed in. Your session has to be attached to the right account, the right workspace and the right organisation as you move between pages, and it has to be protected against being replayed or forged by someone else. → strictly necessary
  • To keep the Service secure. Telling a person apart from an abusive script, protecting forms against automated submission, enforcing rate limits, and detecting fraudulent sign-ups and payments. → strictly necessary
  • To make the Service work at all. Routing your request to a healthy server, keeping you on the same one where a feature requires it, balancing load, and serving the right version of the application. → strictly necessary
  • To remember what you decided about cookies. Your choice has to be stored somewhere, or we would have to ask you on every page. → strictly necessary
  • To remember your preferences. Language, time zone, theme, layout, a panel you collapsed, a message you dismissed, and whether you want the support widget open. → functional
  • To understand how the Service is used. Which pages and features people actually use, which paths fail, and where things are slow — so that we improve the right things rather than the ones we happen to notice. → analytics
  • To measure our marketing. Whether a campaign reached anyone, which content leads to sign-ups, and which organisations show interest in the product. → marketing

Two things follow from that list, and we would rather state them than leave them implied.

Only the first four are needed for the Service to function. Everything in the last three groups is optional. If you refuse all of it, every feature you are entitled to still works, at the same price.

Where we can achieve a purpose without storing anything on your device, we do. That is the whole reason our own analytics is built the way it is — see the section on analytics without consent below.

The four categories we use

Every entry in the table below belongs to exactly one of these four categories. The banner and the preference centre use the same four names, so what you agree to and what this policy describes are the same thing.

These are the ones we set because you asked for a service that cannot be delivered otherwise. They are not optional, they are not used for analytics or marketing, and there is no switch for them in the preference centre. If you block them at the browser level, parts of the Service will stop working.

  • Session and authentication — signing you in, keeping you signed in, refreshing your session, and binding it to the correct account, workspace and organisation.
  • Security — protection against cross-site request forgery, detection of abusive automated traffic, rate limiting, and fraud prevention on sign-up and payment.
  • Load balancing and routing — sending your request to a healthy server and keeping you there where a feature needs it.
  • Your consent choice — storing what you decided, so that we can honour it and stop asking.

Error and crash diagnostics are not in this category by default. Where we use a diagnostics tool that records more than a technical error — a reconstruction of what was on your screen, for example — it is listed under analytics and it waits for your consent.

reCAPTCHA is in this category, and here is our reasoning

We use Google reCAPTCHA — and on some surfaces an alternative provider, named in the table below — to stop automated abuse of forms such as sign-up, password reset and contact. We treat it as strictly necessary, which means it loads without asking you first.

The reason is that it protects the specific form you are trying to use. You cannot meaningfully ask for the form and refuse the protection on it: without it, those endpoints are abused within hours, which is a security failure that harms you as much as us.

What that means in practice, stated plainly:

  • It collects device and behaviour signals from your browser — mouse and touch movement, timing, browser and device characteristics, and your IP address — and sends them to Google, which acts as its own controller for that data under its own privacy notice.
  • We load it only on pages carrying a protected form. It is not present across the whole site.
  • Where an equivalent provider is available on a surface, we prefer the one that collects less.

Not every data protection authority accepts that a bot-protection service belongs in the strictly necessary category. We think it does, for the reason above, and we would rather publish the reasoning and let you judge it than bury the tool in a list. If you would prefer not to submit a form protected this way, write to [email protected] and we will take it from you another way.

These remember choices you have made so that the Service behaves the way you left it: language, time zone, theme, layout, dismissed messages, and support or chat widgets where we offer them.

Refusing this category costs you convenience, not access. Everything still works; it simply forgets your preferences between visits and you set them again.

These tell us how the Service is used: which pages and features are used, which paths people abandon, what is slow, and what fails. Depending on the surface this may include a provider's own persistent identifier and, where the table says so, a masked reconstruction of a session.

Third-party analytics tools are off until you turn them on, and nothing in this category loads before you choose.

There is one deliberate exception, and it is the subject of the next section: our own analytics, running on our own servers, is designed to operate without a consent requirement — cookieless, with no persistent identifier and aggregate reporting only. The next section sets out exactly what that involves and the conditions it depends on.

These measure whether our marketing works and help us understand who is interested in the product: attribution of a sign-up to the campaign that produced it, and business-audience identification tools.

One of these deserves a plain sentence rather than a euphemism. Visitor identification tools resolve a visitor's IP address to the organisation it belongs to, so that we can see which companies have looked at the product. They do not tell us your name, but most people do not expect a website to work out their employer, so we would rather say it here than let you find it in a table. It is off unless you consent.

We do not use cookie walls, and we never make access conditional on consenting to non-essential cookies.

You can refuse everything except the strictly necessary category and the whole of the Service remains available to you — the same features, the same content, the same price. We do not offer a "consent or pay" alternative. We do not degrade the experience, hide content, or nag you on every page because you said no. Refusing is a decision we record and respect, not a negotiating position.

Ever Tech: what runs on this site

We run no analytics of our own on ever.tech. The arrangement described in the core policy — our own cookieless measurement, on our own servers, exempt from consent — does not exist here. Everything that measures this site is a third-party product, and every one of them waits for your answer to the banner.

There is one surface. No account, no signed-in application, no desktop or mobile app for this product — so the table below is the whole of it.

Technology Provider Category What it does How long it lasts
Consent record (cg_consent) Us — first-party, stored on your device only Strictly necessary Stores what you chose in the banner so we can honour it and stop asking Up to 12 months, or until you clear it
Edge and bot protection (__cf_bm and related) Cloudflare, Inc., United States — notice Strictly necessary Separates automated traffic from people and keeps your connection on a healthy server Around 30 minutes per visit
reCAPTCHA (_GRECAPTCHA) Google, United States — notice Strictly necessary Protects the contact, hire-us, careers, application and newsletter forms. Loads only on pages carrying one of them. Google acts in its own right for what it collects About 6 months
Google Analytics 4 (_ga, _ga_*), delivered through Google Tag Manager Google, Ireland and United States — notice Analytics — consent required Counts pages and visits and shows us which pages people leave. Tag Manager is a container, so further tags can be added to it without changing the site Up to 2 years
PostHog (ph_*_posthog) PostHog, Inc., United States — notice Analytics — consent required Product analytics for the site: page views, page-leaves and navigation paths About 1 year
Error reporting and session replay Functional Software, Inc. d/b/a Sentry, United States — notice Analytics — consent required Reports a page that failed and, separately, replays a masked reconstruction of the visit. It sets no cookie, but what it sends carries your IP address and the page you were on Nothing stored on your device
Web analytics component Vercel Inc., United States — notice Analytics — consent required Compiled into the site but inert: its beacon endpoint exists only on that provider's own hosting platform, and this site runs on ours, so nothing is sent to it Nothing stored on your device
Business visitor identification Dealfront Group GmbH (Leadfeeder), Germany — notice Marketing — consent required Resolves your IP address to the organisation it belongs to and reports the pages you read, so our team knows which companies looked at our services Up to 2 years
Support chat widget Chatwoot Inc., United States — notice Functional — consent required Runs the chat bubble and remembers your conversation so it survives a page change For as long as the conversation is kept in your browser
Light or dark theme First party, in your browser's local storage Preferences — consent required Remembers the appearance you chose Until you clear your browser storage

Business visitor identification deserves naming rather than burying. It does not tell us who you are. It tells us which organisation your connection belongs to and what that organisation read, which is more than most people expect a services website to work out. It sits in the marketing category, it is off until you say otherwise, and refusing it sends nothing.

Session replay, since it is more than error reporting

Roughly one visit in ten, chosen at random, and every visit in which an error occurs, is reconstructed for us to play back afterwards — the structure of the page, what moved, what you clicked and in what order. All text is masked and all media is blocked, so what we see is the shape of the visit and not the words in it. It is in the analytics category. Refuse that category and nothing is captured, including on the application form.

What this site does not do, though you might reasonably assume otherwise

  • No advertising, no advertising pixel and no cross-site tracking. Nothing here follows you onto another site, and no advertising network receives anything from this one.
  • Fonts are compiled into the site when it is built and served from our own domain. Reading a page does not fetch a typeface from anyone.
  • There is no cookie for your language. The language you are reading is part of the address of the page, so nothing has to be stored to remember it.
  • The content management system behind this site is for our own editors and is not reachable from these pages. Its cookies are for the people who write the site, not for the people who read it.

Changing your mind

The preference centre is reachable from the footer of every page on https://ever.tech. Withdrawing consent is as easy as giving it, and it takes effect immediately for anything not already loaded. If you find something in the consent-required rows above running before you have chosen, that is a defect and not a policy position — tell us at [email protected] and we will fix it.

Third-party cookies and the providers behind them

Some of what runs on our pages belongs to other companies. We chose to include it, so we tell you it is there — but the provider decides what its own technology collects, and for that collection it is usually acting in its own right and under its own privacy notice rather than ours. Where that is the case, the table below links to their notice.

These are the kinds of provider involved, and what each kind does.

Analytics providers

Measure how the Service is used: page views, feature use, funnels, errors and performance. Most set a persistent identifier of their own so a returning visitor is recognised, and some can record a session replay — a reconstructed, masked playback of what happened on the screen. Where a tool on a surface can do that, the table says so explicitly.

Consent required. They do not load until you agree.

Tag management

A tag manager is a container we load once, through which other tags can then be delivered without shipping new code. That flexibility is exactly what makes it worth describing carefully: a container is a delivery mechanism, so what it delivers matters more than the container itself.

Every tag we deliver through a container is declared in the table below, in its own category. The container is consent-gated as a whole, and we do not use it to deliver anything from a category you have refused.

Consent required.

Marketing and visitor identification

Campaign measurement and attribution — which advertisement, email or article led to a visit or a sign-up — and business-audience identification, which resolves a visitor's IP address to the organisation that holds it so we can see which companies are interested in the product. It gives us a company, not your name. Most people still do not expect it, which is why it is named here as well as in the table.

Consent required.

Video, maps, fonts and other embedded content

Where a page embeds something served from another provider's network — a video player, a map, a code sandbox, a font, a script from a public content delivery network — your browser fetches it directly from that provider.

That fetch discloses your IP address, your browser and the page you were on to the provider, whether or not anything is stored on your device. There is no way to embed a resource and hide the request for it.

We handle this in two ways: where we can serve the asset ourselves, we do, which removes the third party entirely; and where an embed stores or reads anything on your device, we treat it as consent required and it does not load until you agree. Embeds that store nothing but are still fetched from a third party are listed in the table so you can see the disclosure even where no cookie is involved.

Security and delivery

The network in front of our sites — the proxy and content delivery layer that terminates the connection, absorbs attacks and filters hostile traffic — along with bot protection on forms and fraud checks on payment. These see connection metadata and may set their own security cookies.

Strictly necessary, and therefore not consent-gated. Our reasoning for putting bot protection in that category, including what it sends to its provider, is set out in the categories section above.

Measurement injected by that layer, which our banner cannot control

There is one thing here we would rather state plainly than have you discover in a network trace. Our content delivery provider injects its own lightweight measurement script at the edge — into the response, after it leaves our servers. It is not in our code, our consent system never sees it, and switching a category off in our preference centre does not stop it, because by the time the page reaches you the script is already part of it.

What it is: a page-view beacon operated by that provider. It sets no cookie, creates no persistent identifier of you, and reports aggregate traffic. It is not used for advertising and it is not joined to anything else we hold.

What it is not: covered by the exemption we claim for our own analytics. That argument rests on the data staying on our own infrastructure, and this is a third party receiving it. We are not going to stretch the same reasoning over both.

If you would rather it did not run, a content blocker or a network-level block stops it, and we do not attempt to detect or defeat that. You can also write to [email protected] and we will tell you the current provider and exactly what it collects.

Where these providers are, and where to find the full list

Some of these providers are established outside the European Economic Area, and using them involves an international transfer of personal data. The transfers section of our Privacy Policy sets out the destinations and the safeguards we rely on for each, and you can ask us for a copy of those safeguards.

Two lists keep this current, and between them they are the authoritative answer:

  • The table in the product-specific section below names every cookie and similar technology in use on this product's surfaces — the provider, whether it is first- or third-party, its category, its purpose, how long it lasts, and a link to the provider's own notice.
  • Our Sub-processor List covers the wider set of providers that process personal data for us, including the many that never touch your device at all. You can obtain the current version at any time from [email protected], and it names the sub-processor, what it does, and where it processes.

We update both when a provider is added, removed or changed. If you find something on our pages that is not in either list, tell us at [email protected] — that is a defect and we will fix it.

How the banner works

On your first visit we show a consent banner, and nothing in the functional, analytics or marketing categories is written to or read from your device until you have made a choice. The strictly necessary items load, because the page cannot be delivered otherwise. Everything else waits.

The first layer of the banner — the one you see without clicking anything further — carries both a Reject all and an Accept all control, presented with equal prominence. Refusing everything takes one click, exactly like accepting everything. Alongside them is a route into per-category choice, so you can accept analytics and refuse marketing, or any other combination.

Three things that some banners do and ours does not:

  • No pre-ticked boxes. Every category except strictly necessary starts switched off.
  • Closing the banner is not consent. Neither is dismissing it, scrolling past it, or carrying on browsing. If you do not make a choice, nothing optional is set — you simply have not decided yet.
  • No dark patterns. We do not make the reject control smaller, greyer, slower or harder to find than the accept control, and we do not hide it a layer down.

Changing your mind

Withdrawing consent is as easy as giving it, and you can do it at any time.

There is a persistent Cookie preferences link in the footer of every page, and an equivalent entry inside the application's settings. It opens the same per-category controls you saw in the banner, showing what you currently allow. Change a switch and it takes effect immediately: we stop, and where we can, we remove what was stored.

Two honest limits on that:

  • Withdrawal works forwards, not backwards. It does not make lawful past processing unlawful, and it does not reach into data a third-party provider already received. If you want that deleted too, ask us at [email protected] and we will tell you who holds it and how to ask them.
  • Your choice is stored on the device and browser you made it on. A different browser, a different device or a private window will ask again, because there is nothing there to read. Clearing your browser storage deletes the record of your refusal as well, which is why the banner reappears afterwards.

The record we keep

When you make a choice we record what you chose, when you chose it, which categories it covered, and which version of this policy was in force at the time. That record exists for two reasons: so that we honour your choice, and so that we can show what you were asked and what you answered.

You can ask us for a copy of your own consent record at [email protected].

How long a choice lasts before we ask again

We store a consent choice for six months. After that the banner appears again so you can confirm or change it. We will also ask again sooner if we add a purpose or a category your earlier choice did not cover, or if this policy changes in a way that materially affects what you agreed to.

This is our own practice, not a legal requirement. There is no EU-wide statutory interval for asking again — six months follows regulator guidance we consider sensible and proportionate, and we have chosen to apply it. If you would rather not be asked at all, refusing everything is a decision we keep for the same six months, and blocking storage at the browser level stops the question permanently.

Controls in your browser and on your device

Our banner is not the only way to control this, and it is not the strongest one. Your browser and your operating system can enforce a choice on every site at once, including ours.

In a browser

Every major browser — Chrome, Firefox, Safari, Edge and the rest — offers the same set of controls, under privacy or site settings:

  • Delete cookies and site data, for one site or all of them.
  • Block cookies, either all of them or only those set by third parties.
  • Clear storage on exit, so nothing survives the session.
  • Private or incognito windows, which discard everything when the window closes.
  • Per-site permissions, so you can allow storage on the sites you use and block it everywhere else.

Your browser's own help pages describe exactly where these live in your version — we deliberately do not reproduce click-by-click instructions here, because they go stale faster than this document does.

Content blockers and privacy extensions work on our sites too. Using one is a legitimate choice, and we build the Service so that it keeps working when the optional things are blocked.

In our desktop and mobile applications

An installed application has no browser settings to change, so the controls are at the operating-system level instead:

  • Reset or limit the advertising identifier your device provides.
  • Answer no to the app-tracking permission prompt on iOS, which stops access to that identifier entirely.
  • Withdraw notification permission, which stops the push token being useful.
  • Clear the application's stored data, or uninstall it, which removes everything it kept locally.

The Cookie preferences controls described above are also available inside the application, and they govern the same categories there as on the website.

What breaks if you block the strictly necessary ones

Blocking the optional categories breaks nothing. Blocking storage entirely does, and you should know what to expect:

  • You will not be able to sign in, or stay signed in. Authentication needs somewhere to keep the session.
  • Forms may fail their security check and refuse to submit.
  • Some features will behave inconsistently, because requests can no longer be kept on the same server.
  • We cannot remember that you refused. The record of your choice is itself stored on your device, so blocking storage means the banner returns on every visit — the one genuinely irritating consequence, and it comes from the mechanism rather than from us being difficult.

Do Not Track

Browsers once offered a Do Not Track header, and some still do. We do not treat it, on its own, as a refusal — and we would rather explain why than quietly ignore it.

No consistent standard was ever agreed for what a site should do on receiving it. It was never clear whether it expressed a considered decision or a default someone else had set, browsers behaved differently, and several have withdrawn it. A signal we cannot interpret is not a safe basis for deciding what you want.

Use the banner or the preference centre instead. A choice made there is unambiguous, and we record it.

Global Privacy Control

Global Privacy Control (GPC) is the later, better-specified signal, and unlike Do Not Track it is defined to express an actual opt-out rather than a preference.

Where we receive a GPC signal from your browser, we treat it as a refusal of the analytics and marketing categories on that browser, and we act on it without waiting for you to interact with a banner.

Two points of detail:

  • It applies to the browser or device sending it. Another browser sends its own signal, or none.
  • An explicit choice you make later in our preference centre takes precedence, in either direction. If you switch a category on there while GPC is enabled, we treat that as your decision, and we record it as such. If you would rather that never happened, leave the categories switched off.

Changes to this policy

We update this policy when what we do changes — a provider added or removed, a technology retired, a category reassigned. Every update gets its own version number and effective date, recorded at the end of this document.

Where a change materially affects what you agreed to — a new purpose, a new category, or a tool moving out of the strictly necessary or exempt group — we ask for your consent again rather than relying on the choice you made against the old text. Corrections, clarifications and provider renames are published with a new version and no fresh request.

Earlier versions stay available, with the dates each was in force, at https://ever.tech/cookies. The effective date shown with this policy tells you which version applies today.

How to reach us

Questions about this policy, about anything in the table above, or about a choice you have made — write to [email protected]. That address is monitored and we answer it. Ask us for a copy of your own consent record, for the current sub-processor list, or to be excluded from our own analytics, and we will do it without asking why.

By post: Ever Technologies LTD, Mladost 2, bl. 211, ent. A, Sofia 1799, Bulgaria — registered in Bulgaria under company number 204599535. We correspond in English.

If you think we have handled your data badly, tell us first — we would rather fix it. You can also complain to a data protection supervisory authority at any time. Ours is the Commission for Personal Data Protection (Комисия за защита на личните данни), the CPDP, at https://www.cpdp.bg/. You may instead complain to the authority for the country where you live or work.

This document is version 1.0.2 of the Cookie Policy for ever.tech, in force from 2026-08-02. Earlier versions, with the dates they applied, are at https://ever.tech/cookies.