Security and Vulnerability Reporting

Good-faith security concerns may be sent to security@mrblindbandit.net. Include the affected URL or feature, a concise explanation, reproduction steps that avoid harm, and contact information if a response is desired.

Do not access another person's account or private data, persist in a system after demonstrating a flaw, download unnecessary records, destroy or alter data, deploy malware, conduct denial-of-service activity, use social engineering, compromise third parties, or publicly expose a vulnerability before the operator has a reasonable opportunity to investigate and mitigate it.

The operator should treat non-destructive research intended to improve security as a security report rather than automatically as abuse. Nothing in this policy authorizes conduct prohibited by law or creates immunity that the operator cannot legally grant.

Do not send passwords, full authentication tokens, complete payment information, or copied private user records unless absolutely necessary to explain the issue. Redact proof wherever possible.

Reports should be logged, triaged by severity, acknowledged when contact details are available, assigned an owner, remediated or mitigated proportionately, tested, and closed with a record of the outcome. A qualifying personal-data incident should be escalated into the privacy breach process.

Reports are welcome about mrblindbandit.net and its public pages, the community and Mobile features, the label portal, forms, the Media Hub tools that run in the browser, and the Foundation pages under /nonprofit/. Issues that matter most include problems that could expose another person’s account or personal data, let someone change content they should not control, bypass sign-in or consent choices, or inject scripts into pages other people visit.

Services run by other companies, such as streaming platforms, payment processors, app stores and social networks, are outside this policy. Please report problems with those services directly to the company that runs them.

A clear report is easier to verify and fix. Helpful details include the page address, the browser or device you used, the steps you took in order, what you expected to happen, what actually happened, and why you think it creates a risk. Text descriptions are welcome; screenshots or recordings are optional, and reports written with a screen reader or other assistive technology are just as useful. If you are not sure whether something is a security issue, it is fine to send it anyway and say so.