Snipefinity Cookie Policy
Operating entity: Snipefinity (currently operated as an unincorporated project by Ahmad Alibrahim, based in Kuwait) (the "Service," "we," "us," "our"). Effective date: 6 June 2026 Last updated: 6 June 2026
1. Scope
This Policy applies to the Snipefinity web application and to the Snipefinity marketing website at snipefinity.com. The application sets the strictly-necessary cookies described below; the marketing website currently uses only strictly-necessary cookies, and any analytics introduced on either surface will be disclosed here and, where consent is required in your jurisdiction, gated behind consent before it is activated.
This Policy describes the cookies and cookie-equivalent storage technologies we use, the third-party data transmissions that originate from your browser when you use the Service, and the limited choices you have. It is a companion to our Privacy Policy, which describes the personal data we process and our legal bases.
2. What a cookie is
A cookie is a small text file that a website asks your browser to store on your device. The website (or another party whose code runs on the page) can read that file back on later visits. Cookies are the most common terminal-equipment storage technology, but the same legal regimes generally apply to functionally similar mechanisms — localStorage, sessionStorage, IndexedDB, and certain browser-side requests that read device characteristics. Where we use any of these, we describe them below using the umbrella term "cookies and similar technologies."
3. Cookies we use today
All cookies set when you use the Snipefinity web application today are strictly necessary — they are required to operate the Service you have explicitly requested (signing in, navigating between pages, and protecting your session). The application code itself sets no cookies; the cookies below are set by the underlying authentication SDK (Clerk) and by the Next.js framework runtime.
| Cookie | Set by | Purpose | Type | Lifetime | Strictly necessary? |
|---|---|---|---|---|---|
__session | Clerk (auth SDK) | Stores your authenticated session as a signed JWT. Without it, you cannot stay signed in. | First-party; HttpOnly, Secure, SameSite=Lax | Session (Clerk-managed) | Yes |
__client_uat | Clerk (auth SDK) | Lets the client-side app detect whether you appear to be signed in before the server confirms. | First-party; Secure, SameSite=Lax | Session | Yes |
__clerk_db_jwt, __clerk_handshake, __clerk_satellite_url | Clerk (auth SDK) | Multi-domain handshake and dev-mode session coordination. Most are only set in development or multi-domain configurations. | First-party; Secure, SameSite=Lax | Session | Yes |
__prerender_bypass, __next_hmr_refresh_hash, NEXT_LOCALE (if locale is enabled) | Next.js framework | Build, routing, and locale internals. Set by the framework on demand. | First-party; HttpOnly where applicable | Session | Yes |
CSRF protection. Our application uses the Clerk session cookie as the cross-site-request-forgery (CSRF) anti-replay surface; we do not set a separate CSRF cookie. The CSRF role is covered by the same __session row above.
Cookie-equivalent browser storage we use. We use sessionStorage on the strategy snapshot pages to carry a captured strategy payload into the strategy editor on the same browser tab. The stored payload is your own strategy code; it never contains identity or contact information, and it is cleared when the tab closes or when the editor consumes it. If your browser's theme switcher uses localStorage to remember light/dark mode, that key is set by the next-themes component for your visual preference only.
4. Third-party data transmissions from your browser
Some third-party code that runs on the Snipefinity web application does not set cookies but does transmit information directly from your browser to a third-party service. We disclose these here because they have the same transparency implications as cookies, even when the technical mechanism is different.
- Sentry (error tracking). Our front-end loads the Sentry browser SDK, which captures uncaught exceptions and other client-side errors and sends them to Sentry's endpoint (United States) for engineering diagnostics. The SDK does not set first-party cookies on your device; it transmits error events using
XHRandsendBeaconrequests. Our configuration disables personally-identifying defaults, disables session-replay, disables transaction tracing, and applies a redaction filter to error events before they leave your browser. Sentry is a sub-processor; cross-border transfer mechanism is disclosed in our Privacy Policy (see PP §6.1 and §8.3).
If the Sentry configuration changes (for example, if session-replay is enabled), this Policy will be updated and — where required — a consent mechanism will be added before the new behaviour ships.
5. Cookies we do not use
We have verified that the following are not present in the Snipefinity web application:
- No third-party advertising or remarketing cookies, pixels, or beacons.
- No Google Analytics, Mixpanel, Hotjar, Microsoft Clarity, Intercom, or HubSpot.
- No Facebook Pixel, LinkedIn Insight Tag, or TikTok pixel.
- No Stripe.js, Cloudflare beacon / RUM, or other third-party RUM beacons.
- No product-analytics SDK of any kind is loaded today (see §7 below for our planned future activation, which remains tool-agnostic at this stage).
We do not sell or share your data with advertising networks. There is no cross-site tracking on the Service.
Global Privacy Control. Although we do not currently engage in "sale" or "sharing" of personal data within the meaning of US state privacy laws, we detect the Sec-GPC: 1 browser signal at session initialisation and honour it as a valid opt-out preference. Engineering verification: see PP §17.6.
6. Why we do not show a cookie consent banner today
The Service currently uses only strictly-necessary cookies as defined above. Strictly-necessary cookies do not require prior consent under:
- the EU ePrivacy Directive (Directive 2002/58/EC, Article 5(3)) — exemption for storage strictly necessary to provide an information-society service explicitly requested by the user;
- the UK Privacy and Electronic Communications Regulations 2003 (PECR Regulation 6(4)(b)) — equivalent strictly-necessary exemption; and
- the Saudi Personal Data Protection Law (PDPL) and the GCC privacy frameworks generally — these do not impose a cookie-specific consent regime, and the transparency principle is satisfied by this Policy.
Because we set no analytics, advertising, or behavioural cookies, no consent prompt is legally required at this time. We will add a consent mechanism before activating any cookie or storage technology that requires one. Our full list of sub-processors and the data each receives is published in our Privacy Policy (see PP §6 and §7).
7. Planned future activations
We may introduce additional cookies or analytics in the future (for example, first-party product analytics). They are not active today. If we activate any, this Policy will be updated and, where consent is required in your jurisdiction, a consent mechanism will be added before the change takes effect.
8. How to manage cookies
Because we set only strictly-necessary cookies, blocking them in your browser will prevent you from staying signed in or using the Service.
You can manage cookies directly in your browser. Most browsers let you see what is stored, delete specific cookies, block third-party cookies, or block all cookies. The vendors below publish current instructions:
- Chrome: Settings → Privacy and security → Cookies and other site data
- Safari (macOS / iOS): Preferences → Privacy
- Firefox: Settings → Privacy & Security → Cookies and Site Data
- Microsoft Edge: Settings → Cookies and site permissions
You can also clear localStorage and sessionStorage from your browser's developer tools. If you sign in again, the strictly-necessary cookies described in §3 will be re-set.
9. Changes to this Policy
We will update this Policy when our cookie or browser-storage behaviour changes — including when a planned future activation (§7) goes live, when we add or remove a sub-processor whose code runs in your browser, or when applicable law changes.
Material changes — including any change that adds a non-essential cookie or analogous storage, or any change that requires consent under applicable law — will be communicated through our canonical amendment process, described in Terms of Service §17 (and applied to privacy-specific changes in Privacy Policy §16). That process is the single source of truth across our legal pack (Terms of Service, Privacy Policy, Acceptable Use Policy, and this Cookie Policy) and includes prior in-product notice and (where required) re-consent before the change takes effect. Non-material changes (typographical corrections, vendor-name updates, restructured headings) will take effect on posting; the "Last updated" date at the top of this Policy will always reflect the most recent change.
10. Contact
Questions about this Cookie Policy can be sent to privacy@snipefinity.com (see PP §19 for the full set of privacy contact channels). For DSARs and other data-subject requests, the channels and timelines published in our Privacy Policy apply. Snipefinity is currently operated as an unincorporated project by Ahmad Alibrahim, based in Kuwait; entity formation is in progress and this Policy will be updated to reflect the operating entity when it is named.