Privacy Policy

This Privacy Policy describes how Driftstack Processes Personal Data in connection with the Service. Capitalised terms are defined in the Terms of Service.

This Privacy Policy describes Driftstack’s processing as a Controller (account, billing, support correspondence, marketing site analytics where applicable). Driftstack’s processing as a Processor on Customer’s behalf (Customer Data, Session content, Customer-Provided Secrets) is governed by the Data Processing Agreement (DPA), which is incorporated into Customer’s contract by reference.

1. Controller identity

The Controller of Personal Data described in this Privacy Policy is Driftstack, a sole proprietorship (eenmanszaak) registered with the Dutch Chamber of Commerce (KvK) under number 42064799.

For all matters relating to the Processing of Personal Data, including the exercise of Data Subject rights, contact:

• Privacy: privacy@driftstack.dev
• Legal: legal@driftstack.dev

Driftstack does not currently have a Data Protection Officer subject to mandatory appointment under Article 37(1)(b) GDPR; the Privacy Contact above is the primary point of contact for Data Subjects, supervisory authorities, and counterparties. Driftstack will appoint a DPO promptly if Driftstack’s Processing activities cross any threshold that triggers a mandatory appointment under applicable law.

2. Scope of this Privacy Policy

This Privacy Policy applies to:

1. Personal Data of Customer’s Authorized Users that Driftstack Processes to provision, bill for, and support the Service.
2. Personal Data of individual contacts (e.g. founders of B2B prospects) that Driftstack collects in pre-sales correspondence.
3. Personal Data collected through any public-facing Driftstack property (the marketing site at driftstack.io, the API status page, the GitHub repository — to the extent any of these collect Personal Data).

This Privacy Policy does not apply to:

1. Personal Data Customer routes through the Service in the course of its own automated browsing — that data is governed by the DPA, where Customer is the Controller and Driftstack is the Processor.
2. Personal Data Processed by Sub-processors under their own privacy policies (linked in Section 7).
3. Personal Data Processed by Customer-Connected Services (proxies, captcha, email, SMS) under those services’ own policies.

3. Data we collect (and why)

Driftstack collects the following categories of Personal Data, each for the purposes and on the legal bases set out below.

3.1 Account data

What: legal entity name, billing address, VAT/BTW identification number, primary contact name, primary contact email, billing email, optional support contacts, time zone, optional profile avatar (Customer-uploaded image stored through the Cloudflare R2 Sub-processor; see Section 7 / DPA Annex 3), and an optional Customer-stated infrastructure region preference (us, eu, or apac). The preference is informational and non-binding because it does not change current data residency; Sections 6 and 7 contain the authoritative routing disclosure.

Sign-up acquisition record: the page you signed up from, the site that referred you (domain only), campaign tags in the link you followed, and anything you tell us about how you heard of Driftstack; and, from your first visit to driftstack.io or docs.driftstack.io in the 90 days before you signed up, the site that first referred you (domain only), that visit’s campaign tags and landing page, the day of that visit, and up to 20 of our pages you read before signing up (the page addresses only, never what you typed). Your browser keeps that first-visit note in its own storage for that site (no cookie) for at most 90 days; it is sent to us only when you sign up, and we never receive it if you do not. We also record your device type (computer, phone, tablet or app), never the full browser identifier. All of this is kept with the account, used only to understand which channels bring customers and how they get started, never shared, and never read from or sent to a third party. It is deleted with your account.

Free-trial checks: Each person may have one free Trial. To keep to that, when you prove your email address (also when you sign up with Google or GitHub) and when you sign in to the desktop app, while your account is on a free Trial it has never paid for, we make one-way codes and compare them with the codes kept from other accounts:

1. a code made from your email address, written in lower case, with anything after a “+” before the “@” left out and, for Gmail (gmail.com and googlemail.com, taken as one), the dots left out;
2. a second code made from your email address after also joining the address forms that some mail providers deliver to one mailbox (for example icloud.com, me.com and mac.com; the Yandex domains; and Fastmail addresses of the form [email protected]);
3. if you use the desktop app, a code made from the random installation id the app keeps on your computer;
4. if a Google or GitHub sign-in is linked to your account, a sign-in code made from the fixed identifier that Google or GitHub gives you (not your name, email address or password); we make it only when a check is made again later or a pending check is taken up (see below).

Every account that existed when these checks began was given the first email code, whatever its plan. We also make the second email code once from the address of each existing account that already has an email code and is not closed, including accounts on a paid plan, so that later Trials are compared with it.

When you prove your address, we also look at whether your email domain is on a list of disposable-email services, whether it belongs to an email relay service that gives each website its own address, and whether the address can be read in the usual form; we keep only the result, not the domain.

