sigill.ai

Google Drive Add-on Privacy Policy

What the Google Workspace add-on "Sigill for Google Drive" can access, what it sends to Sigill, what Sigill stores, and what it never receives. This notice is written to match what the add-on actually does. If a claim here does not match its behaviour, write to contact@sigill.ai and we will correct it. For the sigill.ai platform itself, see the main privacy policy; setup is described in Connect Google Drive.

ControllerSigill AS
Organisation number937 798 970
Registered officeArne Garborgs veg 21, 7071 Trondheim, Norway
Applies toSigill for Google Drive (Google Workspace add-on)
Versionv1.4
Effective2026-10-19

Summary

The add-on lets people in your Google Workspace add timestamps and advanced electronic seals to Drive files as your Sigill organisation, and check that evidence later. Your files never leave Google. The add-on sends Sigill only a file's cryptographic digest (SHA-256, and SHA-512 for post-quantum seals) and its name. Whenever the add-on needs a file's content — to compute a SHA-512, or to export a Google Doc, Sheet, Slides or Drawing — that happens inside Google, and the content is not sent to Sigill. Google's own formats have no file to seal, so the add-on saves the export (PDF, or Excel for Sheets) next to the original and seals that copy. The evidence (.tsr / .p7s) is saved as a new file too, and so is a sealed PDF (a copy with the seal inside), which the add-on assembles inside Google. The add-on never changes, moves or deletes your files.

What the add-on can access in Google

The add-on requests these permissions (OAuth scopes) and no others:

  • Only files you allow (drive.file) — Drive opens nothing to the add-on until you click Allow for this file on a file. Beyond those, it can only see files it created itself (your evidence files). It cannot browse, search or read the rest of your Drive.
  • The item you select (drive.addons.metadata.readonly) — the name and type of the file selected in Drive, so the panel can show it.
  • Your identity (openid, userinfo.email) — Google issues a signed identity token with your Google account id, email address and Workspace domain; it is how Sigill knows you belong to the connected organisation.
  • Connecting to Sigill (script.external_request) — to call api.sigill.ai and Google's own Drive API.

