Security

Security and data breach notification

Version 1.0 · Last updated 5 September 2026

Habitus Mind holds account credentials, health data and details of people you know. This page tells you how to report a problem, and — if the worst happens — exactly what we will do and what we will tell you.

1. Scope

This policy covers habitusmind.com and the other web properties we operate, including lab.yappatyih.com. Report issues in any of them here.

2. Reporting a vulnerability

Use either channel — both reach us directly:

Contact form — habitusmind.com/contact. Start your message with SECURITY so it is not triaged as a general enquiry.
WhatsApp — +60 12-210 4914.

Please include which URL is affected, what the issue is, how severe you think it is, the steps to reproduce it, and how you would like to be credited.

We know this is not the channel you would have chosen. We publish no email address, so neither route accepts file attachments — no scripts, screenshots, HTTP captures or archives — and neither lets you encrypt what you send.

So describe the issue in text, and if a file is genuinely needed to demonstrate it, say so in your first message and we will agree a secure way for you to send it rather than asking you to paste it into a web form. If you would rather hold the details until a private channel exists, say that — we treat the date you first made contact as the disclosure date, not the date the details arrived.

Please report privately and give us a fair chance to fix the issue before disclosing publicly. We suggest 90 days as a default and would rather agree a different window with you than leave you waiting in silence. Machine-readable details are at /.well-known/security.txt.

3. Safe harbour

If you make a good-faith effort to follow this policy we will treat your research as authorised, will not pursue legal action against you, and will not report you to law enforcement. Good faith means:

you stop as soon as you have confirmed a vulnerability, and go no further into the system than needed to demonstrate it;
you do not access, modify, delete or retain another user's data. This service holds health records and contact details of people who never signed up here — if you encounter personal data, stop immediately and tell us;
you use your own test account, not someone else's;
you do not degrade the service: no denial-of-service, no load testing, no spam, no social engineering of us, our users, or our providers;
you keep what you find confidential until we have had a chance to fix it.

We cannot waive the rights of third parties. Our infrastructure providers have their own testing rules, and this policy does not authorise you to break them.

4. Out of scope

Automated scanner output with no demonstrated impact.
Missing hardening headers or best-practice suggestions with no working exploit.
Vulnerabilities in third-party services we merely use.
Denial of service, volumetric attacks, and social engineering.
Anything requiring physical access to a device, or an already-compromised device.

5. What we will do

This is a small operation, so these are commitments we can actually keep rather than enterprise-sounding numbers we cannot:

Stage	Target
Acknowledge your report	Within 3 business days
Initial assessment and severity rating	Within 10 business days
Fix for critical or high severity	As fast as possible, with updates at least every 7 days
Fix for medium or low severity	Best effort, with an honest estimate rather than silence
Tell you when it is resolved	Always

6. Data breach notification

If personal data held here is exposed, altered, lost, or accessed without authorisation, we will:

Contain it first — close the access route, invalidate sessions, rotate affected credentials, and preserve logs and evidence before changing anything else.
Assess the risk to the people affected: which data, how many people, and what could realistically be done with it. Because this service holds health data and contact records, we assume a higher risk rating unless the evidence shows otherwise — not the reverse.
Notify the supervisory authority within 72 hours of becoming aware, where the GDPR applies and the breach is likely to result in a risk to people's rights and freedoms (Article 33). If we cannot give full details in time, we notify on time and follow up with the rest.
Notify the Personal Data Protection Commissioner in Malaysia as soon as practicable and within the deadlines set by the PDPA and its breach notification requirements.
Notify the people affected without undue delay where the breach is likely to result in a high risk to them (Article 34), or where the PDPA requires it. Where a breach involves fitness or health records, we will tell the people concerned even if we are not strictly obliged to.
Consider people who never signed up. If contact records are involved, the people exposed may be third parties recorded by our users rather than our users themselves. We will tell the account holder so they can inform them, and notify directly where we can and should.
Record every breach — including those below the notification threshold — with the facts, effects, and action taken, as Article 33(5) requires.

We will not delay telling you because a fix is unfinished, and we will not downplay an incident to avoid embarrassment.

7. What we will tell you

In plain language, without assuming you know how the system works:

what happened, and when we found out;
what categories of data were involved, and roughly how many people;
the likely consequences for you;
what we have done to contain it and stop it recurring;
what you should do — change a password, watch for phishing, warn a contact;
who to contact for more, and when the next update will come.

8. How we protect data

PBKDF2-SHA256 password hashing with a unique random salt per user and constant-time comparison. Passwords are never stored, logged or transmitted in the clear.
Optional TOTP two-factor authentication, secret stored encrypted.
256-bit random session tokens verified server-side on every request, so revocation is immediate rather than waiting for a token to expire.
Rate limiting and lockout on repeated failed sign-ins.
A Content Security Policy with no unsafe-inline scripts, HSTS, and CSRF protection on state-changing requests.
API responses select explicit columns, so password hashes and secrets are never serialised into a response.

9. No bounty

We do not run a paid bug bounty — there is no security budget. We will credit you by name on this page if you want that, and thank you properly. Please do not report in the expectation of payment.

10. Contact

Security reports: the contact form with SECURITY as the first word, or WhatsApp on +60 12-210 4914. Privacy questions belong in the privacy notice instead.