01How to report
A report can be sent through /contact/security. Include enough detail for it to be reproduced: the affected page or system, the steps that trigger the issue, and what the impact actually is — a report that says only "there's a vulnerability" with no reproduction steps is much harder to act on than one with specifics.
02Scope
In scope: the public website, the operator console, the staff tablet interface, and the voice platform's externally reachable surfaces.
Out of scope: denial-of-service testing against live restaurant traffic, and social engineering directed at Dohos staff, restaurant staff, or customers. Testing that disrupts an actual restaurant's ability to take real calls during service is not in scope no matter what it finds.
03Safe harbor
Good-faith research conducted within the scope above is not treated as an attack, provided it stays within these bounds:
- don't access or modify another restaurant's data beyond what's strictly necessary to demonstrate the issue
- don't disrupt service for a real caller or restaurant
- don't use social engineering against Dohos staff, restaurant staff, or customers
- don't attempt to obtain, use, or test real payment credentials
- don't publicly disclose a finding before Dohos has had a reasonable opportunity to address it
These are the conditions Dohos's own security policy sets for treating a report as protected research rather than a violation. They describe how a report is evaluated; they are not a formal legal safe-harbor commitment, which this page does not have the authority to make on its own.
04Coordinated disclosure
The expectation runs both ways. A researcher who reports privately and gives Dohos a reasonable window to actually fix an issue before writing about it publicly is doing exactly what this page asks for. Publishing exploit details before that window has passed — even with good intentions — can put a real restaurant's live calls and orders at risk while a fix is still in progress, which is the harm this condition exists to prevent, not a rule for its own sake.
05What's not yet in place
06After a report
A genuine, in-scope report is meant to be triaged against its severity — how exploitable it is, what it exposes, and how many restaurants it could affect — rather than queued strictly behind whatever feature work happens to be in progress. This describes intent, not a measured track record: Dohos has not yet published data on how quickly a past report was addressed, because it does not yet have a public history of reports to draw that data from.
07What makes a report easy to act on
A report is far more useful, and far faster to triage, when it includes:
- the specific page, endpoint, or call flow affected
- the exact steps that reproduce the issue, in order
- what the impact actually is — what data or action it exposes, not just that "something's wrong"
- a minimal proof of concept, stopping at the point that demonstrates the issue rather than continuing to exploit it further
None of that is a requirement for a report to be taken seriously — a shorter report is still read — but a report with those details reaches a fix faster than one without them.
08Why production access needs care
Dohos handles restaurant phone calls that a real caller placed to order real food. Testing that crosses into another restaurant's live data, disrupts an active call, or touches a real payment isn't a safer version of research just because the intent behind it was good — it causes the same harm a malicious actor would cause. That's the reasoning behind the scope and safe-harbor conditions above: they're drawn narrowly enough to protect a legitimate caller and a working restaurant, not to make research difficult for its own sake.