Legal

Privacy policy

Last updated 29 September 2026

This policy describes what Spark Plug actually does with your data. It was written by reading the code and the database schema rather than by adapting a template, so it is specific — including in the places where the honest answer is awkward.

The short version

Who we are

Spark Plug is operated by Jamie Di Cataldo, based in the United Kingdom. For the purposes of UK GDPR we are the data controller for the data described here — the ones who decide what is collected and why, and the ones you hold responsible for it.

You can reach us about anything on this page at privacy@sparkplug.build.

What we collect, why, and our lawful basis

Nothing below is collected unless you do the thing that triggers it. Reading lessons and solving problems while signed out creates no record that can be traced back to you.

Your account

Contract

When you sign in we store your email address, an internal user ID, the time the account was created, and your time zone name — for example Europe/London. Your browser sends the zone name and it is used for exactly one thing: working out where your day ends, so a streak counts correctly. We never receive a date or a location from you, only the name of the zone.

The two ways to sign in collect slightly different things. A magic link needs only your email address. GitHub sign-in hands us the profile GitHub releases — your email address, username, display name and avatar URL. Spark Plug itself only ever reads your email address; the rest sits in your login record with our authentication provider and is not shown anywhere on the site.

We need this to provide the account you asked for, so the lawful basis is performance of a contract with you.

Your progress, and the code you submit

Contract

When you press Submit while signed in, we store the problem, the verdict our grader returned, how long it took, and the full text of the code you submitted. We also keep a record of each problem you have solved, and your current and longest streak.

We want to be plain about the code, because it is the least obvious thing on this page: every submission is kept, not only the one that passed, and it is kept for as long as your account exists. It is there so your history is yours to look back on, and so we can see where a problem is confusing people. Database access rules mean you can only ever read your own submissions — no other user can see them.

Pressing Run stores nothing. Submitting while signed out stores nothing connected to you.

Anonymous practice counts

Not personal data

When somebody who is not signed in runs or submits code, we record four things: which problem, whether it was a Run or a Submit, what our grader returned, and the time. That is the entire record.

It holds no user ID, no IP address, no browser or device information, no country, no code, and — deliberately — no session, visitor or cookie identifier of any kind. Nothing links one row to another, so the rows cannot be assembled into a picture of a person. It is a counter, not a trail. We use it to see which problems people give up on, which is otherwise completely invisible to us for signed-out visitors.

The mailing list

Consent

If you enter your email address in a “new problems in your inbox” form, we store that address, the time, and which page you signed up from. Nothing else, and it is not joined to your account even if you have one.

You gave consent by typing it in, and you can withdraw it whenever you like — by emailing us, or with the unsubscribe link in anything we send.

Error reports

Legitimate interests

When something breaks, on the server or in your browser, a report goes to our error monitoring provider so that we find out. It contains the error and a stack trace.

The monitoring library is configured not to attach the data it would otherwise send by default — your cookies and request contents. That last one is what keeps the code you submit out of error reports. We do not use session recording or replay.

Your IP address is not retained. We would rather be exact about this than claim it is never seen. One kind of report — sent when your browser blocks something our security policy forbids — goes from your browser straight to the monitoring provider, so your address is present in that connection, as it is in any connection your browser makes. The provider is set not to store it, and we have checked that it does not.

One exception worth naming: for a specific class of failure — where your solve was graded but saving it to the database did not work — the report includes your user ID (not your email address). It is there so that if you write and ask “did my solve save?”, we can actually find out.

Our interest is keeping the site working and not losing your progress silently. We think that is closer to a reasonable expectation than an intrusion.

Traffic and performance measurement

Legitimate interests

We use our hosting provider's built-in analytics and page-speed measurement. They record page views and loading-speed figures in aggregate, set no cookies, use no identifier that follows you between sites, and build no profile of you. We see counts and timings, not people.

Server logs and abuse prevention

Legitimate interests

Like every website, our hosting and execution providers log requests, and those logs include IP addresses. We also read your IP address in memory to enforce rate limits, so one person cannot exhaust the service for everyone else. We do not store your IP address in our own database, and we never attach it to your account or your submissions.

Our sign-in provider keeps its own security log of authentication events, which includes the IP address used to sign in.

Where your data is

This is worth stating precisely, because the answer is not the same for everything.

  • Your account, progress, submitted code and the mailing list live in our database in Ireland (AWS eu-west-1), inside the EU.
  • Code you run or submit is executed in the United States — Ashburn, Virginia. The service that actually runs your PySpark is hosted there. Your code is sent to it, run in a locked-down sandbox with no network access, graded, and the result returned. It is not retained on that server after the run.
  • The website itself — every page and every request it handles for you — runs in London. Images, fonts and scripts are delivered from whichever of our host's network locations is nearest you, which is simply how the page loads quickly.
  • Error reports go to our monitoring provider's European region, in Germany.
  • The code editor is a piece of software your browser fetches from a public content delivery network, jsDelivr, when you open a problem. It answers from whichever of its locations is nearest you. We send it nothing about you, but like any server your browser contacts, it sees your IP address and that the request came from this site.

