Security and vulnerability disclosure
How to report a security problem, and what we promise in return. Report in good faith and we will not pursue you.
Reporting a vulnerability
Email alpyalay@gmail.com with the subject "Security".
Please include what you found, where, how to reproduce it, and what an attacker could do with it. A proof of concept helps. If you would like to be credited, say so.
Please do not open a public issue, post it publicly, or disclose it before we have had a chance to fix it.
What we promise
- Acknowledgement within 5 working days.
- An initial assessment, with a rough timeline, within 14 days.
- Progress updates while we work on it.
- Credit when the fix ships, if you want it.
- We will tell you when it is fixed.
RealDex is maintained by one person. Response times reflect that, and we would rather commit to something realistic than to a 24-hour SLA nobody could honour.
Safe harbour
If you research in good faith and follow this policy, we will not pursue legal action against you and will not ask a third party to. If someone else initiates action over research that complied with this policy, we will make it known that your work was authorised.
Good faith means:
- Only accessing data that is yours, or a test account's
- Stopping as soon as you have confirmed a vulnerability — no pivoting, no lateral movement
- Not degrading, disrupting or denying service to other users
- Not exfiltrating, altering or destroying data
- Not using social engineering, phishing or physical attacks against anyone
- Giving us reasonable time to fix it before disclosing
- Not demanding payment in exchange for withholding disclosure
That last one matters. There is no bug bounty, and a report conditioned on payment is not a security report — it is something else, and it forfeits this safe harbour.
Scope
In scope
- The RealDex mobile app, iOS and Android
realdex.alpyalay.org- Our Firebase Cloud Functions endpoints
Out of scope — report these to the vendor, not to us
- Google Firebase, Gemini, AdMob infrastructure
- RevenueCat
- The Apple App Store and Google Play
- Web3Forms and Google Forms
Also out of scope: findings from automated scanners with no demonstrated impact, missing headers with no exploitable consequence, social engineering of the developer, denial of service, and issues requiring a rooted or jailbroken device plus physical access.
How data is protected
RealDex is built local-first, and that is the substantive protection: your photos, your collection and your saved locations are on your device and nowhere else. There is no server-side store of user media or location data to breach. No account, no password, no email address for app data.
For the small amount we do hold:
- TLS on all traffic between the app and our services; the iOS build disallows arbitrary insecure loads
- Firestore security rules restricting records to the device identifier they belong to
- Rate limiting on cloud identification endpoints
- Administrative access limited to a single operator with multi-factor authentication — no shared credentials, no staff accounts
- Cloud infrastructure operated by Google and RevenueCat, under their own certified security programmes
What we do not claim
- No SOC 2 or ISO 27001 certification
- No third-party penetration test
- No bug bounty programme
- No 24/7 security monitoring
These would be easy to imply and untrue. RealDex is a solo-developed app, and its security posture rests on holding very little rather than on defending a lot.
If there is a breach
If a personal data breach occurs that requires notification, we will notify the competent supervisory authority within 72 hours where the GDPR, UK GDPR or KVKK Board Decision 2019/10 requires it, and notify affected users without undue delay where the risk threshold is met.
We will tell you what happened, what data was involved, what we have done, and what you can do — in plain language, without minimising it.
Related pages: Privacy Policy · Terms of Service · Data deletion