Privacy, made visible.
Draft — requires legal review before publication. This notice describes the software as built. Counsel has not reviewed it, and hosting arrangements, legal bases and final wording must be confirmed before launch. It is not a certification or a guarantee of legal compliance.
What Blokk processes, why, for how long, and who is responsible for it.
Who is responsible
Blokk has two roles, depending on whose information it is.
- Controller for early-access requests made on this website, operator console accounts, and the security records that protect both.
- Processor for information about visitors to a customer’s website that Blokk assesses on that customer’s behalf. The customer is the controller: it chooses which actions to protect and what to do with each result, and its own privacy notice should explain this to its visitors. This processing is governed by a data processing agreement with the customer.
These roles describe what each party actually does with the information, not only what a contract calls it. Blokk acts as processor for customer websites only while it uses their information on that customer’s instructions to provide the service.
Work Anywhere VOF
97 Niewstraat, Essen 2920 Belgium
g@blokk.bot
Blokk’s intended website address is blokk.bot.
On customer websites: Blokk as processor
A customer chooses important actions—such as a form, a signup or a costly request—and integrates Blokk into them. When integrated as documented, Blokk processes the following for each protected action.
| Information | Details | Kept for |
|---|---|---|
| Browser observations | Only if the customer loads the optional browser script. By default: its version and whether the browser reports automated control (navigator.webdriver: true, false or not available). Interaction telemetry is off by default. Only during a documented telemetry experiment that the customer’s server configures does the script also record which of four interaction types occurred—pointer, keyboard, touch, scroll—as presence only, never keys, positions or individual events, and the time since the script started, in one of five ranges from under 1 second to over 2 minutes. Technical identifiers for the attempt accompany them. If the customer uses submit-only mode, the script puts the default observations in the form and the customer’s server passes them on. | Raw observations and the sealed receipt: 7 days after collection, or less if their attempt is deleted first. |
| Request context | Sent by the customer’s server: action name, route identifier and method; the browser’s user-agent string (up to 512 characters); the expected page origin; a form or submission identifier; an idempotency key, which Blokk stores only as a keyed hash; a session binding, which Blokk stores only as a keyed hash (HMAC); optionally a network identifier—a keyed hash of the visitor’s IP address computed by the customer’s server with the customer’s own secret, specific to one site and one UTC day; optionally an account reference—a keyed hash of the signed-in account’s identifier, computed by the customer’s server with the customer’s own secret and specific to one site; and, during a telemetry experiment, the experiment’s name. Blokk does not receive the visitor’s IP address or account identifier from the customer’s server. | Attempt records: session binding and submission identifier removed after 7 days; the record is deleted after 30 days. To recognise a retried assessment, Blokk keeps keyed hashes of its idempotency key and of the whole request, which includes the session binding and any account reference; they are unique to that request, link nothing and are deleted with the assessment. |
| Connection data | When the browser script sends observations, the visitor’s browser connects to the Blokk API directly, so the API receives its IP address. It is used in memory to derive rate-limit keys—keyed hashes specific to one day and one limit, with IPv6 addresses grouped by /64. It is not stored in the database, written to application logs or used by detection rules. | Rate-limit records: minutes for per-minute limits, up to 2 days for daily limits. Any connection logs kept by the hosting provider or reverse proxy: to be confirmed for each deployment. |
| Assessments | The result for each action: automation assessment, evidence availability, integrity and the reason it was not valid, integration mode, the reasons and rule versions behind them, processing time and policy mode. Detailed features are kept alongside: the browser observations, user agent, route, and short-window action counts and timings for the same session, network and account, with the session, network and account identifiers. Blokk stores the account reference only after hashing it again with its own key. | The site’s assessment retention: 30 days by default, configurable from 7 to 180 days (pilots typically use 90). Detailed features: the site’s feature retention, 7 days by default (1–180, never longer than assessment retention). Session, network and account identifiers are always removed after the feature retention period. Action counters are deleted within minutes. |
| Confirmed outcomes and review labels | Outcomes the customer reports later: confirmed unwanted, legitimate or unresolved; how it was established, from a fixed list (such as manual review, payment dispute or appeal review); the action the customer took, from a fixed list (such as none, account suspended or content removed); when it was determined; and an idempotency key, stored only as a keyed hash. There is no free text. Only confirmed unwanted or legitimate counts as a confirmed outcome: an action such as a suspension does not. Operators may also label an assessment and add a short review note, which should not contain personal data. | An assessment with a reported outcome or a manual review label is kept, with its detailed features so it can be re-evaluated, until 365 days by default (configurable from 30 to 730) after its newest outcome or manual label. Outcomes are deleted with their assessment, or once older than that period. Session, network and account identifiers still follow the feature schedule. |
What Blokk does not collect
From protected actions, Blokk does not receive message bodies or other form contents, names, email addresses, passwords, account identifiers, or the visitor’s IP address from the customer’s server. The browser script does not read keystroke values, pointer paths, page contents, clipboard data, precise location, canvas, audio or font fingerprints, or extension lists, and it sets no cookies and uses no browser storage.
Blokk does not try to identify individuals or which AI agent acted, and it does not build profiles across websites: the identifiers it stores with assessments are specific to one site, and network identifiers change daily. An account reference links the actions of one account on one site; it cannot show that one person uses several accounts. The customer is responsible for deriving it on its own server from the account it has signed in, never from what a visitor submits. These identifiers are pseudonymous, not anonymous.
Customer data is not used across customers
In this release, information from one customer’s website is used only to provide the service to that customer. It is not used to improve Blokk for other customers: it does not train, tune or evaluate rules for anyone else, and no identifier stored with a customer’s events links activity across customers. The one exception is operational: the per-minute rate limits that protect the shared API count each connecting IP address across all sites, using keyed hashes specific to one day that are kept for about two minutes, never linked to an assessment and not used by detection rules. What carries over between customers is Blokk’s code, its detection rules and synthetic tests. Any future reuse would first need legal review and an update to this notice and to customer agreements.
Browser signal access
The optional browser script reads information from the visitor’s browser—the automation flag and, only during a customer-configured telemetry experiment, whether interactions occurred and the elapsed time—and sends it to Blokk. Under Article 5(3) of the EU ePrivacy Directive, and the national laws implementing it, reading information from a user’s device generally requires consent unless an exemption applies, for example where the access is strictly necessary for a service the user has requested.
Whether an exemption applies to Blokk’s browser signals is being assessed for each deployment; we do not claim that one applies. Customers, as controllers of their visitors’ data, are responsible for their own privacy notices and for deciding whether consent is needed before loading the script. The server-side assessment also runs without the browser script, with more limited evidence.
Shopify adapter processing
The Shopify monitoring alpha adds shop installation identity, granted scopes, encrypted platform credentials, consent-permitted event names and timestamps, pseudonymous session correlation, integration health and merchant policy audit records. Public browser observations cannot create an authenticated account identity or confirmed business outcome. No raw checkout fields, payment credentials, search text or complete page URLs are collected by the extensions.
Shopify authenticates merchants and signs platform webhook deliveries. Mandatory privacy events and uninstall are processed separately. Uninstall disables collection and access; shop redaction removes applicable shop records. Customer-specific data access and erasure must reflect the identifiers actually retained, with live-store verification required before onboarding.
Shopify event features and correlation records are retained for 7 days; assessments and event records for 30 days, subject to the existing reported-outcome retention rules. Webhook deduplication records are kept for 7 days. Privacy-request exports awaiting secure delivery are retained for up to 30 days. Platform credentials remain encrypted while authorised access is active and are revoked on uninstall. Optional order processing retains keyed order and customer references, not complete webhook payloads.
Consent may prevent or delay theme and pixel observations. The generic SDK’s default no-storage behaviour does not describe Shopify’s own browser APIs: the adapter uses store-scoped session correlation, not cross-store tracking. Missing evidence is not treated as automation. Shopify plan, permissions and activation limits are shown on the coverage page.
On this website: Blokk as controller
| Information | Details and purpose | Kept for |
|---|---|---|
| Early-access requests | Your business email, store URL, problem category, optional context, request date and handling status. Legacy enquiries may also contain a name. An optional, separate product-update opt-in is recorded only when selected. Used to respond to you and run the design-partner programme. Website addresses are never fetched or scanned automatically. | 90 days from your original submission. Repeat submissions and status changes do not extend it. |
| Form abuse protection | A keyed hash of your IP address when the deployment passes it from a trusted ingress; otherwise a shared, anonymous limit. | Rate-limit records: minutes. |
| Visiting the pages | No cookies, analytics, remote fonts or third-party scripts. The sample inspector on the home page runs in your browser and does not assess you. | Nothing stored. |
Operator console: Blokk as controller
| Information | Details and purpose | Kept for |
|---|---|---|
| Operator accounts | Email address, workspace membership and a password stored only as a scrypt hash. Used to provide and secure console access. | While the account and its workspace exist, unless deleted. |
| Sessions and sign-in protection | A first-party session cookie and a hashed session identifier. Sign-in rate limits use keyed hashes derived from the login email address and IP address. | Sessions: 12 hours. Rate-limit records: minutes. |
| Audit records | Which operator performed which action, such as signing in, issuing or revoking a site key, or changing site settings. | 365 days by default (configurable from 30 to 730), the same as confirmed outcomes, so changes made during a pilot stay auditable. |
| Site credentials | Site API keys, stored only as hashes with a short identifying prefix. | While the site exists. |
Internal test website
Blokk’s separate test website, Northstar Studio, is a fictional business. It stores the names, emails and messages entered in controlled tests in its own database for 7 days. Testers should use fictional details. Scenario test runs and fixture labels in the detector are kept for 30 days and never extend how long an assessment is kept.
Purposes and legal bases
Proposed legal bases, to be confirmed in legal review:
- Early-access requests: steps taken at your request, and our legitimate interest in responding to enquiries about the alpha.
- Operator accounts, sessions and audit records: performing our agreement with the customer, and our legitimate interest in securing access.
- Rate limits and security records: our legitimate interest in protecting the service and its users from abuse.
- Customer websites: the customer determines the legal basis as controller; Blokk processes only on its documented instructions.
Assessments are signals for the customer’s own review and policy. They should not be the sole basis for a decision with legal or similarly significant effects on a person.
Recipients and subprocessors
Hosting: DigitalOcean, AMS3, Netherlands
There are no other subprocessors configured for the core assessment service. Blokk uses no analytics, advertising, email-delivery, hosted-form or third-party bot-scoring or enrichment services; detection runs on its own rule engine. Shopify supplies platform authentication and event delivery for its adapter; its role and applicable transfer terms need review for the pilot. Customers see assessments and outcomes only for their own sites. We do not sell personal information, and we disclose it to authorities only where the law requires.
International transfers
Core storage runs in the configured hosting location. Shopify’s platform has its own processing arrangements. The actual locations, recipients and any international-transfer safeguards must be confirmed before a pilot; this draft does not promise that all data remains in one jurisdiction.
How information is protected
Identifiers are pseudonymised with keyed hashes, passwords are hashed with scrypt, and generic API keys and operator session identifiers are stored only as hashes. Shopify platform credentials must remain recoverable for API access and are stored encrypted, restricted to their shop. Secrets stay on servers. Console access requires authentication and is limited to one workspace. Retention jobs delete data automatically while the API runs. Traffic is encrypted in transit where the operator configures TLS. We hold no security certifications and have not commissioned third-party audits.
Your rights
Depending on where you live, you may have the right to access, correct or delete your information, to restrict or object to its processing, to data portability, and to withdraw consent. You can also complain to a data protection supervisory authority.
For information collected on a customer’s website, please contact that website first: it is the controller, and Blokk will help it respond. Because Blokk stores keyed hashes rather than names or contact details for those actions, it may be unable to find records relating to you without information from the customer.
For early-access requests and operator accounts: g@blokk.bot
Cookies and browser storage
The marketing pages set no cookies and use no browser storage. The operator console uses a first-party session cookie that is strictly necessary for sign-in. The Blokk browser script sets no cookies and uses no browser storage. The test website uses first-party session cookies for form integrity.
Deletion and backups
Operator-only commands support early-access export and deletion, test-data deletion and retention cleanup. Backups must follow the same deletion policy; restoring an old backup can reintroduce records until the retention job runs again. A detailed table-by-table data inventory is maintained with the source code.
Changes to this notice
Before publication, the operator must confirm its identity and contact details, hosting and location, processing roles, legal bases, backup policy and the final text. This draft makes no legal guarantees.
Back to Blokk