So, plainly: of everything we hold, the code you run or submit is what leaves the UK and the EU, because it is executed in the United States. That is an international transfer and we would rather say it outright than bury it. It is covered by the UK International Data Transfer Addendum to the EU Standard Contractual Clauses. Some of our suppliers are US companies even where the servers they run for us are not, so their staff may access systems from the United States to support and administer them; that is covered by the same safeguards.

Two other things can reach a US company, and neither happens unless you do something. If you choose to sign in with GitHub, that sign-in takes place with GitHub, which is a US company. And opening a problem fetches the code editor from jsDelivr, as described above.

If this matters to you, the practical advice is simple: do not paste anything confidential into the editor. It is a practice environment for exercises about coffee chains and streaming services — please use it as one.

Who else touches it

We do not sell your data, do not share it for advertising, and do not hand it to anyone for their own purposes. It is handled only by the suppliers who run the service for us, each acting as a processor on our instructions:

  • Supabase — database and sign-in. Holds your account, progress, submissions and the mailing list. Ireland.
  • Vercel — website hosting, plus the cookieless analytics and speed measurement. Runs our site in London; a US company.
  • Fly.io — the sandbox that runs your code. United States (Ashburn, Virginia).
  • Sentry — error monitoring, on its European region. Germany.
  • GitHub — only if you choose to sign in with GitHub, and only as part of that sign-in. A US company.

One more party is involved that is not a processor of ours, because we hand it no data: jsDelivr, the public content delivery network your browser fetches the code editor from. It receives what any web server receives from a browser — your IP address and the name of the site you came from — under its own privacy policy rather than our instructions. If it cannot be reached, the site gives you a plain editor instead and everything still works.

We would also disclose data if legally required to. That has not happened.

Cookies and browser storage

There is no cookie banner on this site because nothing here needs your consent. The complete list of what gets set:

  • Sign-in cookies, set only once you sign in. They hold your session so you stay signed in as you move between pages, and they are strictly necessary for an account to work at all. Signing out clears them.
  • One item in your browser's local storage, named sparkplug:solved. If you solve problems while signed out, it remembers which ones so the page can say “3 solved” when you come back. It never leaves your device, we never receive it, and it is never imported into an account. Clearing your browser data removes it.

That is everything. No advertising cookies, no analytics cookies, no tracking pixels, no cross-site identifiers.

How long we keep it

  • Your account, progress, streak and submitted code — for as long as your account exists. Ask us to delete it and it goes, bar up to seven days in our backups before those age out.
  • Mailing list address — until you unsubscribe or ask us to remove it.
  • Anonymous practice counts — kept indefinitely. There is nothing in them to delete, because there is nothing in them that identifies anyone.
  • Error reports — kept by our monitoring provider for 30 days, then deleted automatically.
  • Server logs — kept by our hosting providers on their schedules, typically days rather than months.

Your rights

Under UK GDPR you have the right to:

  • ask what we hold about you, and get a copy of it;
  • have anything inaccurate corrected;
  • have your data deleted;
  • ask us to restrict or stop processing it;
  • object to processing we carry out on the basis of legitimate interests;
  • receive your data in a portable format;
  • withdraw consent to the mailing list at any time.

Email privacy@sparkplug.build and we will deal with it within one month. There is no charge.

If you are unhappy with how we have handled something, you can complain to the Information Commissioner's Office, the UK data protection regulator. We would rather you came to us first so we can put it right.

Deleting your account

Straight answer: there is no delete button in the app yet. Building one is on the list. Until it exists, deletion is a manual process — and we would rather tell you that than describe a button you would go looking for and not find.

Email privacy@sparkplug.build from the address you signed up with and ask us to delete your account. We will remove your login, your profile, every submission including the code, your solved problems and your streak, and take your address off the mailing list. The database is built so that deleting the account removes all of it automatically. Our backups keep a copy for up to seven more days before they age out; we cannot edit a backup, and if one were ever restored we would re-run your deletion straight afterwards. We will confirm by email when it is done.

The anonymous practice counts are the one thing we cannot delete on request, because there is no identifier in them that would let us find “yours”. That is the same property that makes them harmless.

Children

Spark Plug is aimed at people learning a professional data engineering tool and is not directed at children. We do not knowingly collect data from anyone under 13. If you believe a child has created an account, email us and we will remove it.

Changes to this policy

If we change what we collect, we will change this page and update the date at the top. If the change is significant — a new processor, a new category of data, a new purpose — and you have an account, we will email you rather than quietly editing the page.

Contact

Jamie Di Cataldo · privacy@sparkplug.build