- Password hashes and private sessions
- Backups are a recovery measure
- Different lifecycle for different records
On this page
1. Security scope
This statement describes implemented safeguards and known operational limits. It is not a penetration-test certificate, SOC 2 report, cybersecurity warranty or representation that all vulnerabilities have been eliminated.
Public stories are designed for broad distribution; member profile photos, non-published media and security tokens have separate private-access controls. Authentication and administrative privileges are managed server-side.
2. Account credentials and access controls
Passwords are stored as one-way hashes rather than readable credentials. Account sessions use token hashes server-side and protected browser cookies. The privileged Studio has role-based authorization boundaries and stricter session duration than member accounts.
Site requests are protected by same-origin checks, rate limits and limits on upload types and sizes. Users should protect their recovery details and sign out on shared devices.
3. Uploaded photos and publishing
Member avatars are processed into a smaller image format and metadata is stripped during processing. Changes and removals are available to the signed-in account holder. Private uploads are not treated as public merely because the file exists.
When you intentionally submit an approved public comment, public guestbook note or other published submission, it can be accessible to visitors. Take care not to submit third-party private information in a public contribution.
4. Retention by record type
Raw first-party reading and portfolio website measurement data is normally cleaned up after 90 days. Published articles and associated approval records follow the publishing lifecycle rather than the analytics cycle.
The signed visitor token used for reactions can remain in a browser for up to one year; member login cookies have an approximately seven-day lifetime and privileged Studio cookies an approximately eight-hour lifetime. Revocation or password changes may invalidate an otherwise unexpired session.
Expired session rows, rate-limit windows and short-lived realtime event records are cleared in background maintenance. Longer-lived membership records, moderation evidence and audit events remain subject to their service purpose and any lawful retention obligations.
5. Backups and deletion lag
The current offsite-backup scheduler uses a default retention setting of 30 days for verified recovery snapshots. Operational configuration may modify that setting. Backups are verified for recoverability and should not be used as a hidden public archive.
A verified data-erasure request can require removal from active storage before aged backup copies expire. If restored backups contain data that has since been deleted, that data should be re-evaluated and removed from the restored active service as appropriate.
6. Incident reports and service disruption
For a vulnerability, lost device, unauthorized account activity or exposed content, contact connect@vamsimarripudi.me privately. Do not send passwords, OTPs or exploit data that would put visitors at risk.
If an event requires notification or assistance under applicable law, the operator will assess the actual incident and the relevant statutory duty. No fixed notification time is guaranteed here where no such deadline currently applies.
7. Requests, review and corrections
Use the signed-in account’s Privacy & Data section or contact email for a data export, correction or deletion review. Requests affecting someone else’s information may require sufficient legal authority.
Retention periods are reviewed as security needs and Indian legal requirements evolve. See the DPDP Notice and Grievance Policy for the broader rights framework.