Security

If you have found a security or privacy issue in this website or in one of our applications, we want to hear about it directly, before anyone else does. This page says exactly how to tell us, what we will do in return, and what we will not do to you for telling us.

What to send

Enough for us to reproduce the issue without guessing. In practice that means:

• Where it is — the URL, the application, or the version.
• What you did, step by step.
• What happened, and what you expected instead.
• Why you think it matters. A short sentence is fine; we would rather have your read on it than not.

Screenshots and short recordings help. Please do not include anyone else’s personal data in your report — if a proof of concept would require it, describe the shape of the problem and we will reproduce it ourselves.

What we commit to

• A human reply within five business days. Not a ticket number.
• An honest assessment — including telling you plainly when we think something is not a vulnerability, and why.
• Keeping you updated while we work, rather than going quiet until it is fixed.
• Credit in the release notes if you want it, and none if you would rather stay anonymous. Your choice, asked before we publish.

We are a small company. We would rather tell you a fix will take a while than pretend it will not.

What we ask of you

Give us a reasonable opportunity to fix the issue before you disclose it publicly. Ninety days is the norm and we will not argue about it; if we need longer we will say so and explain why, and if we are dragging our feet, say so and we will take the point.

While you are testing, please stay inside these lines:

• Only use accounts and data that are your own.
• If you do come across someone else’s data, stop, do not save a copy, and tell us what you saw and how.
• No denial of service, no load testing, and nothing that degrades the service for other people.
• No social engineering of our people, our customers, or our vendors, and no physical attempts against our registered address or any premises.
• No spam, and no automated scanning heavy enough to be indistinguishable from an attack.

Safe harbour

If you follow the lines above and report to us in good faith, we will not pursue or support legal action against you for your research, and we will treat your work as authorised for the purposes of computer-misuse and anti-circumvention law. If a third party brings action against you for research you conducted within this policy, we will make it known that your work was authorised.

This is our commitment, not legal advice, and it cannot bind anyone other than Memorio Studio LLC. If you are ever unsure whether something falls inside this policy, ask us first — that question alone will never be held against you.

Scope

This policy covers memoriostudio.com, its subdomains, and any application published by Memorio Studio LLC.

It does not cover the third parties who serve or host this site, or any service that merely links to us. Findings in those belong with their own security teams, though we would still like to know if they touch us.

Out of scope as findings

To save your time: reports consisting only of automated scanner output, missing hardening headers with no demonstrated impact, best-practice notes about our TLS configuration, or the absence of a feature we have not shipped are not treated as vulnerabilities. Show us an impact and we will look regardless of category.

Rewards

We do not run a paid bounty programme, and we would rather say so plainly than let you find out after the work. What we offer is a fast human answer, public credit if you want it, and the fix.

This page

The machine-readable version of this policy lives at /.well-known/security.txt and is the canonical location under RFC 9116. If the two ever disagree, this page is the one we mean.