Found a hole? Tell us about it.

Three things, and anything they touch.

• This shop. The storefront on our own domain: the theme, the pages, the forms, the basket, and everything we configured ourselves.
• The SneakPen app. The editor, the templates, the formula editor, the import and export, the service worker, and the Bluetooth printing path.
• The files the app produces. The PDF and JSON exports, and the import that reads a JSON library back in.

Reports we are particularly glad to receive: anything that runs script in the app or on the shop; anything that lets a crafted import file reach past its own card; anything that shows one customer another customer's order or address; and anything that sends data off the device while the app claims that nothing leaves it.

Some of what looks like our surface belongs to somebody else, and some testing does more harm than it proves. Please leave the following alone.

• Shopify's own platform. The checkout, customer accounts, the admin and the infrastructure behind them are Shopify's, not ours. Report those through Shopify's bug bounty programme, which does pay.
• Third-party apps and services embedded in the shop — reviews, analytics, payment providers. Report those to the company that runs them. Tell us as well and we will chase it from our side.
• Denial of service, load testing, traffic floods, and anything else measured in requests per second. It costs us money and proves very little.
• Social engineering of our staff, our suppliers or our customers, and phishing of any kind.
• Physical attacks, and anything that needs access to somebody's unlocked device.
• Form spam. A thousand messages through the contact form is not a finding.
• Scanner output with no demonstrated impact: a missing header, a version number in a response, cookie flags on a cookie that carries nothing, mail record opinions, or a library flagged as old with no working path to exploit it.

If you are unsure which side of the line something sits on, ask before you test it. We would rather answer the question than argue about it afterwards.

Use the form at the bottom of this page, or write to [Security email]. One issue per report, in English or in French.

What makes a report we can act on:

• the exact address or screen where it happens;
• steps to reproduce it, in order, that we can follow on a clean device;
• what an attacker actually gains — the impact matters far more than the label;
• your browser and its version, the operating system, and the device;
• the date and rough time you tested, so we can find it in the logs;
• a screenshot, a short video or a proof-of-concept file, described in the message if you cannot attach it.

The form is ordinary email underneath and is not encrypted end to end. If the detail is sensitive, send a summary and we will agree a better channel in the reply.

Please keep other people's personal data out of the report. If you have already seen data that is not yours, stop there, tell us what you saw and roughly how much, and delete your copy.

Every report gets a person, not an auto-reply and a ticket number.

• Acknowledgement within 3 working days. A short reply confirming we have it and that somebody is looking.
• A first assessment within 10 working days. Whether we could reproduce it, whether we consider it a vulnerability, and how serious we think it is.
• News of the fix. We tell you when work starts, when it ships and what carries it. If it turns out to be somebody else's code, we tell you who we passed it to.
• An honest no. If we decide not to fix something, we say so and explain why, rather than letting the thread go quiet.

Working days are Monday to Friday, holidays aside. We are a small shop with no overnight security desk. If something is being exploited right now, put « active exploitation » in the first line and everything else waits.

If you research within this policy, we treat what you did as authorised. We will not report you, we will not bring a claim against you, and if someone else raises the alarm about your traffic we will confirm that you were acting under this policy.

That protection holds as long as all of the following are true:

• you acted in good faith, to find and report a problem — not to profit from it or to pressure us;
• you stayed in scope, and stopped as soon as you realised you were not;
• you used your own accounts, your own orders and your own test data, and if you reached somebody else's you stopped at the moment you could prove it and told us;
• you did not degrade the service: no floods, no deletion, no altering data that is not yours, no locking anyone out;
• you took no more data than was needed to demonstrate the issue, kept it safe, and deleted it afterwards;
• you did not publish it before a fix, or before the ninety days below have run;
• you broke no law and nobody else's terms in the process.

We cannot waive anyone else's rights. Shopify, our payment providers and our suppliers each have their own rules, and this safe harbour cannot speak for them — which is precisely why their systems are out of scope.

We ask for 90 days from the day we acknowledge your report before anything is made public. It is usually far less than that: most things on a site this size are a day's work once we understand them.

If a fix is slow, we will tell you why and agree a new date with you rather than let the clock run out in silence. If a problem is being actively exploited we may publish sooner, and we will tell you before we do.

Once it is fixed, write about it if you want to — we would rather you did. Send us the draft and we will check the technical detail if that helps. We ask only that nothing in it identifies a customer.

Credit. Say the word and we will name you here: your own name, a handle, a pseudonym, whatever you prefer. Say nothing and we assume you want none.

Worth knowing before you start, because it changes where the interesting bugs are.

The app has no accounts and no server of ours. There is nothing to log into, no session to steal, no password database, no user table, no synchronisation between devices. Every card is written to the browser's local storage on the device you are using, and nothing is uploaded. It is a static web app with a service worker.

So there is no store of ours to breach in bulk. What is left is worth testing:

• script injected through card content, a template, a LaTeX expression or a file name, and wherever that ends up rendered;
• a crafted JSON import that escapes its own card, overwrites a library, or executes on load;
• anything reading that local storage across origins, or a service worker serving content it should not;
• the PDF export, and what a hostile card can put inside a file you then share with a classmate;
• the Web Bluetooth path between the app and the printer;
• on the shop side, ordinary storefront problems: injected content in a form, a leaked order, an unsafe redirect.

What the app stores and why is set out in the terms of use for the app.

If your finding touches personal data — an order, an email address, an address label — treat that as the most sensitive part of it. Tell us what you could reach and roughly how much, take no more than proves the point, keep it safe, do not share it, and delete it when we confirm the fix.

Where a breach affects people's data, we notify the supervisory authority and the people concerned within the deadlines the law sets on us. Everything else about how we handle personal data is in the privacy policy, and a complaint about it can also go to your national data protection authority.

Your report is personal data too. We keep the correspondence while the issue is open and for a reasonable period after it closes, so the fix can be explained later. We do not publish your name unless you ask us to.