security policy

How to report

email support@voiddo.com with the subject line "Security vulnerability report". the same inbox handles every kind of message for the studio, and a human on the team reads it during european or israeli working hours; security reports are flagged by the subject line and pulled to the front of the queue. there is no separate security inbox because there is no separate security team. encrypted reports are accepted: a pgp key is published at /.well-known/pgp-key.txt and the fingerprint is mirrored in the security.txt file.

Please include:

• What product or domain is affected (scrb, rankd, voiddo.com, browser extension, etc.)
• Steps to reproduce — the simpler, the faster we fix it
• Your assessment of impact and any proof-of-concept code or screenshots
• Your handle if you'd like credit when we publish a fix

our response

the realistic timeline goes like this. you send the report. somebody on the team replies within forty-eight hours on a working day — longer on a weekend or an israeli holiday, because the studio is six people across tel aviv, haifa, tallinn and tartu and we do not run a twenty-four-seven security operations centre. the first reply is a real human reading your email, not a ticketing bot writing "thank you for your submission, a member of our team will be in touch within five to ten business days." within five working days we have either reproduced the issue or written back asking for the missing piece we cannot reproduce without. once reproduced and assigned a severity, the patch window depends on what severity means: critical issues — anything that exposes user data, anything that lets a stranger run code or read secrets — get patched inside seven days, usually faster. medium severity gets fixed inside thirty days. low severity gets batched into the next normal release. disclosure is coordinated by default; we publish a short note in the release changelog crediting the reporter by handle (or anonymously if you prefer), and we do not ship a fix and pretend it was a routine refactor.

scope

in scope is everything we actually own and operate: the voiddo.com apex and every *.voiddo.com subdomain (scrb, rankd, tells, games, extensions, tools, ai, play, api, admin, the static pages), every browser extension we publish on the chrome / firefox / edge stores (scrb, rankd, jobmeta, pricepulse, randumb, tabsnap, jsonyo, tokcount, interviewprep, and any new one that ships after this page is written), every npm package under the @v0idd0 scope, every wordpress plugin published under the voiddo studio account on wordpress.org, and the void factory android app distributed through google play. if it has a voiddo logo on it and we can patch it ourselves, it counts.

out of scope is everything we do not operate. paddle handles our billing, cloudflare handles our cdn, hetzner runs our servers in frankfurt, google runs the gemini and play store apis we depend on — if your finding is actually a bug in one of those vendors' systems, please report it directly to them; they have proper disclosure programmes and we cannot patch their code. also out of scope: social engineering of staff (we are six people, please do not try to phish us as a "test"), physical attacks against infrastructure (it is in a hetzner data centre in frankfurt, we cannot do anything about that anyway), denial-of-service via raw traffic flooding (this proves nothing useful), self-xss that requires the victim to paste attacker payload into devtools console (that is a feature of devtools, not a bug in our product), and spam or phishing that originates from somebody else's mail server pretending to be us (report to the mail provider whose dkim is failing). reports out of scope still get a polite reply telling you why and where to send it instead; we do not just close-and-ignore.

safe harbor

the legal promise is short and sincere. if you act in good faith — you test against your own account, you do not access or modify other users' data, you do not exfiltrate more than the minimum needed to prove the issue, you do not destroy data, you do not run automated scanners that knock the service over, and you report the issue to us before publishing or selling it — we will not pursue civil or criminal action against you, even if your testing technically tripped a clause in our terms of service. we will treat the report confidentially until coordinated disclosure, and we will credit you publicly in the release notes if you want credit. if you accidentally cross a line — you fetched a record you should not have, you triggered a database error that looked weird, you froze a queue — tell us promptly and honestly in the same email thread, and we will treat it as part of the good-faith testing, not as a separate incident. the only behaviour that ends the safe harbor is bad-faith behaviour: extortion ("pay me or i publish"), deliberate destruction, accessing other users' private data after the issue is already proven, or selling the finding to a third party before we have a chance to fix it.

what we do not have

we do not run a paid bug bounty programme. we have considered it; we have looked at hackerone and bugcrowd pricing; the revenue does not support it yet and we would rather be honest about that than run a "bounty programme" that pays in stickers and the word "kudos". we do not have a dedicated security team because we are six people total and everybody also ships product. we do not have a soc 2 type ii audit, an iso 27001 certificate, or any of the other badges that procurement departments at large companies require; the audits cost money we currently spend on engineering, and the customers we serve — independent developers, agencies, small teams, freelancers — have never asked for them. if you are an enterprise procurement officer evaluating us against a vendor checklist and one of the rows says "must have soc 2", we are not the right vendor for you yet, and we would rather you know that on day one than three weeks into a sales process. for everybody else: we read every report, we patch what we find, we publish what we fix, and we credit the people who tell us about problems honestly. that is the programme.

machine-readable

the standard security.txt file is published per rfc 9116 and points to the same support inbox. the pgp key referenced by the file is at /.well-known/pgp-key.txt and the fingerprint is mirrored inside the security.txt itself. automated scanners and disclosure platforms can use that file as the canonical entry point.