Security

Run routes, voice recordings and health measurements deserve careful handling. We use administrative and technical controls intended to prevent unauthorised access, loss, alteration and disclosure. We review controls as the service and its dependencies change.

No connected service can guarantee absolute security. This page describes our approach; it is not a warranty that every attack or fault will be prevented.

• Encrypted connections between supported clients and our service.
• Access restrictions intended to limit production data to authorised people and service accounts with a work-related need.
• Private storage, authentication controls, operational logging and monitoring used to find faults or suspicious activity.
• Dependency maintenance, backups and recovery procedures appropriate to the service.
• Contractual confidentiality and data-handling duties for providers that process information for us.

We do not publish configuration details that could make the service easier to attack.

Solo Run uses short-lived email sign-in codes and supported identity providers. Keep your email and device secure, install operating-system and app updates, use a screen lock and review the location and Activity Sync permissions you grant. Never share a sign-in code. We will not ask for your password or code by email.

If you lose a device or suspect account access, secure the connected email or identity account first, then contact hello@moriurban.com.

Email hello@moriurban.com with the subject “Security report.” Include the affected URL, app version or feature; the date observed; the potential impact; and clear reproduction steps. Screenshots or proof-of-concept code are useful, but remove personal data, tokens and precise routes.

Do not send a vulnerability through a public issue, social network or app-store review. If ordinary email would expose sensitive material, ask us for a safer transfer method before sending it.

We welcome reports made to improve Solo Run’s security. Research must stay within these limits:

• Use accounts and data you own or have written permission to test.
• Stop immediately if you encounter another person’s data; do not copy, retain, alter or disclose it.
• Do not use denial-of-service testing, malware, automated traffic that harms availability, physical intrusion or social engineering.
• Do not access more data or execute more commands than needed to show the issue.
• Give us a reasonable chance to investigate and fix the issue before public disclosure.

We will not pursue civil action against good-faith research that follows this policy, avoids privacy harm and complies with applicable law. This statement does not authorise access to third-party systems or waive rights held by another party.

We review credible reports, may ask follow-up questions, assess impact and prioritise a fix based on risk. We may coordinate a disclosure date with the reporter. We do not promise a reward, public credit or a fixed remediation date.

If we confirm a personal-data incident, we will contain and investigate it, preserve necessary records and notify affected people or regulators when applicable law requires notice. Security reports themselves may be retained to document the issue and our response.