← Back to site

Privacy Policy

OpenStamps for Industry · Protosonic OÜ · Estonia · last updated 25 September 2026

1. Who is controller, surface by surface

The same person's data can sit on several surfaces with a different responsible party on each. This table is the map; the sections below give the detail. "Local" means the bytes never leave the device they were made on.

2. The farmer's record — what a farmer is owed under Art. 13, in plain words

If you are a farmer, forest owner, cooperative officer or agent using the plot page from a buyer's link, this is what you should know before you press Send.

• Who asked for it. The buyer named on the page. That buyer is the controller of the record you make for it; we are not, and nothing you record on the page reaches us except a fingerprint at seal time and, when you press Send, the deposit to the buyer's mailbox (section 3). One thing reaches us before that: when the link you were sent holds only the request code (the short link a text message carries), the page asks the buyer's mailbox for the request's own words as it opens — who is asking, for which product and in which language. That request carries the code and, as every web request does, your phone's network address; nothing you have recorded goes with it.
• What it contains. The map of your plot (a point or a shape), whether the trees were planted or natural, the species, the country, the quantity if you declared a harvest, the time your phone said it was, a photo only if you chose to attach one, and a code that identifies this phone. That phone code is a persistent identifier: records made on the same phone can be linked to each other.
• Why the buyer needs it. EU Regulation 2023/1115 obliges the buyer to hold the location of every plot its wood came from and to keep that for at least five years. That legal duty is the buyer's basis for asking; a photo or a plot name beyond it rests on the buyer's interest in evidence that can be checked and on your choice to add it.
• Where it goes. To the buyer's own files on the buyer's own computer. The buyer files a statement in the EU Information System that carries your plot's location; authorities in the country the furniture is sold in can see that statement.
• How long. Your phone keeps a copy for 90 days and then removes it; a record you never sent is never removed by us. The buyer keeps it for at least five years.
• What it proves and does not. A stamped record fixes what you declared and when. It does not prove your harvest was legal, that the forest was not cleared, or that a photo shows this plot or came from a camera.
• Your rights. To see, correct, withdraw or complain about the record, contact the buyer named on the page; a sealed record cannot be edited, but it can be withdrawn by an amendment record, and the buyer can delete it from every store it controls. You may also complain to your national data-protection authority or to the Estonian Data Protection Inspectorate about our part (the mailbox).

This notice is in English here; the plot page shows its short form in the language you chose.

3. The hand-off mailbox

