Privacy

0. What this notice covers

Three separate things carry the PressboardKit name, and a sentence that is true about one of them can be false about another. So each section below says which it is about:

• This website, pressboardkit.com — static files, no accounts, no cookies, nothing third-party. Sections 1 to 3.
• The dashboard, app.pressboardkit.com — where you register an application and hold a licence. It has accounts, so it has cookies and it stores things. Section 4.
• The engine — the SDK other developers put in their apps. What it does and does not send, and what that means for their users. Section 7.

Where a section says "nothing", it means nothing about the thing that section names — not about all three.

1. What this website collects

Nothing. There is no analytics script, no tag manager, no pixel, no A/B testing, no session recording, no heatmap, no advertising identifier and no cookie of any kind on pressboardkit.com. The dashboard is a different host and sets two cookies; see section 4. Neither place asks for cookie consent, and section 4 says why that is allowed rather than assumed.

There are also no third-party requests. No webfonts from a font host, no scripts from a CDN, no embedded videos, no remote images. Every byte the page needs comes from this domain, so no other company learns that you visited. You can check this, on this site and on the dashboard alike: open your browser's network panel and count the hosts.

2. The one thing this website stores on your device

If you use the light/dark toggle in the header, the site saves your choice in your browser's local storage under the key sbk-theme. It exists so the page does not flash the wrong theme when you come back. It is not a cookie, it is never sent to us or to anyone else, and clearing your site data removes it. If you never touch the toggle, nothing is stored at all.

3. Server logs

The site is static files served by a hosting provider. Like any web server, that provider may record requests — typically IP address, timestamp, requested path and user agent — for operational and security reasons. We do not use those logs for analytics and do not build profiles from them.

There are two providers. Google serves this site from Firebase Hosting and runs the staging copy and the dashboard on Cloud Run in the europe-west1 region, in Belgium. Neon runs the dashboard's Postgres database, on AWS in eu-central-1, in Germany.

So the dashboard — accounts, licences, the record of notices — is held in the EU. This site is different: Firebase Hosting is a global content network, and a request for a page may be answered by, and logged at, a server outside the EU. What reaches it is a request for a static file. There is no account behind it, because this site has none.

Each publishes its own terms: Google's privacy policy and its Cloud data processing addendum, and Neon's privacy policy. We do not export these logs anywhere, do not join them to anything else, and do not look at them except when something is broken.

Request logs are kept for 30 days and then deleted. That is Google Cloud Logging's default retention and we have not lengthened it — a shorter answer than any we would have invented, and it applies to this site and to the dashboard alike. One exception we do not control: Google keeps its own record of administrative changes to the project for 400 days, in a bucket whose retention cannot be shortened. That log is about us administering the project, not about you visiting it.

4. The dashboard

app.pressboardkit.com is where you register an application and hold its licence. It has accounts, so unlike this website it stores things about you and it sets cookies. Both are listed here rather than summarised.

What it stores:

• your email address, and whether it has been confirmed. This is the address every notice in the licence is served to, which is the reason an account has one at all;
• a hash of your password — PBKDF2, never the password and never anything reversible;
• your company name, country and VAT identification, if you fill them in. Optional, and for our records;
• the applications you register — product name and bundle identifier — and the licences issued against them. The licence key itself is stored hashed: it is shown once, at issue, and there is no page and no support request that can show it again;
• a record of every notice we send you and whether the email provider confirmed delivering it. That record exists because the licence is discharged by writing to you, so whether a letter arrived is a fact we have to be able to establish. Open tracking and click tracking are switched off — not in a provider setting, but in our own source, because telling developers their keyboard sends nothing anywhere while quietly reporting when they read their post is not a position worth holding.

The three cookies, and why there is still no banner:

• pbk_session — your sign-in. HttpOnly so no script can read it, Secure so it only travels over TLS, SameSite=Lax, and it expires after 30 days. Signing out deletes it on both ends;
• an antiforgery token, set when a page with a form is rendered. It exists so that another site cannot make your browser submit a form to us using your session;
• pbk_theme — set only if you use the light/dark control in the dashboard header, and it holds one word: light or dark. Choosing "Auto" deletes it again rather than storing a third word. It is how the appearance you asked for survives the next page, and because the dashboard runs no script of its own, there is nowhere else it could be kept. Same flags as the session cookie, and it expires after six months.

None is analytics and none follows you anywhere. All three are strictly necessary for a service you explicitly asked for — you cannot have a signed-in dashboard without a session, you should not have one without CSRF protection, and the third exists only because you operated a control asking for it — which is the category that ePrivacy exempts from consent. That is why the dashboard has no cookie banner either: not because we decided to skip it, but because there is nothing on it to consent to.

The exemption we are relying on is the one transposed into Czech law by § 89 of Act No. 127/2005 Sb.: storage that is strictly necessary to provide a service the user explicitly asked for needs no consent. The session and the antiforgery token are necessary in the plainest sense — remove either and a signed-in dashboard either stops working or stops being safe. pbk_theme is the one worth arguing about, and the argument is that it is written only when you operate a control whose entire purpose is to be remembered, holds one word about appearance, and identifies nobody.

