Vulnerability Disclosure Policy

Email [email protected]. That address exists for exactly this and nothing else, so a report sent there is never triaged as a support ticket or a sales enquiry.

What helps us most, roughly in order:

1. The URL or the request where it happens.
2. Enough steps for us to see it ourselves — a short sequence, a screenshot, or a recording.
3. What you think somebody could do with it. A guess is fine; we would rather have your reading of it than nothing.
4. Whether anyone else already knows, and whether you intend to write it up.
5. How you would like to be credited, if at all.

Write in English if you can. If English is difficult for you, send it in your own language anyway — a report we have to translate is far better than a report you did not send.

This is the part that matters, so it is stated plainly and without conditions beyond the scope set out below.

• We will not sue you, report you, or support anybody else's action against you for security research carried out in good faith under this policy.
• We treat that research as authorised. Where a law about unauthorised access to a computer system turns on whether you had permission, this page is that permission, for the activity described here.
• If somebody else comes after you for research you did within this policy, and you ask us, we will say publicly and in writing that you were acting with our authorisation.
• Getting it slightly wrong does not void this. If you cross a line by accident, stop as soon as you notice and tell us what happened. Doing that keeps you inside this promise. What takes you outside it is carrying on anyway.
• We will not ask you to stay quiet forever. See the section on publishing below.

We cannot promise anything on behalf of a third party. If your testing reaches a service we merely use rather than run, that provider’s own policy governs it, not this one.

The public web application and the public API served from this service’s own domains, including the diner ordering flow, the restaurant console, and the public restaurant pages.

Use your own accounts and your own test restaurant. Creating a restaurant to test against is free and takes a few minutes, and it means you never need to touch anybody else’s data to prove a point.

Every restriction here exists because breaking it harms a real restaurant or a real diner rather than us:

• Do not touch data that is not yours. If you get access to somebody else’s account, orders, menu or personal details, stop at the point you have proved it. Do not read further, do not download it, do not keep it, and do not build a list of who else is affected.
• Do not change or delete anything you did not create. A restaurant’s menu, prices, tables and orders are how it earns money that day.
• No denial of service, load testing, or stress testing — not against the service, and not against a restaurant. A platform that stops taking orders in the middle of a dinner service costs somebody their evening.
• No automated scanning that generates significant traffic. A scanner pointed at an ordering system is indistinguishable from an attack on it, and it can fill a restaurant’s screen with junk.
• No social engineering, phishing, or pressure of any kind aimed at us, at a restaurant, at their staff, or at diners. People are not in scope.
• Nothing physical. Do not test the premises of a restaurant that uses this service, and do not tamper with printed QR codes on their tables.
• Do not place real orders at a restaurant that is not yours to prove a finding. Somebody has to cook it.
• No extortion. A report conditioned on payment is not a report, and this policy does not cover it.

This is a small operation, and that cuts both ways: your report is read by the person who can fix it, with nobody in between — and there is no rota, so a message that lands at three in the morning waits until morning.

We do not publish a response deadline, because Mithlesh Kumar would be promising something a single person cannot guarantee, and a missed promise here is worse than no promise. What we do instead: we confirm we have received it, we tell you what we think it is, and we tell you when it is fixed. If we conclude it is not a problem, we tell you that too, with our reasoning, rather than going silent.

If a fix affects the restaurants using the service, they hear about it from us. Our commitments on that are in the Privacy Policy and the Reliability statement.

You are free to write up your work, and we would rather you did than felt you could not. Two requests, neither of which is a condition of the promise above:

• Give us 90 days from your report before you publish, so a fix is out before the method is. If we have not fixed it by then, publish anyway — that is the point of the clock, and we are not going to ask you to extend it indefinitely.
• Leave other people’s data out of it. Describe the flaw as fully as you like; redact anybody real who happened to be behind it.

If we fix something quickly and you would like to publish sooner, just ask — we will almost always say yes.

There is no bug bounty and no money. Saying so on this page is deliberate: you should know that before you spend an evening on it, not after.

What we can offer is credit, in your name or a handle, if you want it — and a straight answer about what you found, which is more than a queue at a large company usually gives you.

If something is broken but not a security problem — an order that will not go through, a menu that will not save — write to [email protected] instead. It reaches a person faster, because it is not queued behind a security triage.

Nothing on this page changes the Terms of Service, and where the two disagree, the Terms govern. This policy describes how the Platform handles security reports; it does not grant any other right to use the service.