Supplier hand-off (dds.html → field.html): a request link carries a random token; the supplier's phone posts the sealed plot record and its stamp to our same-origin /api/handoff/<token> mailbox (the EU-jurisdiction store named in §9, strong consistency), where it waits for the buyer's desk to collect it. A request expires 14 days after it was made (the buyer can choose 1–30): after that, the next touch of that token — a post, a pull, a request-summary read or a close — deletes the request and everything posted to it. There is no separate clean-up job: an expired entry that nobody touches again stays in the store, unread by us, until it is touched. The buyer's desk can close a request early, which deletes it at once. The mailbox holds the declared record and its seal; it cannot alter either and we do not read them. The token in the link can only post, and read the request summary below: collecting and closing need a separate desk key that the mailbox gives the buyer's desk alone and keeps only as a one-way digest, or the account that made the request, so one supplier holding the link cannot read another supplier's record. A request made without an account before this version of this notice keeps its earlier rule, under which its token could also collect and close it, until it expires (at most 30 days). Posts are counted against a hashed per-IP daily limit. Request summary: a plot page opened from a short link (the request code alone, as a text message carries it) reads /api/handoff/<token>/summary as it opens — the request's own words (the buyer's name, product, species, country, crop, language and expiry), never a deposit. That read carries the code and the phone's network address, and is counted, like posts and pulls, against a hashed per-network daily limit.

Roles. The buyer whose desk created the link is the controller; Protosonic is the buyer's processor for the mailbox, under a data-processing agreement attached to the buyer's order, and Netlify, Inc. (United States) is our sub-processor for storage. Retention is the 14-day (1–30) expiry above, applied when the token is next touched. Limits: 256 KB per deposit, 20 deposits per request, 30 requests created, 40 posts, 120 reads and a separate 120 request-summary reads per network per UTC day, declared-plot deposits only. Deposits are stored as posted, in the clear: "we do not read them" is a promise, not a lock, until deposits are encrypted to a key carried in the request link.

4. The due-diligence desk — on the operator's device, and, when signed in, a copy under the account

Due-diligence desk (dds.html), signed out: the operator's identity, product line, supplier and buyer contact details, plot geometry, evidence fingerprints, assessment and statement records stay in this browser's storage on your device; nothing leaves it. So do the sealed records a supplier sends you (with the word the supplier uses for each file it names) and the list of documents you asked each supplier for (since 25 September 2026); none of them goes into a statement or an authority pack. Sealing a record sends only its SHA-256 digest, with a fresh nonce, to the drand beacon operators and our /tsa/* relay, exactly as the stamp tool does. Exports are files you download.

Signed in — the desk syncs to the account (since 16 September 2026): after every save, seal, import or deletion the desk sends its whole bundle to /api/workspace, so the same desk is there on any browser you sign in on. What that bundle holds is what the desk holds: the operator record; every product with its supplier and buyer names, addresses and e-mail addresses, species and plot geometry; assessments, mitigations, statements and seals with their envelopes — never the files themselves. It is up to 2 MB, kept with the five previous versions before each overwrite, stored as sent in the EU-jurisdiction store named in §9, not encrypted on the device before it leaves (a passphrase on every browser is the friction sync exists to remove; a lock is a later option), and read by no code of ours: the server merges nothing and looks at nothing. For this copy the operator is the controller and Protosonic is the processor, under the terms. The account page shows the copy, its versions and a delete button; signed out, nothing is sent. Retention: on the device until you export or clear it — a cleared browser profile or a private window loses it, and the exported bundle is the record you keep for the EUDR five-year period; under the account until you delete the copy or close the account.

Saved companies — the one piece of desk data a function of ours reads. Signed in, the desk can keep company details under your account and fill its operator fields from them on any browser: for each company, the legal and trading name, one or more addresses, the registry code, the EORI and VAT numbers, a contact role and the e-mail and phone you typed. Unlike the desk bundle above, these are not stored-as-sent-and-read-by-nobody: the /api/companies function reads them to show them to your signed-in desk and to your own API key, and /api/stamp reads the one a call names, to write its names, numbers and the chosen address — never the contact — into that stamp's journal row, with the product and lot the call sent, if any. That row stays yours: in a team, the team's view of the journal lists your stamps to your teammates without the company, the product or the lot. An API key can read them and cannot change them. They are never sent to a timestamp authority, never put into a stamp or an envelope, never part of the nightly anchor, and never sent to anyone else; the list itself is never published. A fill only puts them into the desk's own operator fields, which are published, as before, only where you publish them. The numbers are checked for their shape only; nothing looks them up. They are usually a company's details; where a sole trader's name and home address, or a named person's e-mail, is typed they are personal data, and for them the operator is the controller and Protosonic the processor, under the terms. Retention: until you remove the company from the desk or close the account.

5. Statement filing — configured deployments only

Statement filing (dds.html, configured deployments only): the public site holds no Information System credentials, so its /api/dds/* function refuses every call. Where an operator asks for it, Protosonic operates a dedicated deployment that holds that one operator's Information System web-service key as your processor, in the deployment's environment configuration and never in the browser. When you press File, the statement you built (operator, product, quantity, plot geometry, supplier and reference details) is sent through that same-origin function to the EU Information System under your credentials. The Commission's conformance test is run on the acceptance environment before any production filing. The operator is the controller of the transmission, the European Commission is an independent controller of what the Information System receives, and Protosonic is the operator's processor. The function retains nothing; the deployment and its configuration are destroyed when the operator ends it.

6. The account, the payment and the meter

The account. Sign-in is a link sent to your e-mail address — the same message carries an 8-character code, which is how the OpenStamps app signs in, since no cookie of this site can reach a page served from the app — or Continue with Google or Continue with Microsoft; there is no password. Google and Microsoft sign-in are a top-level redirect to the provider and back: this site never loads either as a page script. The browser is sent to accounts.google.com or login.microsoftonline.com; token exchange and the address lookup run on our server (oauth2.googleapis.com and openidconnect.googleapis.com; login.microsoftonline.com and graph.microsoft.com). We receive the work e-mail the provider asserts for that account, and nothing else from that flow is used to set a plan or a price. A personal Microsoft account's address is verified by Microsoft; a work or school account's address is accepted only when Microsoft states that the organisation owns that e-mail domain, because a tenant administrator can otherwise type any address. There is no other door: no page of this site loads a sign-in script from a third party. In the app, the session is a signed value the app keeps on the device and presents as a header, never a cookie; signing out forgets it. Protosonic is the controller of the account data — your e-mail address, a signed session cookie, the plan, the period's included and used counts, the top-up balance and the one-sided count — processed to perform the contract with you (GDPR Art. 6(1)(b)). For the contents of the desk bundle — which, since 16 September 2026, the desk writes to the account by itself after every change while you are signed in, and reads back on every browser you sign into; the five versions before the latest write are kept alongside it — the operator remains controller and Protosonic is processor. It is stored as sent and read by nobody; it is not encrypted on your device before it leaves, and this page says so rather than implying otherwise. The journal. Since 16 September 2026 a stamp made from a signed-in browser, or through an API key, is also kept under the account: the sealed envelope (the SHA-256 of the file, a beacon round and the timestamp authorities' tokens over that digest), the purpose it was sealed under, the page it came from, and a name you may type — by default the file's name. Never the file, and never a place, with one exception: a stamp made through an API key that names a saved company also keeps, in its row, that company's names, numbers and chosen address — a place — and the product and lot the call sent (see Saved companies above). Stamps made on the farmer's page, or while signed out, are not journaled. Each entry can be renamed, downloaded or deleted from the account page; a deletion is immediate and final. The nightly anchor. Every night a hash of every journal entry (its id, content id, digest, sealing time and a hash of its envelope — never its name, never the account) is folded into one root across all accounts and that root is stamped and published at /api/anchors; the published anchor carries the root, a count, a beacon round and the authorities' tokens, and nothing that identifies an account or an entry. A deleted entry's hash remains in past anchors, which is what makes the anchor a proof of existence at a time. A published journey (/u.html?p=…) is what an operator chose to make public about one product from the desk: the sealed records ticked, their stamps, and what those records declare — a place, a time, a species. It carries no account and no person's name unless the operator wrote one into a record; on a Studio or higher plan it may also carry a brand kit the operator typed on the desk — a brand name, a colour, a tagline and a logo image of up to 32 KB — stored with the pack and served publicly with it until the operator clears it or withdraws the page; the link is a random token; the operator withdraws it from the desk at any time and the page goes with it. Anyone who scans the code fetches that pack and checks it on their own phone; we log nothing about who scanned. Managed renewal, on for paid plans unless switched off, appends a fresh timestamp token to an entry's renewal chain before its authority's key lapses; it reads the content id and the chain, never the file. Mail from us is off unless you switch it on there: a plain-text receipt when a stamp is recorded (its name, fingerprint, content id and beacon round — never the file, never a token) and a statement on the first of each month (last month's stamps by kind, the plan, the balance), both to the address on the account, through the same provider as the sign-in link, with no tracking. Switch either off on the account page at any time. Storage is the EU-jurisdiction object store named in §9 (stores osfp-accounts and journal); the sign-in e-mail goes through an e-mail provider if one is configured, and we will name it here on the day a deployment configures one. Without its configuration the account function answers 503 and does nothing. Retention: until the account is closed; the desk bundle and its kept versions are deleted when you delete them from the account page or close the account. Closing is a button on the account page: the journal, the desk and its versions, the saved companies, every API key and the account record are deleted at once. Two things remain: Stripe's record of what you paid — invoices are kept by Stripe and by us for the period Estonian accounting law requires, which is seven years — and a marker under the hash of your e-mail address saying that an account with it was closed, kept so the same address does not receive a second trial; it holds a date and nothing else.

The payment — Stripe is our processor, and it holds the customer record. Card details and Revolut Pay are entered on Stripe's own hosted checkout and billing portal, not on this site: we never see, receive or store a card number or Revolut credentials, and no payment page is served from here. Revolut Pay is a method on Stripe's pages; we are not a Revolut merchant and we have no separate Revolut account. Stripe Payments Europe, Ltd. (Ireland) acts as our payment processor and, for its own regulatory duties, as an independent controller. The data involved is your e-mail address, billing name and address, VAT identification number if you give one, and the status of your payments and subscription — that is all; we do not receive anything about the card itself beyond its brand and last four digits as Stripe displays them to you, and we do not receive Revolut account details. If you pay with Revolut Pay, Stripe shares what that method needs with Revolut under Stripe's own arrangements. Purpose: to take payment and to meet our tax obligations (GDPR Art. 6(1)(b) and 6(1)(c)); VAT determination is performed by Stripe Tax. Retention: Stripe keeps the customer record under its own policy; we keep what accounting and tax law requires us to keep, which in Estonia is seven years for the underlying documents.

The API key — we store a hash, never the key. A key is generated in your account and shown to you once. What is stored on the account record is a SHA-256 hash of it, with the label you chose, the time it was made and the time it was last used. We cannot show you the key again and we cannot recover it, because we do not have it; that is the point. Revoking a key marks the hash revoked. Retention: until you revoke it or close the account.

The vault — ciphertext, a salt and a check value; never a key, never a file. If you keep a stamped file in the vault, it is encrypted on your device (AES-GCM under a key derived on your device from your passphrase) before it is sent; what we store under your account is that ciphertext, the file's SHA-256 (which the stamp already commits), the name and size you gave it, the date it was stored, the retention date five years on, and whether you set a legal hold. We also store the salt the key derivation uses and a check value that lets your browser tell a right passphrase from a wrong one; neither yields the key. We cannot read a vaulted file, cannot recover a forgotten passphrase, and delete the vault with the account. A file you delete is gone from our store at once; a file under a legal hold cannot be deleted until you lift the hold.

The meter — counts, and nothing else. To bill for qualified stamps we keep, on your account record, numbers: how many qualified stamps the current period included, how many were drawn, how many top-up stamps remain, how many stamps went out one-sided, and when the period rolls. The meter never receives a record, a file, a fingerprint, a plot, a species, a supplier or a customer of yours. The relay it protects is the same pipe described in section 7: a digest with a fresh nonce passes through it and nothing is retained. Counting how many times you stamped tells us nothing about what you stamped, and that separation is deliberate.

7. The tools that keep your files on your device

Local evidence-pack handover. Choosing Continue to review or Edit a copy stores an unencrypted temporary copy of the pack, including its original attachments, in this browser's IndexedDB. No pack bytes are uploaded and the link contains only a random local reference. The destination removes the stored copy when opened. A handover stops opening after two minutes; abandoned copies are removed on the next handover-storage operation, or when you clear this site's browser data, not by a background timer. Download the pack and any review receipt to keep them. Optional stamping similarly passes the downloaded pack to the stamp tool on this device; only its fingerprint is sent to timestamp authorities when stamping.

• Browser stamp tool: file hashing and sealing run locally; we never receive your file. At stamp time the browser fetches the current public randomness round from the drand beacon operators (api.drand.sh, drand.cloudflare.com — no file data is sent) and, to close the time bracket, sends the file's SHA-256 digest (not the file) with a fresh nonce through our same-origin /tsa/* relay to two RFC 3161 timestamp authorities: freetsa.org and DigiCert (timestamp.digicert.com). The relay is a pipe — we do not retain the digest — and the TSA receives a digest it cannot reverse into your file. Verification sends nothing anywhere: it runs offline on your device.
• Plot or source declaration (try.html): if you allow it, the browser reads device GNSS in order to declare a point or polygon. An applicable micro or small primary operator may instead type a postal address or reference from an applicable official system for the simplified route. These details stay on your device unless you download an export or stamp the declaration (in which case only the SHA-256 of that JSON is relayed to timestamp authorities, same as any other file). Phone GNSS and eligibility for the simplified route are operator-declared fields; the stamp does not prove either claim. We do not receive a live location stream.
• Map tiles (opt-in): the chain map on try.html draws declared plots over a public-domain Natural Earth outline served from this site, so viewing it contacts nobody else. If you switch on Show OpenStreetMap tiles in the map legend, or press the map's own “show the map” button, your browser fetches map images directly from the OpenStreetMap Foundation (tile.openstreetmap.org), which then sees your IP address and which map areas you view; none of your files or records is sent. The switch is off on every load and remembered only for the browser session.
• Place search (you type it): the plot map's search box sends the words you type to our same-origin /api/geocode. That function asks the OpenStreetMap Nominatim service (nominatim.openstreetmap.org) with a contactable User-Agent. Nominatim sees the query text and this server's address, not your plot, your corners or your files. Nothing is searched until you press Go. A result is a suggested map centre, not a location proof.
• Phone Sync (acoustic path): the rendezvous mailbox at /api/copresence briefly holds, per pairing session, four sample-clock integers and two confidence numbers from each device, keyed by a one-way hash of a secret that never reaches the server. It cannot derive a location or a distance from them; entries expire within 10 minutes. The screen-to-camera path uses no server at all.
• GeoLibre plugin (opt-in, inside GeoLibre): the OpenStamps plugin for the GeoLibre GIS (installed by you from /geolibre/plugin.json) runs in GeoLibre, not on this site. Only when you paste a journey link, press "Illustrative unit", or answer "Open and check it" when a saved project or a link names a journey (it asks first and reads nothing until you do) does it read that published journey from /api/publish/<token> or the public sample chain here — the same public reads the journey page makes, seen by our host as any page view is (§9). Checking the stamps is the engine inside the plugin and reaches nothing. What you draw stays in GeoLibre; a project you save keeps the journey link and the declared positions, never a check result.
• The security and buying pack: architecture, data flow, sub-processors, retention, service limits and the honest questionnaire answers (no SOC 2, no ISO, no insurance, no SLA) are on one page, kept in step with this one.
• Coverage map (opt-in, per published journey): when you publish a product's journey from the desk you may tick also put this journey's plots on the coverage map. Then /api/coverage and Calibration is the public record of how our own forecasts compared with what happened; it names nobody and withholds any cell small enough to identify somebody. /coverage.html list that journey as the industry, the country a plot named, the day it was published and up to eight positions rounded to 0.01° (about a kilometre), linking to the public page — no name, no account, no polygon. The page is public whether or not you tick; the map only aggregates journeys whose publisher said yes, the tick is undone from the desk at any time, and withdrawing the page removes the dot. Ask the supplier whose plot it is before ticking.

8. Enquiries and e-mail

Evidence tools and team enquiries: the free pack builder and recipient review tool process selected files in this browser. The review tool keeps its draft in the current tab until you download it; importing a pack or receipt does not upload it. A Workspace interest or assisted-setup request includes the contact, company, enquiry type, workflow, optional reviewer requirements, estimated volumes and preferred date you review on teams.html. It uses the same enquiry route described below only after you press Send, or your own mail client if you choose e-mail. It does not include source documents. For assisted setup, the written scope must agree the document transfer method, access and retention arrangements before you share those documents with us.

Enquiry / e-mail: whatever you choose to write to us — typically your name, your work e-mail address and the question you are asking. The Ask panel and the enterprise quiz last step are the same door: a same-origin POST to /api/crm, which creates a Lead in a CRM we operate ourselves, hosted for us in Germany. Plots, stamps, desk bundles and Information System credentials are never sent that way. An e-mail link uses your own mail client. Purpose: answering you (legitimate interests, and steps prior to a contract where you are asking about buying: GDPR Art. 6(1)(f) and 6(1)(b)). Protosonic is the controller. The first-party Ask panel answers locally on your device and sets no cookie. Nothing on this site asks you for a turnover figure as an input to a price. Retention: up to 24 months after last contact, unless a contract or tax law requires longer.

9. Hosting logs and abuse limits

Our static host may process IP address and user-agent transiently to deliver pages. To enforce the per-network anti-abuse limits we store a hashed daily counter (not the IP itself) for timestamp-relay, sign-in, hand-off, Phone Sync and Ask-panel messages. These per-network counters are not the meter: the meter (section 6) counts stamps against an account, this counts requests against a hashed network, and neither holds anything you stamped. Purpose: prevent infrastructure abuse (GDPR Art. 6(1)(f)). Counters expire with the UTC day. Protosonic is the controller.

Where the material is held, by class. Two classes of data live on the store, and /api/residency prints — for this deployment, at any moment — where each is: the evidence (the journal's envelopes, the vault's ciphertext, the nightly anchors, published journeys, the desk bundles and their versions, the hand-off mailbox and the ten-minute co-presence mailbox) and the ledger (the account record with its balance, e-mail address and key hashes, and the abuse counters). Since 16 September 2026 both classes are held in an object store with European Union jurisdiction — Cloudflare R2, bucket restricted to the EU at creation, which Cloudflare documents as storing the data only in EU locations. Cloudflare, Inc. is our sub-processor for those bytes; Netlify runs the functions that read and write them and holds no copy — the Netlify Blobs stores used before that date were emptied on the same day. /api/residency names the class of place (provider, jurisdiction), never an endpoint or a bucket; the account page prints the same sentence under the vault. Netlify's functions, CDN and request logs remain where Netlify runs them (section 9, first paragraph); residency here is about where the stored material rests. Nothing moves by itself: a change of store is a deliberate, logged act by the operator, printed on /api/residency the moment it is made.

10. Blockchain hygiene

Procurement and privacy officers ask "is this a blockchain, and what goes on it". The answer, once: no blockchain is needed to check a stamp — a stamp is checked offline from its own bytes, a public randomness round and timestamp-authority tokens. Where a public append-only log is used, now or later, what is registered is a 32-byte identifier, never a record, as one more independent clock beside the others. There is no token, no per-stamp transaction, no data on any chain, and no chain per company. A chain, if one is ever used, is one witness among several and is never load-bearing on its own. Today no stamp minted on this site is registered in any log at all, and every surface says so.

11. Cookies and analytics

This site is designed without advertising trackers, analytics scripts or cookie banners. If a future analytics tool is added, we will update this policy and, where required, obtain consent. The account session cookie is strictly necessary, carries no tracking, and is set only after you sign in. The Ask panel sets no cookie. Stripe sets its own cookies on Stripe’s hosted checkout and billing portal, on Stripe’s pages and under Stripe’s policy; none of them is set on this site. If you choose Revolut Pay, Stripe may send you on to Revolut’s pages, where Revolut sets its own cookies under Revolut’s policy; none of them is set on this site either.

12. Recipients and transfers

Enquiry submissions become a Lead in the CRM we operate, hosted for us by an EU provider in Germany; the same-origin door that creates that Lead runs on Netlify. An e-mail link uses your own mail client. Hosting and e-mail providers act as processors or sub-processors. Stripe Payments Europe, Ltd. (Ireland) is our payment processor and holds the customer record; Stripe, Inc. (United States) is its sub-processor and Stripe's own transfer safeguards apply. The timestamp authorities — two free ones, and a qualified third where this deployment relays to one: Microsec zrt. (Hungary, EEA) — receive digests only; the drand operators receive nothing. The operator's own alert mailbox receives operational mail about that leg (counts, an HTTP code, a slot name) carrying no personal data. We do not sell personal data. Transfers outside the EEA — Netlify, Inc. and DigiCert are in the United States — use appropriate safeguards (EU Standard Contractual Clauses); the digest sent to DigiCert is not personal data. The CRM is hosted in Germany. Nobody receives anything when a stamp is checked, because nothing leaves the device that checks it.

13. Retention, in one place

• Farmer's phone: 90 days for sealed entries; an unsent entry is never pruned.
• Hand-off mailbox: 14 days by default (1–30 at the buyer's choice), applied on the next touch; no sweep job; closed at once by the buyer.
• Desk: on the device until exported or cleared by the operator; the signed-in copy under the account (the bundle and its five previous versions) until the operator deletes it or closes the account.
• Saved companies: under the account until the operator removes one from the desk or closes the account.
• Filing deployment: nothing retained by the function; decommissioned when the operator ends it.
• Vault: each file five years from the day it is stored (a legal hold you set prevents deletion until you lift it; a prepaid vault term funds the five years for the files stored while it is live); the vault is deleted when the account is closed.
• Account: until closed.
• API keys: the hash, until you revoke it or close the account.
• Meter counts: on the account record while it is open; the previous period's counts are overwritten when the period rolls.
• Payments: Stripe's own retention for the customer record; ours is what accounting and tax law requires (seven years in Estonia for the underlying documents).
• Enquiries: up to 24 months after last contact.
• Abuse counters: the UTC day.

14. Your rights

Under the GDPR you may request access, rectification, erasure, restriction, portability, and objection. For surfaces where we are controller, contact pilot@openstamps.com. For a farmer's record or a mailbox deposit, the buyer is the controller and we will refer your request to it and assist it. You may complain to the Estonian Data Protection Inspectorate (Andmekaitse Inspektsioon) or to your own national authority.

15. Children

The Service is for business users. It is not directed at children.

16. Changes

We may update this policy; the date above will change.

Terms Accessibility Cancellation and refunds Check a stamp The dossier Changelog