Find JobsCompanies

Openings from employers hiring right now — search, save and apply with one profile.

Job seekers

Browse jobsSaved jobsMy applicationsMy profile

Employers

Employer loginPost a job

Company

HomeAll openingsPrivacy PolicyTerms of UseCookie Policy

© 2026 Grasshire · Careers · Every opening here is posted by the employer named on it.

Legal

  • Privacy Policy
  • Terms of Use
  • Cookie Policy

On this page

  1. 1What This Policy Covers
  2. 2Cookies
  3. 3Local and Session Storage
  4. 4What We Do Not Use
  5. 5Shared Job Links
  6. 6The One Thing We Ask You
  7. 7Third-Party Requests From This Site
  8. 8Managing These, and Questions

Legal

Cookie Policy

Every cookie and browser-storage entry the Grasshire Platform creates, what each one does, and the one thing we ask your permission for. This is the complete list, not a representative sample.

Effective 22 September 2026 · Version 1.0

Read the Privacy Policy

For what we do with your data generally, and how to make a privacy request.

Contents
  • Privacy Policy
  • Terms of Use
  • Cookie Policy
  1. 1What This Policy Covers
  2. 2Cookies
  3. 3Local and Session Storage
  4. 4What We Do Not Use
  5. 5Shared Job Links
  6. 6The One Thing We Ask You
  7. 7Third-Party Requests From This Site
  8. 8Managing These, and Questions

At a glance

  • Two cookies. One keeps you signed in, one blocks cross-site request forgery. Both are strictly necessary; you can browse jobs without either.
  • No advertising, no tracking pixels, no fingerprinting, no session recording. The one thing we measure is how many people opened a job, and you can decline it.
  • Your session records no IP address and no user-agent — unlike the employer portal, which records both for its own users.
  • Three third parties are contacted, all Google: Fonts on every page load, the sign-in library once you log in, and reCAPTCHA on the four sign-in pages only — never while you browse jobs.

1What This Policy Covers

This covers the Grasshire Platform — this site, where you search jobs, hold an account and apply. It lists every cookie the site sets and every value it stores in your browser.

The employer portal has its own cookie policy, and the two lists genuinely differ. The difference that matters to you is in §2: this site records no IP address and no user-agent against your session, while the employer portal records both for its own users. Nothing on the candidate side captures an IP address at all — not the session, not your consent record, not the share-link view counter.

We use the word “cookie” loosely here, as most people do, to mean anything the site stores in your browser. The tables are precise about which mechanism each entry uses, because they behave differently — a cookie is sent to our server on every request, while local and session storage never leave your device.

2Cookies

Two, both strictly necessary, and neither is set until you sign in. Browsing and searching jobs sets no cookie at all.

NamePurposeLifetime
gh_cand_sessionYour signed-in session. It holds a signed token our server issues after your identity provider has verified you once, and it is what authenticates every later request. It is HttpOnly — JavaScript cannot read it, which is what limits the damage a cross-site scripting bug could do. In production it is also Secure, SameSite=None and Partitioned.15 minutes, renewed silently while you are active
gh_csrfCross-site request forgery protection. Unlike the session cookie this one is deliberately readable by the site’s own code, which echoes its value back in a header on every state-changing request; the server checks that the two match. A forged request from another site can carry your cookie but cannot read it, so it cannot produce the header.7 days

Neither cookie identifies you to anyone but us, and neither carries an IP address or anything about your device. They are first-party, they are not shared, and no third party can read them. The token inside is signed with a key belonging to this service alone — your session here cannot authenticate a request on an employer’s portal, and theirs cannot authenticate one here.

Blocking these two prevents you signing in, which means you cannot save a job, apply, book an interview or respond to an offer. Job search itself still works.

3Local and Session Storage

These live in your browser and are never sent to our servers. Clearing them loses a preference and nothing else.

