Cookie policy

1. Scope and legal framework

This policy describes cookies, local storage, scripts and similar technologies used on seeft.io, www.seeft.io and tools.seeft.io. It supplements the Privacy policy and reflects Article 122 of the Italian Privacy Code, the GDPR and the Italian Data Protection Authority’s cookie guidelines of 10 June 2021.

Strictly necessary cookies and technologies are used to provide the requested service. Browser analytics and diagnostics are activated only with consent. As a cautious approach, Seeft treats Umami as optional even though it does not place cookies, because it generates session identifiers and measures navigation.

2. Classification criteria

Seeft classifies technologies by purpose, not merely by name or technical format:

• Necessary: required for delivery, language, security, authentication and storage of privacy choices;
• Analytics: measure visits and feature use to improve the service;
• Diagnostics: collect errors, performance information and masked replays to identify technical problems.

The latter two categories are disabled by default. There are no advertising or commercial-profiling categories.

3. Necessary cookies and storage

Names prefixed by __Secure- or __Host- are the HTTPS variants. Some OAuth cookies appear only during sign-in and callback handling.

| Name/item | Type and domain | Purpose | Duration | | --- | --- | --- | --- | | seeft_consent | First-party cookie, .seeft.io domain | Stores categories, services, language, random consent identifier and preference revision across Seeft domains | 182 days | | NEXT_LOCALE | First-party cookie, .seeft.io domain | Stores the selected language across Seeft domains | 1 year | | theme | Local storage | Stores the light or dark theme | Until deleted in the browser | | __Secure-next-auth.session-token (or the unprefixed variant outside HTTPS) | First-party, HttpOnly cookie | Maintains the authenticated session | Normally 30 days or until logout/expiry | | __Host-next-auth.csrf-token | First-party, HttpOnly cookie | Protects authentication against forged requests | Session | | __Secure-next-auth.callback-url | First-party, HttpOnly cookie | Returns the user to the correct page after sign-in | Session | | __Secure-next-auth.pkce.code_verifier, __Secure-next-auth.state, __Secure-next-auth.nonce | First-party, HttpOnly cookies | Temporary security and verification for OAuth/OIDC | Up to 15 minutes or session |

seeft_consent is a technical cookie used to remember and demonstrate the user’s choice and does not itself require consent. Deleting it causes the banner to appear again.

4. Optional analytics

4.1 Umami Cloud

Only after consent to “Umami Analytics” does Seeft load the script from cloud.umami.is for the configured domains. The integration:

• respects the Do Not Track signal;
• excludes URL search parameters and fragments (#...) from transmission;
• measures pages, referrer, duration, browser, operating system, device and approximate location;
• does not intentionally send tool inputs, outputs, files or filenames.

Umami does not place analytics cookies. To distinguish sessions, however, it generates a hash from technical data such as IP address, user-agent and website identifier using a periodically rotated salt. According to the vendor’s documentation, the IP address is used for geolocation but is not stored. Seeft does not configure an account-linked distinctId.

The Umami account uses the EU region and the Hobby plan. The current integration loads only script.js: it does not load recorder.js, enable replays or heatmaps, or explicitly enable Core Web Vitals collection. The actual Umami Cloud retention period still needs to be confirmed with the vendor; Seeft aims to limit it to no more than 13 months. If additional features are enabled later, the policy and consent choices must be updated before activation.

Vendor: Umami Software, Inc. — privacy information. Before final publication, Seeft must obtain or accept a valid DPA from the vendor and retain a copy.

4.2 Seeft product events

After consent to “Seeft product analytics”, the website creates seeft_analytics_id in local storage. It contains a random UUID and creation date, with an application-enforced lifetime of 182 days.

Allowlisted events are limited to viewing the tool, adding a transformation step, exporting, clicking save, creating a saved transformation and running one. Seeft receives the event name, tool slug and random identifier; for signed-in users, the record may be linked to the internal account identifier. Inputs, outputs, configured operations, files and filenames are not sent.

Events must be deleted or aggregated within 13 months. On withdrawal, the local identifier is removed and new transmissions stop.

5. Optional browser diagnostics

Sentry browser diagnostics

Sentry is initialized in the browser only after consent to the service. In production, Seeft samples approximately 10% of ordinary traces and sessions and 100% of replays associated with an error. Replay masks all text and blocks media.

The configuration disables default PII transmission and removes user data, cookies, headers and request bodies before sending an event. URLs without query strings, technical information, interface actions, stack traces and connection data may still be processed. Secrets and sensitive data must therefore never be placed in URLs or technical names.

Data is sent to the EU data region through Sentry’s Germany ingestion endpoint (ingest.de.sentry.io) and is retained for 30 days according to the project settings. Default data scrubbing, IP-address scrubbing and Enhanced Privacy are also enabled in the dashboard. Vendor: Functional Software, Inc. — privacy notice, DPA and transfer information.

6. Server-side diagnostics

Server-side Sentry may operate without consent for backend security and reliability. It does not read or write cookies or local storage on the user’s device and does not create replays. sendDefaultPii is disabled. This processing relies on legitimate interests and is described in the Privacy policy; it does not appear as a banner toggle because it is not a storage or terminal-access technology.

7. Giving, changing or withdrawing a choice

On the first visit:

• “Accept all” enables every optional service;
• “Reject all” keeps only necessary technologies;
• “Customize” allows selection by category and service;
• closing the banner with the X rejects optional technologies.

Optional choices are not preselected, and refusal does not restrict essential features. Choices may be changed at any time using “Cookie preferences” in the footer. Withdrawal stops new transmissions; where an SDK was already loaded, the page reloads to complete shutdown. Withdrawal does not affect the lawfulness of earlier processing.

The banner is not shown again before the choice expires unless conditions materially change, the preference cannot be read or the user requests it.

8. Choice register

To document consent and refusal, Seeft records the consent identifier, action, categories and services, language, hostname, policy versions, banner revision and server date. For signed-in users, the internal account identifier may be associated. The register does not directly store full IP addresses or user-agent strings.

The legal bases are the obligation to demonstrate consent and legitimate interests in defending claims. Records are kept for five years unless needed for pending proceedings. Refusal is recorded to avoid repeated requests and demonstrate that optional technologies were not authorized.

9. Browser settings

Browsers allow users to inspect, block or delete cookies and storage. Blocking necessary items may prevent sign-in, language preferences or storage of the privacy choice. The banner controls remain the recommended way to manage optional services.

10. Updates

The version and effective date appear at the top of this page. If purposes, vendors, categories or optional technologies change, Seeft will update this policy and, where required, increase the banner revision and request a new choice.