Security Policy MyOwnConference

This is the policy referenced by our security.txt file, published under RFC 9116. It tells you how to report a security problem in MyOwnConference, what we consider in scope, and what happens after you write to us.

If you are looking for how we handle personal data, that is the privacy policy, and the processing terms are in the data processing agreement. This page is only about vulnerability reports.

§1 How to report

1.1. Write to [email protected]. This address is the one published in our security.txt and it is the only channel we treat as a security report.

1.2. If the report contains anything sensitive, encrypt it with our OpenPGP key, published at /.well-known/pgp-key.txt.

1.3. We read reports in English, Russian, Polish and Ukrainian.

1.4. A useful report tells us what you found, where you found it, and how to reproduce it. Steps we can follow, the request or payload you used, and what you saw as a result are worth more than a scanner label. Screenshots and short recordings help.

1.5. Tell us if you intend to publish, and when. We would rather know than find out.

§2 What is in scope

2.1. myownconference.com and its subdomains, which is the site you are reading now.

2.2. app.myownconference.com, the control panel where accounts, webinars and billing live.

2.3. www.mywebinar.com, the webinar room itself.

2.4. Anything you can reach from those without credentials that are not yours.

§3 What is out of scope

3.1. Services we do not operate. Payment processing, mail delivery and the content delivery network belong to third parties, and reports about them should go to those parties.

3.2. Output from an automated scanner with no demonstrated impact. A finding needs a path from the observation to a consequence.

3.3. Missing hardening headers, weak cipher suites and similar configuration observations, unless you can show what they let an attacker do here.

3.4. Denial of service, volumetric testing, and anything else that degrades the service for other people. Please do not.

3.5. Social engineering of our staff, our customers or our suppliers, and physical access attempts.

3.6. Reports that depend on a compromised device, an outdated browser, or a user who has already been phished.

§4 What we ask of you

4.1. Work only with accounts and data that are yours. Create a free account if you need one, because we would rather you tested on your own webinar than on somebody else's.

4.2. If you reach data belonging to another person, stop, do not save it, and tell us what you saw and how.

4.3. Do not modify or delete anything that is not yours, and do not keep access once you have shown the problem exists.

4.4. Give us a reasonable chance to fix the issue before you publish. We will tell you where we are.

4.5. One report per issue, please, and let us close the first one before opening variants of it.

§5 What we do

5.1. We confirm that your report reached a person, and we keep you informed until the issue is closed or we explain why we are not treating it as one.

5.2. We do not set a deadline in this document, because a promise we might miss is worth less than a straight answer about where a fix stands.

5.3. We will not initiate legal action against a researcher who acted in good faith and within this policy. If somebody else raises a claim about work that followed these rules, we will say plainly that the work was authorised.

5.4. This policy does not create an entitlement to payment. If you would like to be credited once a fix ships, say so in your report.

§6 Keeping this page honest

6.1. Our security.txt carries an expiry date and is regenerated on every deploy, so the contact and the key above stay current.

6.2. If anything on this page turns out to be wrong or stale, that is itself worth an email to the same address.