For these checks we keep only the codes, not your email address, the installation id or the Google or GitHub identifier. The codes are one-way: the address or an id cannot be read back from a code, but a code can be matched by making it again from the same address or id. We also keep a record of each different result of a check on your account, including a match found when another account’s pending check is completed: when it happened, at which step (proving the address, a check made again for an account with a Google or GitHub sign-in, or the desktop app) and under which setting of the checks, which kinds of check matched (for example “email” or “desktop app”, never a code or an address), a score, for a match how many accounts had matched that code by then, and whether it changed your Trial; staff may add their assessment of a result (correct, wrong or unknown). When a code matches, the code it matched also records how many other accounts matched it and when the last one did. If a check that should make the second email code or the sign-in code cannot make them at the time, we keep a note that it is pending, with no address and no code, until it is completed, and at most 30 days. If a check fails, your Trial is kept and no note is made; a later run may find a running Trial whose email check never happened and make the check again. That run keeps a record of its attempts for your account (how many failed, whether one ran, and when the last one was), which is deleted 30 days after the last attempt and is not unlinked from the account before then. Your account itself also keeps whether and when a check ended its Trial and why (a matching code or a disposable-email domain), and whether staff gave the Trial back; this is kept as account data (Section 9).

If the first email code or the desktop code matches a code kept from another account, your new Trial ends automatically at that check. A match on the second email code or the sign-in code, or an email domain on the disposable-email list, can also end it; each of these is switched on only after a period in which its result is only recorded. The check does not itself refuse or close your account: you can still sign in and choose a paid plan. As with any ended Trial, an account that has not chosen a plan within 30 days after the Trial ended may be closed, after a warning email at least 7 days before (Terms of Service, Section 8.9), so ask for a review before then. You can ask a person to review the decision (Section 10).

Only Driftstack staff see these records, in our admin tools, as kinds of check, steps, outcomes, scores, counts and dates, with the setting the checks run under, staff assessments and the state of the secret key the codes are made with (once the checks are switched on): never a code, an email address, an installation id or a Google or GitHub identifier. Staff decisions on a review, with the reason they record, are kept in our admin audit log. Our server logs record account ids and the kinds of check that matched, never an email address, an installation id, a Google or GitHub identifier or a code. The codes and records are held in Driftstack’s database and its encrypted backups (Section 7).

If you close your account, the codes are kept, so that closing an account and signing up again does not give a second Trial. When the account is erased, 30 days after it is closed, the codes and the records of each check are unlinked from it and kept until their own period in Section 9 ends; the record of attempts is not unlinked and is deleted as Section 9 says, and the note of a pending check is deleted at erasure. For the same reason they are kept if you ask us to erase your data. We use the codes and records only for this check, for reviewing its results and for measuring how well the check works, on the basis of our legitimate interest in keeping the free Trial to one per person and preventing its abuse (Art. 6(1)(f) GDPR).

Sign-up checks against fraud. When you create an account, we record the internet address (IP address) and the browser details (user agent) your sign-up came from, together with a few signals derived from them: the country, the type of network (for example a data centre or a Tor exit), the kind of browser or tool (for example a computer or phone browser, or an automated tool), whether your email address is from a disposable or forwarding service, and the result of our bot check. We also note how you signed up (email, Google or GitHub sign-in, website or desktop app) and the network operator your address belongs to. If you later sign in with our desktop app, we also record an identifier of that installation. We use this only to prevent fraud and abuse, such as stolen-card payments or one person opening many accounts to repeat free trials. Our legal basis is our legitimate interest in preventing fraud (GDPR art. 6(1)(f)). We delete the IP address and browser details after 90 days. We keep the derived signals and the installation identifier while your account exists, and delete them when your account is erased.

Why: to administer the contractual relationship, generate VAT-compliant invoices, send service notifications, provide support, render Customer identity in the dashboard and GUI Client, and (for the sign-up acquisition record) understand which channels bring customers.

Legal basis (GDPR Art 6): Article 6(1)(b) — performance of the contract with Customer (where the contact is Customer’s principal or authorised representative). Article 6(1)(f) — Driftstack’s legitimate interest in administering the relationship and complying with its obligations (where the contact is a Customer employee whose contact details are necessary for service operation). Article 6(1)(f) — Driftstack’s legitimate interest in knowing which channels bring customers (the sign-up acquisition record, which is limited to what the sign-up page itself held and what Customer chose to type).

Source: Customer provides directly at signup or via Account configuration through the API or GUI; the sign-up acquisition record is taken from the sign-up page at the moment of sign-up.

3.2 Authentication data