KeyMechanismWhat it remembers
ros-themeLocal storageYour Light, Dark or System theme choice. Read before the first paint, which is why the site does not flash white on load.
ros-csrf-tokenLocal storageA copy of the CSRF token above, for deployments where the cookie cannot be read across sites. Not a login credential — on its own it authenticates nothing.
ros-analytics-consentLocal storageYour answer to the analytics question in §6 — yes or no, and which version of this policy you were shown. This one is how we remember not to ask you again, and it is the only reason the next two entries may or may not exist.
ros-visitor-idLocal storageA random number identifying this browser, so a job you open twice is not counted as two people. Only written if you said yes, and deleted the moment you change your mind. It is not built from your name, email, phone or account — it is not connected to who you are, and it is the only entry on this page you are asked about.
ros-application-draftsLocal storageWhich jobs you have an unfinished application for, so the Drafts tab can find them — the job id, its title and when you last saved, for at most 25 jobs. Not your answers: those stay on our servers, and this list is only used to ask for them. It is per-browser, which is why a draft saved on your phone does not appear on your laptop, and kept separately for each account that signs in on that browser, stored under this name followed by your internal account ID.
ros-view-sessionSession storageA random number for this browser tab, sent with the same view signal. Only written if you said yes, and gone when you close the tab.

Firebase Authentication’s own storage

When you sign in, Google’s Firebase Authentication library stores its own session state in IndexedDB and local storage so you are not asked to sign in again on every visit. We do not read or write it ourselves, and its contents are Google’s format rather than ours.

This exists here and not on the employer portal, because this is the only side that still runs Google’s sign-in library in your browser. On the employer side, credentials go to their server instead. It is cleared by signing out, or by clearing site data.

4What We Do Not Use

Stated as a list because its absence is the point, and because “we may use cookies for analytics” is the sentence most job sites hide behind:

  • No third-party analytics. No Google Analytics, no tag manager, no product-analytics SDK. Nothing on this site reports what you do to anyone but us, and §7 is the complete list of who is contacted.
  • No profile of you, and no behavioural targeting. We count openings of a job posting. We do not build a picture of you from them, we do not use them to decide what you are shown, and they reach the employer as numbers on their own job — never as a list of what you read.
  • No advertising cookies, no advertising pixels and no conversion tags.
  • No session recording or heatmap tool. Nobody replays your screen.
  • No fingerprinting by us — we do not profile your device, fonts, canvas or hardware, and nothing we run examines them. On the four sign-in pages only, Google’s reCAPTCHA does look at device and interaction signals; that is how it tells a person from a script, it happens nowhere else on this site, and neither we nor Google use it here to profile you or to decide what you are shown. See §7.
  • No cross-site or cross-context tracking, and no data sold or shared for it. Nothing you do here follows you to another site. An employer sees the count on their own posting and nothing else — no employer learns which other jobs you viewed, on this site or anywhere.
  • No IP address and no user-agent recorded against your session, your consent, or a job view — including the view signal in §5, which is why declining costs you nothing in privacy that we were collecting anyway. This is unusual and it is deliberate.

One thing you may find in the page source, disclosed rather than omitted. Our published configuration contains an unused Google Analytics measurement identifier. No analytics code is initialised, no measurement data is collected and nothing is sent to Google Analytics. It is a leftover configuration value, and we would rather explain it than have you find it and wonder.

We do not respond differently to a Do Not Track header. It is unenforced and ambiguous, and §6 asks you the question directly instead — which is a worse excuse than the one this sentence used to give, and a more honest one.

5Shared Job Links

If you reach a job through a link somebody shared — on a social network, in a newsletter, in an email — that link carries a short token identifying the channel it was shared through. It stays in the address bar for as long as you are on that page. The site does not store it in your browser, and it does two things with it, both of which end when you leave the page:

  • Sends a single view signal so the employer can count how many people opened that link.
  • Drops it from the link back to your search results, so it does not follow you around the site.

The view signal, on every job page