From the files you allow, the add-on reads metadata (name, type, size, folder and Drive's SHA-256 checksum). It reads content only to compute a digest inside Google, as described above, and exports Google Docs, Sheets, Slides and Drawings inside Google — also when you select one later, to compare it with its saved export. To find existing evidence for a file, it lists files in the same folder — which, under drive.file, returns only files you allowed or the add-on created.

What the add-on writes in Google

  • New evidence files — a .tsr (timestamp) or .p7s (seal) in the same folder as the file. It never updates, overwrites, moves, trashes or deletes any file, including its own.
  • Exports of Google Docs, Sheets, Slides and Drawings — when you timestamp or seal one, a new PDF (or Excel file, for Sheets) in the same folder, named after it, for example Contract (PDF export 2026-10-18 09.30 UTC).pdf. It is the file the evidence proves. The add-on creates it only after Sigill has issued the evidence.
  • Sealed PDFs — when you choose Create sealed PDF, a new copy of the PDF (or of a Google file's PDF export) with the seal inside, in the same folder, for example Contract (sealed 2026-10-18 09.30 UTC).pdf. Its private properties record that it is a sealed copy, of which file, the Sigill evidence id and the time.
  • Private properties on those files — on evidence: the Drive id of the file it proves, its SHA-256, the kind of evidence, the Sigill evidence id and the time; on exports: the Drive id of the Google file, a SHA-256 fingerprint of its PDF export and its last-modified time and version at export, the format and the time. They link evidence, export and original and are visible only to the add-on.
  • Per-user storage inside Google, private to you: your short-lived Sigill token (at most one hour) in Apps Script PropertiesService and CacheService, and recent verification results (up to six hours) in CacheService.

What the add-on sends to Sigill

  • Your Google identity token, once per token, in exchange for a short-lived Sigill token that can only timestamp, seal and list the seal certificates your organisation may use. Sigill verifies the token's signature with Google's public keys and accepts it only for a Workspace domain that a Sigill organisation has verified and connected.
  • To timestamp or seal: the file's SHA-256 (and SHA-512 for post-quantum seals), the file name as the evidence label, and the options you chose (certificate, qualified timestamp, post-quantum).
  • To create a sealed PDF: the SHA-256 of the bytes the seal covers (the PDF with an empty signature field added inside Google), the name of the sealed copy as the label, the certificate and the qualified-timestamp option.
  • To check evidence: the file's current SHA-256 (and SHA-512 for post-quantum seals) together with the .tsr or .p7s evidence file. The evidence file contains no document content.
  • To check a sealed PDF: the SHA-256 of the bytes the seal covers and the signature taken from the PDF. The signature contains no document content.

What Sigill stores

When an owner connects Google Drive (Settings → Apps), Sigill stores the connection: your organisation's verified domain, which Sigill user connected it, and when; when it was last used, and when it was disconnected.

When someone uses the add-on, Sigill stores, from Google's signed identity token:

  • the Google account id, email address and Workspace domain of the person;
  • a SHA-256 fingerprint of the identity token (to make each token single-use) and the time of the exchange.

These are shown to your organisation as the evidence's Issued by record, so you can see who in your Workspace issued it. The evidence itself — the digest, the label, the timestamp token or seal and its renewal chain — is stored as for any other evidence in your organisation, as described in the main privacy policy. Checking evidence creates no evidence and stores no result; it uses your Sigill token, whose exchange is recorded as above.

What Sigill never receives

  • Your files or their content — Drive files, Google Docs, Sheets, Slides or their exports. Only digests.
  • Google credentials. Sigill holds no Google access or refresh token and cannot call Google on your behalf. The identity token is verified and discarded; only its fingerprint is kept.
  • Anything about files you have not allowed the add-on to open.

Who Google user data is shared with

By Google user data we mean what the add-on obtains through Google: your Google account id, email address and Workspace domain (from Google's identity token), the names of files you timestamp or seal (used as evidence labels), their digests, and the evidence files. Sigill shares, transfers or discloses it only as follows:

  • Your own Sigill organisation — its owners and members see the evidence your organisation issued, with its label (the file name) and who issued it.
  • Amazon Web Services — Sigill's hosting provider and sub-processor, in the EU (Stockholm, eu-north-1), under a data processing agreement. It stores and processes the data on Sigill's behalf only.
  • Timestamp authorities — the trust service providers that issue timestamps (for qualified timestamps, providers on the EU trusted list) receive only a digest to timestamp, as RFC 3161 requires: no file name, no identity, no file content.
  • Authorities — only where the law requires it, for example a court order; where permitted, we tell your organisation first.

Nothing else. Google user data is not sold, not shared with advertisers, data brokers or other third parties, and not used to train AI or machine-learning models. Sigill staff access it only to support your organisation at its request, to investigate security incidents, or where the law requires it. Evidence files saved in your Drive, and anything you choose to share yourself, remain under your control. If Sigill is ever involved in a merger or acquisition, the data stays subject to this policy and your organisation will be told before anything changes.

How Google user data is protected

  • Minimisation — file content never leaves Google: Sigill receives digests, never files. Google's identity token is verified and discarded; only its SHA-256 fingerprint is kept, to make it single-use. Sigill holds no Google access or refresh tokens and cannot call Google on your behalf.
  • Encryption in transit — every connection between the add-on, Google and Sigill uses HTTPS with TLS 1.2 or 1.3.
  • Encryption at rest — Sigill's database and its backups are encrypted (AES-256, AWS-managed keys). Seal signing keys live in AWS Key Management Service hardware security modules and never leave them.
  • Access control — each organisation's data is isolated from every other organisation's on every request. The add-on's Sigill credential lasts at most one hour, can only issue evidence and list the organisation's seal certificates, and stops working the moment the connection is removed or the domain loses its verification.
  • Inside Google — the add-on opens only files you explicitly allow (drive.file), and keeps its short-lived credential in storage private to your Google account.
  • Operations — data is hosted only in the EU; logs identify records by internal ids, never by email address or file name; security-relevant actions are recorded in an audit log; backups are kept for seven days. Security issues can be reported under our responsible disclosure policy.

Google API Services User Data Policy

Sigill's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Data from Google is used only to provide the add-on's features described here. It is not sold, not used for advertising, not used to train AI or machine-learning models, and not read by people except with your consent, for security investigations, or where the law requires it.

Calls Sigill makes to Google

Sigill's servers fetch Google's public signing keys (accounts.google.com) to verify identity tokens. They make no other calls to Google: everything that touches your Drive runs in the add-on, inside Google.

Where data is stored, and for how long

Data is stored on the sigill.ai platform in the EU (AWS, Stockholm, eu-north-1); see sub-processors. Google is your own provider, not a Sigill sub-processor. The connection is kept until you disconnect it or delete your Sigill organisation. The Issued by record is kept as long as the evidence it describes, and is deleted with your organisation. Disconnecting, or losing your domain verification, stops the add-on from issuing evidence immediately. Uninstalling the add-on removes it from Drive; evidence files already saved in Drive stay yours.

Legal basis and your rights (GDPR)

The processing is necessary to provide the service your organisation signed up for (Art. 6(1)(b) GDPR), and to keep a trustworthy record of who issued evidence on its behalf (Art. 6(1)(f)). The rights and contact points in the main privacy policy apply, including access to and erasure of the email address recorded with evidence you issued. Complaints may be directed to Datatilsynet (the Norwegian Data Protection Authority) or your local supervisory authority.

Changes and contact

Material changes are versioned on this page. Questions and corrections: contact@sigill.ai. Security reports: security@sigill.ai (responsible disclosure).