What: API Keys (stored as scrypt-hashed values; the plaintext key is shown to Customer once at issuance and is not recoverable thereafter), session tokens for the GUI Client, key prefixes and last-used-at timestamps. When Customer enrolls in optional second-factor authentication, Driftstack also stores a TOTP secret encrypted at rest with AES-256-GCM, ten single-use recovery codes as scrypt hashes (raw codes shown once at enrollment), and a per-session MFA-satisfied timestamp used to gate sensitive operations. Plaintext TOTP and recovery-code material is not retained after enrollment. For each sign-in to the dashboard, Driftstack also records the address the sign-in came from, the browser’s user-agent string, and the country and city its edge network resolved for that address at the time of the sign-in (never looked up afterwards); the address and the user-agent string are cleared 90 days after the sign-in ends.

Why: to authenticate API requests, scope operations, detect or remediate compromise (including a sign-in pattern that does not fit the account, such as sign-ins from many countries in a short time), and enforce step-up reauthentication for sensitive operations.

Legal basis: Article 6(1)(b) — performance of the contract. Article 6(1)(c) — compliance with legal obligation under Article 32 GDPR (security of processing).

Source: Driftstack generates API Keys and MFA enrollment material at Customer’s request; Customer stores and manages the one-time plaintext values.

3.3 Session metadata

What: session id, account id, target URL, archetype identifier, timestamps, duration, success/failure, aggregate operation counts.

Why: to operate the Service (route Sessions to Mac mini fleet nodes, enforce rate limits, generate usage reports), to detect abuse, and to maintain Service capacity planning.

Legal basis: Article 6(1)(b) — performance of the contract. Article 6(1)(f) — legitimate interest in detecting abuse and protecting the Service.

Source: generated by the Service in the course of executing Customer’s instructions.

3.4 Desktop-local recordings and API Capture artifacts

Desktop-local recordings. When Customer enables recording in the GUI Client, the desktop app captures streamed frames and writes the completed recording as local NDJSON files in the app data directory on Customer’s device. Those frames can include Personal Data that Customer’s automated browsing encounters. Customer controls whether to record, export, retain, or delete those device-local files.

The recording workflow does not upload recording files or frames to Driftstack’s API, control plane, or Cloudflare R2. Driftstack has no API recording endpoint and applies no cloud recording-retention window.

API Capture artifacts. An authenticated Customer may request a screenshot, DOM snapshot, or PDF through POST /v1/sessions/:id/capture. Driftstack returns the resulting bytes inline in that response; the Capture endpoint does not retain the artifact. Customer decides whether and where to store it.

Processor role and retention boundary. Driftstack transiently Processes live-session media and API Capture requests as Processor on Customer’s behalf under the DPA, not as Controller. Desktop-local recording files remain on Customer’s device and are not collected or retained by Driftstack. Live-session media is ephemeral: it streams through Driftstack’s own video relay and is dropped on session end. Customer determines the lawful basis for the underlying browsing and any copies Customer stores.

3.5 Customer-Provided Secrets

What: authentication credentials Customer supplies for use in Sessions, including (without limitation) HTTP/SOCKS5 proxy credentials, captcha-service API keys, IMAP / Gmail OAuth tokens, and SMS-service API keys.

Why: to forward to the appropriate Customer-Connected Service on Customer’s instruction during Session execution.

Legal basis: Driftstack Processes Customer-Provided Secrets as Processor on Customer’s behalf under the DPA, not as Controller. Customer holds the underlying relationship with the third-party provider; Driftstack is a transient holder of the credential for the duration of the Session and for the storage retention specified in Section 9.

Storage: encrypted at rest. Used only on Customer’s instruction. Not used for any purpose beyond executing Customer’s Session.

3.6 Billing data

What: transaction identifiers, payment method type (card, Link, Amazon Pay), last-four of payment instruments where retained, invoice status, amount, currency, VAT basis. Driftstack does not retain primary account numbers (PANs); these are tokenised by Stripe under PCI-DSS scope.

Cryptocurrency payments. When Customer pays with cryptocurrency, Driftstack sends Confirmo Limited the order amount and the currency it is priced in, the coin and network Customer pays with, the currency Driftstack is paid out in, the Plan, Driftstack’s order reference, a reference for Customer’s Account and the web address Customer returns to after paying (which carries the order reference), and Customer pays on Confirmo’s hosted payment page. Confirmo processes that payment and what Customer enters on its page (such as the sending wallet and, where the law requires it, the details its Travel Rule checks ask for) under its own terms and privacy notice. Driftstack keeps the order record (amount, coin, status, dates and the payment’s transaction reference) for its accounting obligations (Section 9).

Why: to process Subscription Fees, generate invoices, and maintain accounting records.

Legal basis: Article 6(1)(b) — performance of the contract. Article 6(1)(c) — compliance with Dutch tax law (Article 52 of the Dutch Algemene wet inzake rijksbelastingen; 7-year retention).

Source: Stripe returns transaction metadata to Driftstack via webhook. Customer provides billing details at signup or via the customer portal.

