Privacy Notice - development preview

UNREVIEWED DEVELOPMENT DRAFT.

DevGrail is not live yet. This document is a placeholder for testing the privacy notice display. A reviewed privacy notice will replace this text before launch.

The installation heartbeat

Every DevGrail installation reports to the DevGrail site it was installed from. This report is called the heartbeat. It cannot be turned off.

Why. The heartbeat tells the DevGrail provider that an installation exists and which release it runs. It also delivers the installation's acceptance of the Operator Agreement, so the provider has a record that the terms were accepted. The provider also checks that an installation applies the plan document it was sent, to administer the agreed subscription limits and investigate possible circumvention. A mismatch flag prompts human review; it does not itself change the subscription or stop work.

Proposed legal basis for the plan check, subject to legal review. Where the heartbeat identifiers and plan-check records are personal data, this draft proposes legitimate interests in administering agreed subscription limits and preventing misuse (GDPR Article 6(1)(f)). Before production use, the provider must assess necessity and the balance with affected people's rights and interests, including their reasonable expectations and right to object. A lawyer must confirm or replace this proposed basis and complete the notice's controller, contact and rights information. This development draft does not establish a lawful basis by itself.

When. Nothing is sent until an administrator accepts the Operator Agreement. After that, the installation sends a heartbeat each time the DevGrail server starts and then about once every 24 hours. An administrator can also send one by hand.

What a heartbeat contains, and nothing else:

protocol_version: the version of the report format.
installation_id: a random ID created when DevGrail was installed, or when an administrator started a new installation identity.
instance_id: a random ID for this copy of the installation, so a copy restored on another server can be told apart.
run_id: a random ID for this start of the DevGrail server.
report_id: a random ID for this report, so one sent twice counts once.
sequence: the number of this report within the run.
release: the DevGrail release, such as v1.4.0.
os: the operating system, such as linux.
arch: the CPU architecture, such as amd64.
entitlement_sha256: a checksum of the plan document the installation received, which tells the DevGrail site whether it applies the document sent; empty when no document is stored.
entitlement_applied: which part of that document applies now (current, next or fallback), or none before the first document.

What an Operator Agreement acceptance contains: the document's type, version, language and SHA-256 checksum, when it was accepted, that the administrator declared authority to accept it, and a random event ID. It does not say who accepted.

A random credential, created with the installation ID, proves that reports come from the same installation. The DevGrail site stores only a hash of it. If an administrator starts a new installation identity, because the old one can no longer report, DevGrail reports as a new installation and sends nothing that links it to the old one.

What is not sent: user names, email addresses, User Agreement acceptances, workspaces and their files, domain names, usage data and machine fingerprints. A plan billed by usage sends daily counts in a separate usage report, described below; the heartbeat itself never does. The DevGrail site does not store the IP address a report came from, in its data or in its logs, although network providers in between may process it to deliver the request.

Limiting registrations. So that one network cannot register new installations without limit, the DevGrail site counts the registrations that come from each IPv4 address, or from each IPv6 network of the size usually given to one customer (a /56), and refuses more than three in an hour. While it counts, it holds the address only in memory, and only as a keyed hash whose key is lost whenever the site restarts. It never writes the address to its data or its logs, and forgets it once the hour is over. Heartbeats and Operator Agreement acceptances are not counted this way. A refused registration does not affect the installation, which keeps working and tries again later.

What the reply contains. The site answers each registration and heartbeat with the installation's plan document: plan names and versions, limits, features, any end date and scheduled plan, the default plan to use after a long outage, with the release support status added to heartbeat replies (supported, outdated or retired). Registration does not report a release and its reply omits that status. It never includes prices. The installation stores the document locally so that plan changes can take effect while it is offline.

What is kept. Details of each server start are kept for 90 days after it was last seen. When an installation has not reported for 12 months, its release, operating system, architecture and when it was seen are removed. Its random ID and the hash of its credential are kept with its acceptance records, which are kept as evidence that the terms were accepted, so the installation can report again if it comes back; how long they are kept remains to be decided.

The provider also keeps a record of each plan document sent, its checksum, installation and instance IDs, issue time and the term it describes, for 31 days. A mismatch flag and the instance's consecutive mismatch state are kept until a matching heartbeat clears them or an administrator dismisses them. The subscription history records when a flag was set, cleared or dismissed; its final audit retention remains for legal review with the other contractual records. A heartbeat retry does not count as another mismatch.

Seeing it. Every user can read this description on the Agreements & privacy page. Administrators can see the last heartbeat exactly as it was sent on the Administration page, under Installation reporting.

The usage report (plans billed by usage only)

Why. Some plans are billed by usage, for example per enabled user account. For an installation on such a plan, the usage report gives the DevGrail provider the counts the charge is calculated from.

Proposed legal basis, subject to legal review. Where the counts are personal data, this draft proposes that sending them is necessary to perform the contract with the operator that chose a plan billed by usage (GDPR Article 6(1)(b)), and that keeping them is necessary for billing and accounting obligations. A lawyer must confirm or replace this basis.

When. Only while the installation's plan is billed by usage. The installation counts every hour and sends a usage report after each heartbeat, with the completed days it has not sent yet. An installation on any other plan sends no usage report and counts nothing for one.

What a usage report contains, and nothing else:

protocol_version: the version of the report format.
installation_id: the same random ID the heartbeat sends.
report_id: a random ID for this report, so one sent twice counts once.
days: for each completed day (UTC) not sent yet, the day, the meter (users) and that day's highest number of enabled user accounts.

It contains no user names, email addresses or other details of the accounts it counts, and nothing about workspaces or what anyone does in them.

What is kept. The DevGrail site keeps the daily counts of the days on which the installation's plan was billed by usage, for as long as billing records must be kept; that period remains to be decided with the accountant. A count received for a day the plan did not bill is not kept. Each report's random ID is kept for 31 days, so a report sent twice counts once. The installation keeps its own daily counts for 62 days.

Seeing it. Administrators see whether the plan is billed by usage, and exactly what is sent, under Settings, Plan, and the last usage report exactly as it was sent under Administration, Installation reporting.

Review before launch

This minor version introduces the purpose of checking applied plan documents, the two entitlement fields, plan replies and delivery retention, and the usage report of plans billed by usage: its daily account counts, their purpose, retention and proposed contractual basis. It must be reviewed with Operator Agreement 1.2.0 before publication, especially the proposed legitimate-interests basis and the handling of objections, and the basis and retention of usage counts. No workspace counts are introduced by this version.

Legal review reference: GDPR Articles 6 and 21.