Security and responsible disclosure
Status: Draft, pending legal review. Version 1.0. This page will show an effective date and a “What changed” note once it is final. Our disclaimers page explains what a draft means.
What this document is
Amyn is a point of sale in development. This document explains how to tell us about a security problem, what we ask of you while you look, and what we promise in return. It is written for security researchers, but anyone who notices something wrong can use it.
The website and account terms define the words we use in every policy. In this document, “we” and “us” mean Amyn. “You” means the person reporting a problem. “The service” has the meaning in the terms. In this document it refers to the parts you may test today: the website at amynpos.com and the dashboard, the signed-in area where a merchant runs its account. A “report” is the message you send us about a problem.
How we protect the service
Most of this page is about what happens when something slips through. Here is what we do to stop that in the first place.
- The website is served only over HTTPS, with modern browser security headers, and loads no code from third parties.
- Our database, sign-in, file storage and server functions run on Supabase, Inc., and the database is in a United States region. Data is encrypted on its way to and from our servers and while it is stored.
- Database rules keep each merchant’s account inside its own records.
- Only the people on the Amyn team who need access to do their job have it.
- We will require two-step sign-in for account owners and admins, and offer it to everyone else.
- Card details will be handled by our payment processor, which we will name here before any payment is taken. Amyn is designed to keep full card numbers out of its systems; the point of sale is built to hold only the last four digits and the card type.
No system is perfectly secure, which is why the rest of this page exists. We will publish a fuller description of our security practices before launch.
How to report a problem
Send your report by email to info@amynpos.com, or through the contact form on amynpos.com. Both reach the same small team, and a person reads every message.
Our security contact is also published in the standard place for it: amynpos.com/.well-known/security.txt. That file lists the same email address and the contact form.
We do not publish an encryption key today. If your report contains something you would rather not send in plain email, write to us first with a short description. We will arrange a safer way to receive the details.
What to put in a report
A good report lets us find and fix the problem on the first try. Please include:
- Which part of the service is affected, with the web address if there is one.
- What the problem is, in plain words.
- The steps to repeat it, in order. Screenshots or a short recording help.
- What someone could do with it, as far as you can tell.
- The date, time and IP address you tested from, if you know them, so we can tell your activity apart from an attack in our logs.
- How you would like to be credited, or that you would rather not be.
You can report without giving your name. We will still read and act on the report. We cannot update you, though, unless you give us a way to reach you.
What is in scope
You may test:
- The public website at amynpos.com, including the waitlist form and the contact form.
- The help assistant, once it is live on the site.
- The dashboard, once it opens. Until then there is nothing to test there.
The help assistant is in scope only for the way we have built it into the site. Anthropic provides it (model: Claude). It has no access to merchant accounts or account data. Problems inside the underlying model belong to Anthropic, not to us.
When the point of sale launches on registers, we will update this page to say what you may test, and how.
What is out of scope
Please do not test the following, and we will not accept reports about them:
- Denial of service, in any form. Do not send heavy automated traffic to the service, and do not try to make it slow or unavailable.
- Social engineering. Do not phish, call, message or trick our team, our providers or anyone else to get access.
- Physical attacks. Do not try to get into our offices or at our equipment.
- Third-party services we use. Supabase, Inc. runs our database, sign-in, file storage and server functions. Netlify, Inc. hosts the website and receives the form entries. Anthropic provides the help assistant. Each has its own way to receive security reports. If the problem is in their systems rather than in how we use them, please report it to them.
- Our payment processor, which we will name here before any payment is taken. Its systems will be out of scope in the same way.
Some findings are real but are not security problems on their own. We will not treat these as reports, though you are welcome to mention them:
- A missing best-practice setting with no shown effect.
- Output from an automated scanner with no working example.
- Which software or version we use, when that alone does nothing.
- Content you can see only because you are signed in to your own account.
- Rate limits, password rules or email settings that could be stricter but work as intended.
If you are not sure whether something is in scope, ask us first. A short email saves you time.
The rules
These rules protect the people whose data we hold. They also protect you, because the promises in the next section apply only to research that follows them.
- Do not access other people’s data. If you reach data that is not yours, stop at once. Do not read more of it, do not copy it, and do not keep it. Tell us what you reached and how.
- Do not disrupt the service. Do not change, delete or damage data, and do not interfere with anyone else’s use of the service.
- Stop and report as soon as you confirm a problem. One working example is enough. Do not go further to see how much more you could do.
- Test only with accounts that belong to you. When the dashboard opens, create your own test business and stay inside it.
- Use what you find only to report it to us. Do not demand payment or anything else in return for the report.
- Keep what you found between you and us until we have fixed it. If you want to write about it, we will agree a public date with you. See “Can you publish what you found?” below.
- Follow the law. Nothing here allows you to break any law or to test anyone else’s systems.
If you break these rules, the promises below no longer apply.
What we promise
If you follow the rules above, we promise to:
- Reply within 5 business days to confirm we have your report.
- Tell you whether we can repeat the problem, and how serious we think it is.
- Keep you informed while we work on it. We will tell you when we expect to fix it and when the fix is live.
- Fix confirmed problems as quickly as we can. Serious problems come first.
- Credit the first report if two people find the same problem, and tell the other reporter that it was already known.
- Credit you, if you want us to. We will name you on this page or in our note about the fix, in the way you choose. We will not name you without your permission.
- Take no legal action against you for research that follows the rules in this document.
We will be honest with you, including when we disagree about how serious a problem is.
No bounty programme today
We do not run a bug bounty programme, and we do not pay for reports. We are a small company in development, and we would rather say this plainly than let you expect a reward. If we start a programme later, we will say so in this document and publish its terms before it starts.
Legal protection for good-faith research
We want people to look for problems and tell us about them. So if you act in good faith, follow the rules above and report what you find promptly, this is where we stand:
- We will not sue you or report you to the police for that research. We treat it as work we asked for.
- Our website and account terms and our acceptable use policy ban probing and testing. For research done under this document, we set those bans aside. Where the documents disagree, this one wins.
- Some security controls double as technical locks. Getting past one of ours only to test it and report it is not something we will hold against you.
- If someone else takes you to court over research done under this document, we will say, on request, that we allowed it.
Good faith means three things. You tried to avoid harm. You used the problem only to show that it exists. And you gave us a fair chance to fix it before telling anyone else.
This protection covers only our own systems. It cannot bind Supabase, Netlify, Anthropic, our payment processor once it is named, or anyone else. It does not cover research that breaks the rules.
Counsel: settle the safe-harbour wording, including the Computer Fraud and Abuse Act, state computer-crime laws, DMCA section 1201 and the promise about third-party claims.
Can you publish what you found?
Yes, once the problem is fixed or we have agreed a date with you. We ask you to wait until then so that merchants and visitors are not exposed while the fix is on its way. We will not ask you to wait without a reason, and we will tell you what the reason is. If we have neither fixed it nor agreed a date, and you feel we are taking too long, write to us. We would rather talk than have you guess.
When you publish, please leave out any personal data you may have seen. Please also leave out any detail that would help someone attack a merchant who has not yet updated.
What we do with your report
We keep your report, our replies and our notes on the fix. We use them to repair the problem, to record what happened and to credit you if you asked for that. Your name and contact details are used for nothing else. We do not sell them and do not share them for advertising.
We keep reports for as long as we need them to show what was found and how it was fixed. They are a security record, kept under the retention schedule we will publish before launch, even when the report arrived through the contact form. The privacy notice explains your rights over your personal data and how to use them.
If your report shows that other people’s data was exposed, we will handle that under the privacy notice and the law. That may mean telling the people affected or a regulator. If the data belongs to a merchant’s customers, we will also tell that merchant, as the data processing addendum describes. We will not name you in those notices unless you ask us to.
How to contact us
Email info@amynpos.com or use the contact form on the website. Put “Security report” in the subject line so we can route it. If you need this document in another format, ask us; our accessibility statement explains how we help. We will publish our mailing address here before launch. Every policy, with its version and effective date, is listed at /policies.
Our published security contact is at amynpos.com/.well-known/security.txt. For questions about your personal data, use the same addresses. A person answers.
Changes to this document
Every version of this document carries a version number, an effective date and a “What changed” note. Earlier versions stay in an archive linked from /policies. If we make a material change, we email account holders at least 30 days before it takes effect. Smaller changes, such as fixing a typo or a link, take effect when posted. This is version 1.0, and no earlier version exists.
A material change to this document is one such as a narrower safe harbour, a new rule for researchers or a change to what is in scope.