Renewal-reminder emails. Approximately seven (7) days before each recurring subscription invoice is generated, Stripe fires an invoice.upcoming webhook to Driftstack. We use this signal to send the billing email address one (1) billing-renewal-reminder email per upcoming invoice, summarising the upcoming amount, currency, and renewal date, and linking to the customer billing portal. Customers may opt out of this email at any time via the dashboard’s email preferences page (the underlying contractual notification — actual charge confirmation — is sent by Stripe and is not opt-outable). The complete catalog of emails Driftstack sends — opt-outable vs transactional — is on the public Emails reference page.

3.7 Support correspondence

What: email content, support ticket content, including messages sent from the desktop app or the web dashboard (“Help”), attachments, and metadata associated with Customer’s contact with Driftstack support, together with the diagnostic details a Customer chooses to include with a Help message: the platform and user-agent strings the browser reports (in the desktop app, the browser engine inside it), which name the operating system and the browser or browser engine, often with version numbers; whether the app is connected to Driftstack’s cloud or to a self-hosted server; the identifier of the team workspace Customer is working in, if any; and, from the desktop app, the app version, the identifiers of the profile or session concerned, and the last error lines the app displayed. The app offers a preview of exactly what will be included before it is sent; when Help is opened from a session in the desktop app, the details are included unless Customer unticks them. The details never include API keys, proxy credentials, cookies, page content, screenshots, recordings or the network log.

If Customer writes to Driftstack on Telegram, in the public community group (t.me/driftstackhq) or to @driftstack directly, the messages are held by Telegram under its own terms. Messages in the group are public: anyone who opens the group can read them, and its members can forward them. Driftstack reads them to answer.

Why: to provide support, document service issues, and improve the Service. Support mail and Help messages are sorted and, where a reply is drafted, drafted with AI assistance; a person reads and approves every written reply before it is sent. A fixed acknowledgement of receipt may be sent automatically. Content is not used to train any model. Messages to security@, legal@, abuse@ and privacy@ are never given to an AI model and never receive an AI-drafted reply; a person reads every one of them.

An AI-drafted reply is never sent on its own. When the sender is verified as the account holder, the AI drafting a reply is also given that account’s billing basics: the plan, the subscription’s status and current period end, the dates and amounts of its recent invoices, including any amount refunded or disputed, the trial end date and the date of its first session. When the message was sent from the desktop app, the AI is also given the app details Customer included with it: the app version, the platform, the deployment (Driftstack’s cloud or a self-hosted server), the identifiers of the session and profile concerned, and the last error lines the app displayed. These details are sent to Anthropic only to draft the reply and are not used to train any model.

Help also offers an assistant that answers questions from Driftstack’s documentation. It is an AI: its answers are not reviewed by a person before you see them, and you can ask for a person at any time. What you type is sent to Anthropic to generate the answer, with credentials Driftstack recognises removed first; it is not used to train any model. For a signed-in Customer the assistant is given, about that Customer’s own account only: the plan and whether it is a trial (and when the trial ends), that plan’s limits (concurrent sessions, saved profiles, whether the plan includes API access and the AI agent), whether the account is active or suspended, whether its email is verified, the number of API keys on the account (a count, never the keys), and the error codes of the account’s own recently failed sessions, and, when Help is opened in the dashboard or the desktop app, the name of the screen you are on and the error code that screen is showing, if any — never the screen’s content or anything you typed there. It is never given another Customer’s data, nor API keys, payment details or proxy credentials. When you ask the assistant on driftstack.io or docs.driftstack.io, it is given the path and title of the public page you are reading — never a query string, a fragment, or anything you typed on another page. Conversations with the assistant are kept for 90 days, or, if you send the conversation to a person, with that support conversation.

Legal basis: Article 6(1)(b) — performance of the contract (when support is contractually owed). Article 6(1)(f) — legitimate interest in service improvement (when correspondence reveals patterns of issue beyond the immediate Customer) and in operating support efficiently with AI-assisted sorting and drafting under human review.

Source: Customer’s outbound correspondence to Driftstack support addresses and Help messages submitted from the app or dashboard, and messages Customer sends Driftstack on Telegram.

3.8 Marketing-site data

What: access logs (IP address, user agent, referrer, request timestamp) for visitors to driftstack.io (the marketing site). Driftstack sets no analytics cookies. The site keeps the first-visit note described in Section 3.1 (Sign-up acquisition record) in your browser’s storage for that site, and counts visits by referring site and page without any identifier (no cookie, no stored IP address). Driftstack also uses Cloudflare Web Analytics on driftstack.io. For each page view, a Cloudflare script sends the page path, the referring site, the visitor’s country, device type, browser, operating system and page-load timings to Cloudflare, Inc., which processes them for us as a processor (Section 7). It sets no cookie, uses no browser storage, assigns no identifier and builds no profile, and Cloudflare keeps the full data for 7 days and a sampled aggregate after that.

