Shared responsibility
This policy explains current safeguards and practical account precautions. It is not a certification, an audit guarantee or a promise that incidents cannot occur. Deployment operators are responsible for secure hosting, transport, access permissions, updates and recovery arrangements.
Safeguards in the application
MastLog uses account-scoped database queries, server-side authorization, password hashing, hashed application session tokens and encrypted provider sessions. Provider ciphertext is bound to its user and provider where applicable. New-account policy and adult acknowledgments are checked by the server and their version and timestamp recorded.
Protect your sign-in
Use a unique, strong password and protect the email account you use to sign in. Enable additional protection on your email and provider accounts where available. Sign out on shared devices and do not share MastLog cookies or provider sessions. Matching authenticated provider email addresses can lead to the same MastLog account, so keep those provider accounts secure.
Connecting and disconnecting safely
Only connect accounts you control. Authentication can require a provider's verification challenge; do not send codes or passwords to support contacts. Provider passwords are used for the requested authentication, while reusable sessions may remain encrypted until disconnection. Disconnect an unused or compromised connection and review its public showcase permissions.
What encryption does and does not cover
Provider sessions are encrypted in application storage; local passwords and MastLog session tokens are hashed. Journal records are stored in the database and are not end-to-end encrypted. A production installation must secure HTTPS, database access, encryption keys, backups and administrative permissions. Local development may use HTTP and is not evidence of production transport protection.
Reporting a vulnerability
Send vulnerability reports privately to support@mastlog.com. Include affected routes, reproducible steps and impact using synthetic data. Never access another person's journal, extract real records, interrupt the service or publish credentials to demonstrate a bug. Obtain authorization before intrusive testing. This policy does not establish a paid bounty or unrestricted permission to attack.
Response and incident limits
Reports should be evaluated and affected users or authorities notified when applicable law requires it. Response times, backup schedules and infrastructure guarantees must be defined by the actual operator; this installation does not publish an SLA. Do not treat a browser screenshot, test result or encryption claim as proof that every deployed component is secure.
Keep reports private
Send only the information necessary to reproduce the issue to support@mastlog.com. Avoid private content, passwords, tokens, authentication cookies and identity documents. A public issue tracker is not a suitable place for intimate records or exploitable secrets. Contact dmca@mastlog.com for copyright complaints and insprations@mastlog.com for suggestions; security reports belong in the support channel.
Security reports: support@mastlog.com
If you suspect compromise
If you suspect compromise, stop using the affected session, sign out, secure your email and relevant provider account and disconnect compromised connections where possible. Contact support@mastlog.com privately. For immediate risks to personal safety, seek appropriate local assistance; MastLog is not an emergency response service.