[PLACEHOLDER FOR THE LAWYER: confirm that reasoning and that no consent mechanism is required. pbk_theme was shortened from a year to six months rather than waiting to be told to; if even that is too long, the fix is the lifetime again, not a banner.]

There is no analytics on the dashboard and nothing third-party is loaded into its pages — the one stylesheet it uses is served from the same origin. There is one script, on one page: when a licence key is issued it is shown once, and an inline script puts a "copy" button beside it. That script is served as part of the page, makes no request, stores nothing, and reads only the key already on screen. Its hosting provider records requests the way section 3 describes.

Taking a copy, and closing the account, are both controls on the account pagerather than a request you have to make of us. The export is a file holding everything listed above — this account, the applications you registered, the licences issued against them and the record of notices sent — and it names the two things it leaves out: the password hash, because a credential is not information about you, and the licence keys, because they are stored hashed and shown once at issue, so there is no copy to return.

Closing the account signs out every session and the address cannot sign in again. Two things it deliberately does not do. Licences already issued keep working, because the keyboards running on them belong to your users, who had no part in the decision. And the account row is marked closed rather than removed — licences, notices and any payment record point at it, and an accounting record cannot lose the party it is about.

To be exact about what happens today rather than what ought to: nothing is deleted on a timer. There is no job that expires old accounts, notices or audit rows, so a record stays until somebody removes it by hand. Saying "we keep this for N years" before that job exists would be describing a system we have not built.

[PLACEHOLDER: set the retention period for accounts, notices and audit records, reconciled with the statutory retention of accounting documents — and build the thing that enforces it. The sentence and the job have to ship together; either one alone is a fiction.]

5. If you email us

Writing to hello@pressboardkit.com means we hold your email address and whatever you put in the message. We use it to reply to you and to keep track of the conversation. We do not add it to a mailing list, and we do not sell or share it.

This is about mail coming to us. Mail going the other way — the licence confirmations and notices described in section 4 — is sent through Resend, whose privacy policy covers what it does with a message in transit. Open and click tracking are switched off in our own source rather than in a provider setting.

[PLACEHOLDER: name the provider hosting the hello@pressboardkit.com mailbox, link its privacy policy, say where it stores messages, and set a retention period after which correspondence is deleted. Resend is the outbound sender and is not this answer — the mailbox is a separate service and nothing in this repository records which one.]

6. If you open a GitHub issue

The issue tracker is hosted by GitHub, and anything you post there is public and governed by GitHub's privacy policy, not this one. If a report contains something you would rather not publish, send it by email instead.

7. The engine itself

As shipped today, PressboardKit performs no network requests. It imports no networking framework, has no third-party dependencies, and contains no code that opens a connection — the package manifest declares no dependencies at all, and the source links only Apple's own frameworks. That is a description of the current build rather than a permanent guarantee: licence validation is planned, it will run in the containing app rather than in the keyboard process, and it will carry a licence key and a bundle identifier — never anything typed. The claim that does not change is the one above: what you type stays on the device. Typing, autocorrection, word completion, next-word prediction and slide-to-type decoding all run inside the keyboard process, against dictionaries bundled in the app and against Apple's system text checker, UITextChecker.

Two things are worth being precise about, because they are the points where data could plausibly leave:

• What the engine learns, it hands back to the host app. The engine learns the word pairs you type so it can predict the next word, and it gives that data to the application embedding it to store — typically in the app's own container, so it survives the keyboard extension being killed. Where that application then puts it is the application's decision and is covered by its privacy policy, not this one.
• An app embedding the engine can still send data itself. A keyboard extension with Full Access can do things the engine does not. If you are an end user wondering what a particular keyboard does with your typing, the answer is in that app's privacy policy — this page can only speak for the engine.

8. Legal basis, and your rights

There are two cases, and they have different bases. An email you send us is an address you chose to give us, processed so we can answer you. A dashboard accountis different: the email address, the applications you register and the record of notices sent are processed to perform the licence itself — a licence is served at an address, so holding the address is not a convenience, it is the contract working.

The data controller is AFTG s.r.o., Komenského 1081/91, Bolevec, 323 00 Plzeň, Czech Republic, IČO 03267725 — the same entity named in the licenceand the site terms. Write to hello@pressboardkit.com about anything on this page.

You have the rights the GDPR gives you over the data described here: to ask what we hold about you, to have it corrected, to have it erased, to object to processing, to have it restricted, and to receive it in a portable form. Write to the address above and say which; we will answer, and where something cannot be erased — an accounting record, say — we will tell you which rule stops it rather than declining in general terms.

If you think we have handled your data badly, you can complain to the Czech supervisory authority, the Office for Personal Data Protection (Úřad pro ochranu osobních údajů, uoou.gov.cz), or to the authority where you live.

[PLACEHOLDER FOR THE LAWYER: state the lawful basis for each of the two cases described at the top of this section — performance of a contract for the dashboard account, and what covers an email somebody sends us — and check the rights paragraph against how we actually answer such a request.]

9. Changes

If this notice changes, the revised version is published here. There is no analytics and no mailing list, so there is no list of visitors to notify — but registered licensees do have an address on file, and a change that affects them is written to it. That is the same address, and the same undertaking, as section 8 of the licence.

10. Contact

Privacy questions go to hello@pressboardkit.com.