Why: infrastructure operation and abuse detection.

Legal basis: Article 6(1)(f) — legitimate interest in operating the site. This measurement is first-party, minimal, kept only for Driftstack’s own statistics, not shared beyond our processor and not used to build profiles; Driftstack relies on it having little or no impact on your privacy (Article 11.7a(3)(b) of the Dutch Telecommunications Act). You can clear it at any time by clearing the site’s data in your browser.

Cookies: Driftstack uses strictly-necessary cookies on the marketing site (session-id for signup flow, CSRF token). Strictly- necessary cookies do not require consent under Article 5(3) of Directive 2002/58/EC (the ePrivacy Directive). Non-essential cookies, including analytics and marketing cookies, remain disabled unless the required consent mechanism and disclosure are active.

3.9 Status-page data

What: access logs (IP address, user agent, referrer, request timestamp) for visitors to status.driftstack.io (the public Service status page). Driftstack does not set analytics cookies on the status page.

Why: infrastructure operation and abuse detection, and to let Customers and prospects verify Service availability.

Legal basis: Article 6(1)(f) — legitimate interest in operating the status page.

Status-page content: the status page surfaces Service-level health metadata only (incident title, severity, affected components, chronological updates, and resolution time). It does not expose Customer Data, Capture or live-session content, Session payloads, account identifiers, or PII. Driftstack operators or automated health probes that Driftstack runs against its own endpoints generate the data shown.

Probe history: Driftstack records each automated health probe against its own public endpoints (timestamp, success flag, latency, HTTP status, and error message). This internal operational data does not reference a Customer or visitor and is retained for 30 days for diagnostic purposes.

Cookies: none. The status page is served from Cloudflare Pages and reads incident data from https://api.driftstack.dev/v1/status/incidents.

3.10 Status-page email subscriptions

What: the email address (only) submitted through the status-page “Subscribe to incident updates” form, opaque opt-in and unsubscribe tokens generated by Driftstack, and opt-in / unsubscribe timestamps.

Why: to notify Customers and prospects when a public Driftstack Service incident is posted or resolved.

Legal basis (GDPR Art 6): Article 6(1)(a) — explicit, freely-given consent through the double-opt-in flow. The address joins the notification list only after the subscriber opens the confirmation link. Every notification includes one-click unsubscribe.

Source: Customer or prospect voluntarily submits the address at status.driftstack.io.

Retention: subscription data is retained while subscribed. Unsubscribe creates a tombstone so the address cannot be re-added without a fresh double opt-in; the address is purged from that row 90 days after unsubscribe.

Recipients: the record is stored in Driftstack’s Postgres database, hosted by Neon in the EU (Frankfurt) as listed in Section 7; Postmark sends the notification emails as the Sub-processor listed in Section 7.

Cookies: none.

3.11 Live-session media (live view)

What: real-time WebRTC media streams (rendered browser screen) of each Session. Each session’s screen is streamed from the start to Driftstack’s own video relay on the same serving machine, so you and your team’s admins can watch it live. Driftstack does not record it, and Driftstack support cannot join. The stream can carry rendered frames, screen-coordinate metadata, a room id, connection metadata such as timestamps, ICE candidates, and peer ids, and the messages a viewer sends to the Session over the same connection, such as taps, keystrokes, pasted text, web addresses to open, and the list of open tabs.

Why: to let Customer watch an in-progress browser session in real time.

Legal basis (GDPR Art 6): Article 6(1)(b) — performance of the contract; the live view is a Service feature.

Source: the browser running Customer’s Session streams its screen from the start of the Session. The Session’s own account, a team admin of that account, or the desktop app’s control key for that Session opens the live view. Driftstack support cannot open or join a live view; if that changes, this Section will say so first.

Retention: live-session media is not stored. Frames pass through Driftstack’s own video relay in real time and are dropped on session end. No durable copy lands in Driftstack’s control plane. Driftstack has no cloud recording endpoint or recording-retention window. Customer may instead create a desktop-local recording on Customer’s device or request an inline API Capture artifact that the Capture endpoint does not retain.

Recipients: no additional Sub-processor. The video relay is Driftstack’s own and runs on the same serving machine as the Session. When a viewer opens the live view, the viewer’s browser contacts public address-lookup (STUN) servers run by Google and Twilio to learn its own network address. Those servers see the viewer’s IP address and nothing else; no session data or media passes through them.

Cookies: none.

Cryptography: media is encrypted in transit on each WebRTC connection using DTLS-SRTP. Driftstack’s own video relay receives and forwards the media. Driftstack does not currently provide application-level end-to-end encryption through the relay.

3.12 Live network metadata (Network pane)

