Interlinked - The Cube

Data Processing Agreement

The Article 28 contract between a gallery and the operator. The gallery is the controller. The operator is the processor. This is owed by us to you.

Version 2026-09-11.1 In force from 2026-09-11 Operator see below

How to accept this

This agreement applies automatically to every account and forms part of the Terms of Service. Opening an account, or continuing to use one after the version below takes effect, is acceptance of it. A customer who needs a signed counterpart, or its own paper, should write to stoiana00@gmail.com.

1. The roles, stated plainly

There is a short list on which we act as controller rather than processor, and it is deliberately separate from everything above: your staff's own user accounts and sign-in sessions, the security and integrity of the service, and the record of data-rights requests we are required to keep. That processing is described in the Privacy Notice and is not governed by this agreement.

2. Our obligations as processor (Article 28(3))

1. Only on your instruction. We process personal data only on your documented instructions, including on transfers, unless a law we are subject to requires otherwise, in which case we tell you before processing unless that law forbids it. Using the software as it is documented is an instruction.
2. Confidentiality. Everyone we authorise to process the data is bound to confidentiality.
3. Security. We apply the measures in Annex II, which are the measures actually implemented in the software and not an aspiration.
4. Sub-processors. You give general authorisation for the sub-processors in Annex III. We tell you at least 30 days before adding or replacing one, and you may object; if we cannot resolve an objection, you may terminate for the affected part of the service without penalty.
5. Helping you answer data subjects. The software already does most of this: an export produces a collector's real rows, and an erasure destroys their viewing record. Where a collector comes to us directly, we execute what we hold the levers for and refer the rest to you, because it is yours to decide. See clause 4.
6. Helping you with Articles 32 to 36. We assist with security, breach notification and any data protection impact assessment, taking account of what we can see, which is the infrastructure rather than your reasons for contacting a person.
7. Deletion or return at the end. On termination you may export for 30 days; after that we delete your workspace and everything in it, unless a law requires us to keep something, in which case we say what and why.
8. Proof. We make available the information needed to demonstrate compliance with this clause and allow audits, on reasonable notice, no more than once a year unless an authority or an incident requires otherwise.

3. Your obligations as controller

• You warrant that you have a lawful basis for every person you add and every room you send, and that the basis covers a viewing record being kept. We have no way to verify this and do not.
• You are responsible for the accuracy of the contact records you enter, and for informing people as Articles 13 and 14 require. Our consent screen and Privacy Notice help, but they are not a substitute for your own relationship with the person.
• Your instructions must not require us to break the GDPR. If we think an instruction does, we will tell you and may decline it.
• You must not switch off, obscure or work around the consent screen, and must not present the measurement to collectors as something other than what it is.

4. When a collector comes to us directly

A collector can ask us for their data or for erasure through our own form, and we verify the address before anything happens. What we then do is split along the same line as the roles:

• We act, without waiting for you, on everything that exists only because of our tooling: the visits, the dwell measurements, the zooms, the marks, the hashed IP, the browser string, and the viewing-room links, which we revoke. This is a standing instruction you give by accepting this agreement, and it exists because a person waiting weeks for a gallery's reply while being measured daily would be an unacceptable answer.
• We anonymise, we do not destroy, your business record. Their name and address in your contact list are blanked. The enquiries they sent you, and the threads that followed, stay as your own commercial record, now attached to a contact that names nobody. We will not destroy your sales history on a third party's form.
• You decide about the correspondence. If you conclude that an erasure request reaches it too, you can have it purged, and the software does it (POST /api/v1/gdpr/erase-contact with purgeCorrespondence: true, available to an owner or manager). That is your Article 17 assessment to make, not ours.
• We tell you that the request happened and what was done, and we keep a record of it so that both of us can prove it.

5. Breach

We notify you without undue delay after becoming aware of a personal data breach affecting your data, with what we know at the time and updates as we learn more. The 72-hour notification to the supervisory authority under Article 33 is yours to make, as controller; we give you what you need to make it.

6. Transfers

Data is stored in the European Union. A sub-processor in Annex III that is established outside it processes on the basis of the European Commission's standard contractual clauses together with any additional measures the transfer requires. The exact instrument for each is listed in docs/LEGAL.md as a point for legal review before this agreement is used with a paying customer.

Annex I, the processing

Subject matter and duration

Providing the private viewing-room service described in the Terms, for as long as the account is open, plus the export window and the retention periods in Annex IV.

Nature and purpose

Storing a gallery's inventory and contacts; delivering time-limited viewing-room links; recording and aggregating what a collector does inside a room; carrying enquiries and the conversations that follow.

Categories of data subject

• Collectors and other people a gallery sends a viewing room to.
• People who write to a gallery through a room without having been sent one.
• The gallery's own staff who hold accounts (as to whom we are controller, not processor).
• Artists, whose name, email and biography a gallery may store.

Categories of personal data

No special categories. Nothing in this product asks for or is designed to hold data under Article 9 or Article 10. A collector could type anything into a free text enquiry, and the gallery should not invite them to.

Annex II, security measures

• Passwords hashed with argon2id; never stored, never recoverable.
• Session tokens held only as SHA-256 in the database, so a stolen dump cannot be replayed as a live session. The same pattern for password reset and for data-request verification links.
• Every query for gallery data is filtered by the gallery id resolved from the session; there is no unscoped read of works, rooms or contacts.
• Every action a collector can take is re-checked against the room their token opened, so a forged payload cannot attach attention, a mark or an enquiry to another gallery's work.
• Viewing-room tokens are unguessable, revocable, expirable and limitable to a number of visits.
• IP addresses are stored only as a salted, truncated hash, and blanked after 90 days.
• Transport encrypted with TLS; HSTS set on production responses.
• Content security policy, nosniff, frame denial and a strict referrer policy on every response, so a room token in a URL is not leaked in a referer header.
• Rate limiting on every credential and data-rights endpoint.
• Backups of the database, encrypted at rest with the storage provider.
• Input validated with a schema before it reaches the database; no query is built by concatenating user input.

Two honest gaps, recorded here rather than left for an auditor to find: the content security policy still permits inline scripts, which the build requires today and which nonces are the documented fix for; and rate limiting is held in the process rather than shared, so it multiplies if the service is ever run as more than one replica.

Annex III, sub-processors

Annex IV, retention