Terms and Legal
Vulnerability disclosure.
Found a security issue? We want to hear about it, and we will treat you well for telling us. One email starts the process: security@vronify.chat. A human replies within 48 hours, good-faith research is protected by a clear safe harbor, and you get public credit when the fix ships if you want it.
Effective 1 July 2026
Why this policy exists.
We would rather hear about a flaw from you than learn about it any other way.
Vronify.chat is hand-written, from 0 to over 125.000 lines of code, by a small team in the Netherlands. There is no template or white-label product underneath, and the platform runs on hardware we own and tune ourselves. That gives us an unusual advantage when you report something: the people reading your email are the people who wrote the affected code and who operate the machines it runs on. There is no vendor to escalate to, no ticket queue between you and a fix. When your report is confirmed, the patch is often a direct conversation away.
It also means we carry the responsibility alone. People trust Vronify.chat with their communities, their friendships, and their private direct messages. We take that seriously, and part of taking it seriously is admitting the obvious: no codebase of this size is perfect, ours included. Independent researchers who probe our defenses in good faith make the platform safer for everyone, and this page exists to make working with us easy, predictable, and safe for you.
The short version
Email security@vronify.chat with what you found. Do not access more data than you need to prove the issue, do not disrupt the service, and give us reasonable time to fix it before you talk about it publicly. In return: a human acknowledgment within 48 hours, an honest severity assessment, updates until the fix ships, credit if you want it, and no legal action from us for research done in good faith within scope. The rest of this page is the detail behind that promise. Our broader defensive posture, from encryption in transit to infrastructure, is described on the security page.
What this policy is not
This is not a marketing exercise and not a paid bug bounty program. We do not currently pay cash rewards, and we would rather say that plainly than let you find out after you have done the work. What we offer instead is a fast, honest, human process: your report lands with the developers themselves, you are kept informed, and your contribution is publicly acknowledged if you want it to be. If we introduce a reward program later, it will be announced on this page and in the changelog.
How disclosure works.
Five steps, one email address, no forms or portals.
Report it privately
Email security@vronify.chat with what you found, the steps to reproduce it, and the impact you believe it has. Proof of concept beats theory. Please use email and nothing else: not a public server, not a DM to a team member, not a post on social media. A private report gives us time to protect users before anyone can exploit the issue.
We acknowledge within 48 hours
You get a human acknowledgment within 48 hours. Not an autoresponder, not a ticket number: a reply from someone who has read your report and can ask sensible follow-up questions. If anything in your report is unclear, this is where we ask, so the more complete your first email is, the faster everything after it moves.
We reproduce and assess
We attempt to reproduce the issue from your steps, then give you an honest assessment of severity and a realistic timeline shortly after. If we think the impact is lower than you believe, we explain why instead of going quiet. If it is worse than you thought, we say that too, and we may ask you to hold details more tightly while we work.
We fix it and keep you updated
Confirmed issues get fixed with priority matching their severity. Because we own the whole stack, from the code to the hardware it runs on, there is no upstream vendor to wait for. We keep you updated until the fix is live, and we tell you when it ships so you can verify it yourself.
We credit you
With your permission, we credit you when the fix ships. If you prefer to stay anonymous, that is fine too, and it changes nothing about how your report is handled. Where you want the credit to point, a name, a handle, or a link, is up to you.
Writing a report we can act on.
A good report gets fixed faster. Here is exactly what helps.
What to include
The best reports read like a recipe: someone who has never seen the bug can follow them and see it happen. Aim to cover these points in your first email:
- Where: the exact page, endpoint, or feature affected, with the URL if there is one.
- Steps to reproduce: numbered, starting from a fresh state, including any account setup the issue depends on, such as specific roles or permissions.
- What you expected versus what happened: one sentence each is enough.
- Impact: what an attacker could actually do with this, in your honest estimation. Who is affected, and what do they lose?
- Evidence: screenshots, request and response snippets, or a short recording. Trim anything that is not needed to show the issue.
- Your environment: browser and version, since Vronify.chat is browser-first and some issues are rendering- or browser-specific.
Proof of concept beats theory
A report that says "this endpoint might be vulnerable to X" is a starting point. A report that demonstrates the vulnerability against your own test data is a finding. We read both, but demonstrated impact moves straight to reproduction while theoretical reports first need investigation on our side, which takes longer and may end with us unable to confirm anything. If you can show it, show it. Keep the demonstration minimal: proving you can read one record you should not see is enough, and pulling a thousand records proves nothing extra while putting real user data at risk.
One issue per report
If you find three unrelated problems, send three emails. Each issue gets its own severity, its own fix, and its own timeline, and bundled reports make all three harder to track. The exception is a chain: if several small weaknesses combine into one meaningful attack, describe the whole chain in one report, because the chain is the finding.
If you hit personal data, stop
The moment you realize you can access another user's data, stop there. Capture the minimum evidence needed to show the flaw exists, do not browse further, do not download data in bulk, and tell us in your report exactly what you accessed. Handling it this way keeps you unambiguously inside the safe harbor described below, and it is the difference between security research and a data breach.
Sensitive details
If your finding is severe enough that you are uncomfortable putting full details in a first email, say so and describe the general area instead. We will arrange a more secure channel for the specifics before you send them. Please never post technical details anywhere public while an issue is unfixed, even partially redacted: attackers reconstruct bugs from fragments.
Scope.
What we want reports about, and what we cannot act on.
In scope
- The Vronify.chat web application and its API
- Authentication, session, and permission flaws
- Data exposure of any kind
- Anything that lets one user affect another's account
- Weaknesses that expose private direct messages to people outside the conversation
- Bypasses of roles, permissions, or moderation controls
- Injection of any kind: script, markup, or query
Out of scope
- Denial of service and volumetric attacks
- Spam, phishing, and social engineering of users or staff
- Physical attacks and attacks on our facilities
- Findings from automated scanners without a demonstrated impact
- Self-inflicted issues, such as script you can only run against yourself
- Missing hardening flags with no demonstrated attack path
- Third-party services we use but do not operate
The gray areas, honestly
Scope lists never cover everything, so here is how we think about the common edge cases. Automated scanner output is out of scope not because scanners are useless but because raw findings without verification create noise that slows down real reports; if you take a scanner lead, confirm it manually, and demonstrate impact, it is a real report and we treat it as one. Best-practice findings, like a missing header or a configuration that merely deviates from a checklist, need a demonstrated attack path to be actionable: tell us what an attacker gains, not just what a checklist says.
Denial of service is out of scope for testing, because proving it means degrading the service for real communities, and our 99.9% uptime across the last 12 months is something users rely on. If you have found what looks like a resource-exhaustion flaw, describe the mechanism in an email without firing it at production, and we will investigate it ourselves. Rate-limiting observations follow the same rule: report the reasoning, skip the flood.
Social engineering of our users or our team is out of scope in every form, including pretexting, phishing simulations, and attempts to talk staff into revealing information. The interesting flaws are in the software, not in whether a human can be tricked on a bad day.
Scope will grow
Today, Vronify.chat is browser-first with nothing to install, so the web application and its API are the entire attack surface, and that is what this policy covers. A mobile app for iOS and Android and a desktop app for Windows, macOS, and Linux are coming soon; when they ship, they join the scope, and this page will say so. The upcoming built-in bot engine will also be in scope from the day it goes live, since automation that acts inside servers deserves adversarial attention from day one.
Reporting should be effortless.
No portals, no paperwork, no lawyers between you and the people who wrote the code.
How we judge severity.
Priority matches real-world impact on real users, not a scanner's label.
Critical
Compromise of many accounts at once, unauthorized access to private direct messages, or broad access to data users believed private. We drop everything else. You will hear from us quickly and often until it is closed.
High
Takeover of a single account, one user acting on another's account, or a permission bypass that hands a member powers their roles do not grant. Fixed ahead of all feature work.
Medium
Real impact with real constraints: a leak of limited data, an attack requiring unusual user interaction, or a flaw only reachable from an already-privileged position. Fixed on a clear, communicated timeline.
Low
Genuine but minor: hardening gaps with a plausible path, information leaks of little value on their own. Queued and fixed, and still worth reporting, because low findings often become links in someone else's chain.
Informational
Observations without a current attack path. We read them, we sometimes act on them, and we say honestly when we will not. An informational rating is a judgment about impact, never about you.
Disagree with our rating?
Say so, with your reasoning. Severity is a judgment call and we have changed our minds before. What we will always give you is the honest assessment we actually believe, not a rating chosen to make a problem sound smaller.
Safe harbor and the rules of engagement.
Clear rules protect you as much as they protect our users.
Our commitment
Safe harbor: research done in good faith within this scope will not lead to legal action from us. If you follow the rules on this page, we consider your testing authorized, we will not report you to authorities for it, and if a third party raises questions about research you did under this policy, we will make it known that you were acting with our authorization. One honest limit: we can only bind ourselves. We cannot waive laws on behalf of governments or grant permission for systems other people operate, which is exactly why staying inside this scope matters.
What good faith looks like
- Test against your own accounts. Create test accounts and test servers, and attack those. Never target a real community or a real user's data.
- Stop at proof. Access the minimum needed to demonstrate the issue, then stop. Do not pivot deeper, do not persist access, do not install anything.
- Do not degrade the service. Real communities depend on the platform. If a test could slow it down or break it for others, describe the flaw instead of firing it.
- Do not alter or destroy data that is not yours, and do not exfiltrate data in bulk. One record proves a flaw; a thousand records is a breach.
- Keep it confidential until we have had reasonable time to fix it, then coordinate the disclosure with us.
- Delete what you touched. If any user data ended up on your machine during testing, delete it once we have confirmed the report.
What voids the safe harbor
The protection above is generous by design, and it has hard edges. It does not cover extortion or ransom demands, selling or sharing the vulnerability with anyone else, threatening publication to pressure a payment, accessing data beyond what a proof of concept requires, social engineering, physical intrusion, or attacks on infrastructure and services we do not operate. None of that is security research, and none of it is protected by this page.
Coordinated disclosure
We ask for reasonable time to fix an issue before you publish, and in exchange we work openly with you: honest severity, honest timelines, and a heads-up when the fix ships. Once it is live, you are welcome to publish your findings, and we are happy to review a draft for factual accuracy first, without ever editing your conclusions. If a fix is taking longer than we said it would, we owe you an explanation, not silence, and the timeline gets renegotiated with you rather than imposed on you.
If you are a user, not a researcher
Not every security concern is a vulnerability. If your account is behaving strangely, if you received a suspicious link, or if another member is harassing you, use support and the in-app reporting tools; those routes are staffed for exactly that, and the community guidelines explain what moderation can act on. The security address is for flaws in the platform itself. Sending the right thing to the right place gets you a faster answer at both.
Questions researchers actually ask.
Do you pay bug bounties?
Not at the moment, and we say that up front so nobody is surprised after doing the work. What you get is a fast human process, honest communication from the people who wrote the code, and public credit when the fix ships if you want it. If a paid program launches later, it will be announced here and in the changelog.
Do I need permission before I start testing?
This page is the permission. Good-faith testing within the scope and rules described here is authorized without asking first. You do not need to email us before testing, only when you find something. If you want to try something you suspect sits outside the rules, ask first at security@vronify.chat and wait for a yes.
Can I stay anonymous?
Yes. Report from any address you like, use a pseudonym or no name at all, and skip the credit entirely if you prefer. Anonymity changes nothing about how seriously we take the report or how the safe harbor applies. The only thing we need is a way to reply, because reproduction usually takes a question or two.
What if someone already reported the same issue?
We will tell you it is a duplicate, honestly and promptly, rather than leaving you waiting. Credit goes to the first actionable report. A duplicate is still useful signal: it tells us the issue is findable, which can raise its priority, and independent reports sometimes add details the first one missed.
I accidentally accessed someone else's data. Am I in trouble?
Not if you do the right thing next: stop immediately, keep only the minimum evidence, tell us exactly what you saw in your report, and delete anything that ended up on your machine once we confirm the finding. Stumbling into data through a flaw is the flaw's fault. Continuing to browse it afterward is a choice, and that is the line the safe harbor draws.
What about bugs in third-party software you use?
Because the platform is hand-written rather than assembled from someone else's product, our third-party surface is small, but it is not zero. If a flaw in a dependency affects Vronify.chat, report it to us: how it affects our users is our problem, and we will mitigate on our side and pass details upstream. Our safe harbor cannot authorize testing systems other companies operate, so test the impact on us, not on them.
Can I publish my findings afterward?
Yes, once the fix is live. Write-ups, conference talks, and blog posts are all fine, and we are glad to check a draft for technical accuracy if you want a second pair of eyes. We do not ask for editorial control and we do not ask you to sign anything. All we ask is that publication comes after users are protected, not before.
Will the mobile and desktop apps be in scope?
Yes, from the day they ship. Today the platform is browser-first, so the web application and API are the whole scope. The iOS and Android app and the Windows, macOS, and Linux desktop app are coming soon, and each joins this policy at release, as will the built-in bot engine. Watch the changelog for those launches.
Found something? Tell the people who can fix it.
One email reaches the team that wrote every line. A human replies within 48 hours, and your report makes every community on the platform safer.
Good-faith research protected. Anonymous reports welcome. Credit when the fix ships.