What: the per-request metadata a Session’s own browser reports for each resource it loads, rendered live in the Network pane of the GUI Client’s session drawer: the request address (a URL, which can carry a query string), the HTTP method, the response status code, whether and why the request failed, the negotiated wire protocol (HTTP/1.1, HTTP/2, HTTP/3) and ALPN token, the resource type and the initiator, the transferred size in bytes, a timestamp and the basis it was taken on, the load duration, whether the response was served from cache, and a per-Session page number (which of the Session’s own browser pages made the request: a counter the browser keeps for that Session, not an identifier of Customer, of any person, or of the site). A user name or password in a request address, and a value in it that Driftstack recognises as a credential by its name or its format, are replaced by a marker before the entry is held: the Network pane shows that a value was hidden, never the value.

The entry format Driftstack validates and holds defines no request or response headers, no request or response bodies, and no cookies. Any other field a report carries is discarded when the entry is validated — before it is held, served, or logged — so headers, bodies, and cookies cannot be held or served even where a report sends them.

Why: to render the Network pane, so Customer can see which requests an in-progress Session made and over which wire protocol.

Legal basis (GDPR Art 6): Article 6(1)(b) — performance of the contract; the Network pane is a Service feature, populated by Customer’s own Session.

Source: reported by the browser running Customer’s own Session. Driftstack accepts a report only from the fleet node that Session is running on, and only while that Session is live; a report from any other node, or for a Session already closed, is refused.

Retention: live network metadata is not stored. Entries are held in the control-plane API server’s memory only — never written to a database, to object storage, or to any store that outlives the server process, and never written to a log line. Driftstack’s operational logs record identifiers, a status, counts, and the field name of a rejected row — never an address, and never any part of an entry. At most 2,000 entries are held for a Session, oldest evicted first, and at most 5,000 Sessions’ entries at once, stalest evicted first. The read endpoints serve entries only while the Session is running and return none once it is not, and tell browsers and proxies not to store them. A Session’s entries are discarded within 2 minutes after the Session ends, once 30 minutes have passed with no further request for that Session, or when the server process restarts, whichever comes first.

Export: a network log Customer exports from the Network pane is saved by the GUI client as a file on Customer’s own device; Driftstack keeps no copy of it, and Customer controls that file from then on.

Recipients: no additional Sub-processor. The reporting browser runs on the Mac mini fleet hosted by MacStadium (and can also run on serving machines hosted by Green Mini host B.V.) and the entries are held in the control plane hosted by Hetzner, all listed in Section 7; nothing is sent to Cloudflare R2, to the Postgres database, or to Redis. Entries are read back only over the owner-scoped network endpoints for that Session, which serve them to the account that owns the Session, to any account the Customer has given the admin role on that account’s team, or to the single-Session control key the GUI client holds for it, and to no one else.

Processor role: Driftstack Processes live network metadata as Processor on Customer’s behalf under the DPA, not as Controller, on the same footing as live-session media and API Capture requests.

Cookies: none.

3.13 AI chat history, assistant templates and Get started progress (desktop app)

What: when an Authorized User uses the AI chat in the desktop app, the app saves each conversation to that user’s Driftstack account: the messages the user typed, the agent’s replies and the steps it reported, the chat’s title, the profile and model it used, the team workspace it ran in, and timestamps. The app also saves the prompts the user saved as assistant templates, and which Get started steps the user marked done or hid, including whether the user dismissed the setup checklist.

Why: so the same history, templates and progress appear on any computer where that user signs in to the desktop app.

Role: Driftstack Processes this content as Processor on Customer’s behalf under the DPA: it is Customer’s instructions to the Service and the Session content the agent reported.

Storage: encrypted at rest under a key derived for the user’s account. This is not end-to-end encryption: Driftstack holds the key and can decrypt this content, which is what lets a computer that signs in with only an API key show it. It is held in the control plane’s database (the control-plane hosting and managed Postgres rows in Section 7) and is returned only to that user’s own sign-in in the desktop app or dashboard; it is not shown to other members of a team, not used to train any model, and not sent to any other Sub-processor (sending a new message to the AI agent is covered by the Anthropic, PBC row in Section 7).

Deletion: deleting a chat in the app deletes its content from the account at once; Driftstack keeps only a record that the chat was deleted (its identifier and times, with no content), so another computer does not restore it. When a user holds more than 300 chats, the oldest are deleted as new ones are saved. Signing out removes the computer’s copy only. Everything in this section is deleted within 30 days of Customer Account termination.

Cookies: none.

4. Special Category Data

Driftstack does not intentionally collect Special Category Data (Article 9 GDPR — racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data uniquely identifying a person, data concerning health, or data concerning sex life or sexual orientation).