The same signal is sent when you open any job posting, not only one you reached through a shared link, and it is how an employer knows whether the job nobody applied to was also the job nobody saw. It contains the job, a timestamp, and the utm_source value if the link that brought you here carried one — a word like linkedin or google, naming the channel and never you.

What it carries depends on your answer in §6, and that is the whole of the difference. If you declined or have not answered, it carries no identifier at all — it counts an opening, and two people opening the same job are indistinguishable from one person opening it twice. If you accepted, it also carries the random number from ros-visitor-id, which lets the count tell those two cases apart. Either way it carries no IP address and no user-agent, it is stored nowhere on this site, and it is sent whether or not you have an account.

Because the count of distinct people depends on who accepted, it is an undercount — deliberately. We would rather show an employer a number that is honestly short than ask you for something you did not want to give.

6The One Thing We Ask You

Consent rules exist for storage that is not needed to deliver the service you asked for. Everything in §2 and the first three rows of §3 is either strictly necessary to run the site or a preference you set yourself. Exactly one entry is neither: ros-visitor-id, the random number that lets a job’s view count tell a returning reader from a new one. So we ask about that one, and only that one.

The banner appears once, on your first visit, with Accept and Decline the same size and the same prominence. Declining is not hidden behind a second screen and does not have to be repeated per purpose, because there is only one purpose. Your answer is remembered in ros-analytics-consent and you are not asked again unless this policy substantially changes.

Changing your mind

The link in the site footer reopens the choice, and so does the Privacy section of your profile if you have an account. Choosing Decline after having accepted deletes ros-visitor-id rather than merely stopping its use — the number is gone from your browser, and accepting again produces a new one that cannot be joined to the old.

Declining does not reduce what the site does for you. Every page, search, application, interview and offer works identically. The only difference is that an employer’s view count treats each of your visits as a separate opening.

If we ever add storage that genuinely requires consent beyond this, this section changes and the choice widens with it. The document version at the top of this page is how you would know.

7Third-Party Requests From This Site

RequestWhat it disclosesStorage set
Google Fonts — the Inter typeface, on every page loadYour IP address and browser user-agent, to GoogleNone
Firebase Authentication (Google) — when you sign inYour email address or Google account, to GoogleIndexedDB and local storage — see §3
Google reCAPTCHA Enterprise — on the sign-in, registration and password-reset pages onlyYour IP address, browser user-agent and how you interacted with the page, to Google. It is what stops scripts creating accounts in bulk and using our signup form to send mail to addresses that never asked for it.A _GRECAPTCHA cookie, set by google.com — not by us, and not readable by us
Our own API — every data request the site makesYour session cookie, to usSee §2

No advertising network, analytics provider, social widget or embedded tracker is loaded on any page of this site. reCAPTCHA is the one third-party script that examines how you use a page, and it is loaded on four pages — sign-in, registration, forgot-password and reset-password — and on none of the job pages. It is there to keep automated abuse off the sign-up form, which is a security measure rather than a choice about advertising, so it is not covered by the question in §6; if you would rather not be assessed by it, you can browse and search every job on this site without ever loading it.

8Managing These, and Questions

Every browser lets you view, block and delete cookies and clear site storage, usually under privacy or site settings. What happens if you do:

  • Blocking the two cookies in §2: you can still search and read jobs, but you cannot sign in — so no saving, applying, booking or responding to an offer.
  • Clearing the storage in §3: the site works normally and forgets your preferences. Your theme resets to System, you are signed out, and — because your analytics answer is cleared with everything else — the §6 banner asks once more on your next visit.
  • Clearing a share token mid-application: the application still submits. It is simply attributed to no channel, which affects the employer’s reporting and nothing about you.

This policy is updated when the list changes, and carries an effective date and version at the top of the page. For anything about your personal data more broadly — including how to make a privacy request, and who to contact — see the Privacy Policy.

Employer loginLoginRegister