If Customer’s automated browsing causes Special Category Data to pass through live-session media, live network metadata, or an API Capture request, that data is Processed by Driftstack only as Processor on Customer’s behalf under the DPA. A desktop-local recording may contain the same data, but that file remains on Customer’s device and is not uploaded or retained by Driftstack. Customer is responsible for ensuring it has a lawful basis under Article 9(2) GDPR for processing such data.

5. Data we do not collect

Driftstack does not:

1. Sell Personal Data to third parties.
2. Use Customer’s Personal Data for behavioural advertising or profiling beyond what is necessary to operate the Service.
3. Combine Customer-Connected Service data with Driftstack-internal profiles or cross-Customer aggregates.
4. Use Customer Data (including Session content, Workflows, live-session media, or Capture content) to train machine-learning models, including the bundled-LLM AI agent feature, without Customer’s separate explicit consent.

6. International transfers

Driftstack is established in the Netherlands and stores account data in the EU (Germany). Driftstack does not promise that Personal Data stays within the EEA. Several Sub-processors are established outside the EEA, or Process Personal Data there, in particular in the United States, where browser Sessions run. Browser Sessions can also run in the Netherlands, inside the EEA. Where Personal Data is transferred outside the EEA to a country without an adequacy decision under Article 45 GDPR, Driftstack relies on:

1. The EU-US Data Privacy Framework (DPF) for Sub-processors that are self-certified under the DPF and where the data category is within the scope of the recipient’s certification. Driftstack checks each Sub-processor’s current self-certification status on the EU-US DPF participants list (https://www.dataprivacyframework.gov/list).
2. The 2021 Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), in the appropriate Module per the Sub-processor’s role, for Sub-processors not (or not currently) DPF-self-certified, or for transfer paths the DPF does not cover.
3. Article 49 GDPR derogations only in genuinely exceptional cases (e.g. one-time transfers in support of a legal claim). Driftstack does not rely on Article 49 derogations as a routine transfer mechanism.

The current applicable mechanism and location per Sub-processor is documented in the Sub-processor list (Section 7). A copy of the safeguards that apply to a transfer can be requested from [email protected].

7. Sub-processors

Driftstack engages the following Sub-processors to provide the Service. Each Sub-processor is bound by a written agreement imposing obligations consistent with Article 28 GDPR.

The Sub-processor list is subject to change under the notice and objection mechanism in Section 3.4 of the DPA. The current list is published at /trust/sub-processors.

8. Customer-Connected Services (NOT Sub-processors)

The following third-party services are integrated with the Service under Customer’s account, Customer’s credentials, and Customer’s contractual relationship. They are not Sub-processors of Driftstack:

1. HTTP / SOCKS5 proxy providers (e.g. Bright Data, Smartproxy, Customer’s own infrastructure).
2. Captcha-solving services (e.g. 2Captcha, CapSolver, AntiCaptcha).
3. Email services Customer accesses by IMAP, Gmail OAuth, or equivalent.
4. SMS-verification services (e.g. TextVerified, Twilio).

Driftstack does not contract with these providers, does not receive service from them, and does not Process Personal Data on Driftstack’s behalf through them. The third-party Processes data on Customer’s instruction via Customer’s credentials. Each Customer-Connected Service operates under its own privacy policy between Customer and that provider; Driftstack has no visibility into that relationship beyond the credential Customer supplies and the response observed during the Session.

9. Retention

For every row, copies in encrypted backups are gone within a further 40 days (Section 12).

When the retention period for a category expires, Driftstack deletes the Personal Data or anonymises it (rendering it no longer attributable to a Data Subject). Anonymised aggregates may be retained for capacity planning.

10. Data subject rights

Where Driftstack acts as Controller for Personal Data of a Data Subject, the Data Subject has the rights set out in Articles 15–22 GDPR:

• Right of access (Article 15) — confirmation of whether Driftstack Processes the Data Subject’s Personal Data, and a copy of that data.
• Right to rectification (Article 16) — correction of inaccurate or incomplete Personal Data.
• Right to erasure (“right to be forgotten” — Article 17) — deletion in the circumstances set out in Article 17(1), subject to the exceptions in Article 17(3) (notably: legal obligation, the establishment, exercise, or defence of legal claims).
• Right to restriction of processing (Article 18) — Processing on hold pending verification or pending the establishment of a legal claim.
• Right to data portability (Article 20) — Personal Data the Data Subject has provided, in a structured, commonly used, machine-readable format. Driftstack provides a self-service audit export at /v1/account/audit-log/export?format=csv|json (Customer Dashboard → Audit log → Export), capped at 10,000 rows per export; older entries remain available through the paginated read API. Account, billing, and authentication data are exportable on request via [email protected].
• Right to object (Article 21) — to processing based on Article 6(1)(f) (legitimate interest), where the Data Subject’s interests prevail.
• Rights related to automated individual decision-making, including profiling (Article 22) — Driftstack makes one kind of automated decision about Data Subjects: the free-Trial check in Section 3.1 can end a free Trial without a person looking at it first. It decides only whether the free Trial runs; it does not itself refuse or close the account, and paid plans stay available. You can ask for a person to review the decision, give your view and contest it, through Help in the dashboard or the desktop app or by writing to [email protected]. While the account is open, a person then reviews it and can give the Trial back; later free-Trial checks on that account do not end it again. Driftstack makes no other automated decision producing legal or similarly significant effects on Data Subjects.

To exercise any of these rights, contact [email protected]. Driftstack responds within one (1) month of receipt of the request, extendable by two (2) further months for complex or numerous requests with notice to the Data Subject (Article 12(3) GDPR).

Where Driftstack acts as Processor on Customer’s behalf (e.g. for Session content, live-session media, or API Capture requests), Data Subject requests should be directed to the Customer (Controller). Driftstack assists Customer in responding, per DPA Section 3.6.

Right to lodge a complaint with a supervisory authority (Article 77 GDPR): Data Subjects may lodge a complaint with the Autoriteit Persoonsgegevens (Dutch DPA), Postbus 93374, 2509 AJ Den Haag, the Netherlands; or with the supervisory authority of the Data Subject’s habitual residence.

11. Data Protection Officer / Privacy Contact

Driftstack has assessed its DPO obligations under Article 37(1)(b) GDPR and concluded that, at current scale, the threshold for mandatory DPO appointment is not met. Driftstack has documented a threshold-based policy: a DPO will be appointed when:

1. Total monthly active sessions across the Service exceed 1 million; or
2. Any single Customer’s monthly Sessions involve regular and systematic monitoring of more than 5,000 unique Data Subjects; or
3. The Autoriteit Persoonsgegevens issues guidance applying the Article 37(1)(b) threshold to similar services.

Until then, Driftstack designates a Privacy Contact responsible for fielding privacy queries and coordinating Driftstack’s response to Data Subject requests:

• Privacy Contact: [email protected]

The Privacy Contact monitors threshold conditions and triggers DPO appointment when applicable. The threshold policy is reassessed on each annual review of this Privacy Policy.

12. Security

Driftstack implements technical and organisational measures appropriate to the risk under Article 32 GDPR. The measures are documented in detail in the DPA Annex 2. Summarised:

1. Encryption in transit: TLS 1.2+ for all API and Service traffic.
2. Encryption at rest: disk-level encryption on the Postgres primary; application-level encryption for Customer-Provided Secrets.
3. Access control: role-based access to production systems; principle of least privilege; production access logged.
4. API authentication: scrypt-hashed API Keys; revocable; scoped.
5. Audit logging: structured Pino-formatted JSON logs with request id correlation; admin actions audit-logged separately.
6. Backup: Postgres point-in-time recovery for the most recent 7 days, plus encrypted nightly backups kept off-site for up to 40 days.
7. Vulnerability management: dependency security scanning; coordinated disclosure mechanism.
8. Incident response: documented runbook; incidents are handled by Driftstack’s founder, with automated monitoring and alerting.

13. Breach notification

Where Driftstack identifies a Personal Data breach within the meaning of Article 4(12) GDPR:

1. Notification to the supervisory authority. Driftstack notifies the Autoriteit Persoonsgegevens (or the lead supervisory authority if different) within 72 hours of becoming aware of the breach, where the breach is likely to result in a risk to the rights and freedoms of natural persons. Where notification is not made within 72 hours, the notification is accompanied by reasons for the delay (Article 33(1) GDPR).
2. Notification to Customer (where Driftstack is Processor). Driftstack notifies Customer without undue delay (target: within 48 hours of becoming aware), per the DPA Section 6.1.
3. Notification to Data Subjects (where Driftstack is Controller and Article 34 applies). Driftstack communicates the breach to affected Data Subjects without undue delay where the breach is likely to result in a high risk to their rights and freedoms, subject to the exceptions in Article 34(3).

14. Children

The Service is not directed to and is not intended for use by children. Driftstack does not knowingly collect Personal Data of children under 16 (or the equivalent threshold of the Data Subject’s jurisdiction). If Driftstack learns it has collected Personal Data of a child, Driftstack deletes the data without undue delay.

15. When this Privacy Policy changes

Before Launch, a change to this Privacy Policy takes effect when it is published. After Launch, Driftstack tells Customer about a material change at least thirty (30) days before it takes effect, by email to Customer’s billing contact; any other change takes effect when it is published. Changes to the Sub-processor list follow Section 3.4 of the DPA.

16. Contact

For all matters relating to this Privacy Policy:

• Privacy: privacy@driftstack.dev
• Legal: legal@driftstack.dev

End of Privacy Policy.