XtrkR is operated by De Nihil LLC, a Wyoming limited liability company. In this policy, “I” refers to De Nihil LLC.
XtrkR is built so the data you enter stays on your device, not on servers I operate. There are no XtrkR accounts, no XtrkR cloud database, and no third-party ad or analytics SDKs in the app. Some Apple-provided services and optional features may involve limited data processing outside the app’s local storage environment, as explained below. But as a general matter, I do not have technical access to the health records you store in XtrkR.
For Washington residents and others interested in consumer-health-data-specific disclosures, see the Consumer Health Data Privacy Policy.
XtrkR stores the following categories of data locally on your device using Apple’s native frameworks:
This data is designed to stay on your device unless you choose to use a feature that involves Apple services or you choose to export, back up, or share information yourself.
This privacy policy primarily addresses the XtrkR iOS app. The marketing website at xtrkrapp.com is a separate surface with its own minimal privacy posture.
No cookies. No third-party trackers. No analytics SDKs. The site sets no browser cookies and embeds no Google Analytics, Plausible, Meta Pixel, or similar tracking scripts. You can verify this in your browser’s developer tools.
First-party campaign attribution. When you visit the site with a campaign-tracking URL parameter (e.g. ?ref=reddoor from a clinic’s distribution card), our server logs the visit with three things: an anonymized IP address (last octet truncated to zero — your full IP is never stored), a timestamp, and the campaign tag value. Visits without a ?ref= parameter are not logged by this system.
This is attribution — knowing which distribution channels brought you to the site so we can prioritize them — not surveillance. It’s the same kind of measurement a podcast uses when it asks listeners to use a unique promo code per sponsor.
Where the data lives. The log file is stored on our hosting server in a directory only the operator can access. It is never shared with third parties, never synced elsewhere, and deleted on request to hello@xtrkrapp.com.
Standard server logs. Like every web server in existence, our hosting provider (Hostinger) maintains standard access logs at the infrastructure layer that we do not directly control. These are governed by Hostinger’s own privacy policy.
XtrkR can optionally write certain sexual activity data to Apple Health if you choose to enable that feature. This feature is off by default and is write-only, which means XtrkR can write approved data to Apple Health if you enable the feature, but XtrkR does not read data from Apple Health. Any data written to Apple Health is then subject to Apple’s Health privacy framework and your Apple device settings.
XtrkR can optionally create encrypted backups to your iCloud Drive. This feature is off by default and only works if you choose to enable it. Backups are encrypted on your device using AES-256-GCM before being saved to your personal iCloud Drive. I cannot access, decrypt, or read those backup files.
XtrkR stores your PIN hash and, if you enable backups, your backup-related credentials in the device Keychain. Keychain data is protected by iOS device security and is not synced to iCloud Keychain.
If you choose to add a location to an encounter, that location information is stored locally in the app on your device. If you use the geocoding feature, XtrkR sends those coordinates to Apple’s MapKit service to translate them into a city or place name. That request goes to Apple and is subject to Apple’s privacy terms; the coordinates are never sent to any server I operate, and I never receive or store them. If you don’t use geocoding, no location data leaves your device.
Photos you choose to save in XtrkR are stored locally in the app on your device. If you create an encrypted backup, those photos are included in that backup. XtrkR does not upload your photos to servers I operate or share them for advertising or analytics purposes.
All payment processing for in-app purchases is handled by Apple through StoreKit. I do not receive or store your payment card information.
Notifications are generated locally on your device — not pushed from a server. Discreet mode (on by default) uses generic titles for privacy.
XtrkR carries a 17+ rating on the Apple App Store. To use XtrkR, you must be at least 18 years old — on first launch, the app prompts for your date of birth and will not unlock until you reach 18. I do not knowingly process data from anyone under 18.
Since all data is stored locally, you have complete control. Delete individual records in the app, or delete the app to remove all data. Because XtrkR does not keep a server-side copy of your records, there is no separate deletion request process through me for data stored only on your device.
If you choose to email me at hello@xtrkrapp.com, abuse@xtrkrapp.com, or any of the alias addresses, your message lands in a Google Workspace inbox that I control. Google’s standard privacy terms apply to that inbox in addition to the discipline I describe here.
What I ask of you: please don’t include personal health details (specific medications, test results, partner names, diagnoses) when you write to me. I can almost always help without them. If you do include them, I treat the email as sensitive data the moment it arrives.
What I do with support emails: I delete support threads once the conversation is resolved. I never forward emails containing health details to anyone. I never paste them into third-party tools or AI assistants. I do not maintain a separate CRM, database, or archive of who said what about their health.
Security: the Google Workspace account uses strong two-factor authentication. If you have access to a Workspace account, you know nothing is unbreachable — but the retention discipline above means that even in a worst-case account compromise, there is very little identifiable health data sitting there to lose.
Because the app does not store your data on any server I operate, I have nothing to produce in response to a subpoena, court order, or legal request about your in-app records. If you have emailed me support requests that contain health details, those emails could in principle be reached by a subpoena to me or to Google — which is one reason I purge support threads after resolution and ask you not to include health details in the first place. Your device itself may be subject to a warrant or physical seizure by law enforcement — this applies to all data on your phone, not just XtrkR. If you use encrypted iCloud backups, Apple could be compelled to produce the encrypted file, but it cannot be read without your password.
XtrkR is designed so that the records you enter are accessible to you on your device, can be deleted by you at any time, and can be exported by you in CSV, JSON, or encrypted backup form. Because XtrkR does not keep a server-side copy of those records, there is generally no separate access, correction, or deletion workflow through me for data stored only on your device. I do not sell your personal information or disclose your health records for advertising or analytics purposes.
If you believe your personal data has leaked, someone has content about you in their XtrkR, you encounter non-consensual intimate imagery, or you have any other privacy concern, please email abuse@xtrkrapp.com.
Response time: I respond to abuse and privacy reports within 72 hours. As a solo operator, that’s an honest timeline — not a 24-hour promise I can’t keep.
What I can do: Triage bug reports, answer privacy questions, and forward applicable reports to the app user whose device holds the content. For non-consensual intimate imagery or imagery of minors, I will coordinate with law enforcement and, where relevant, file a report with NCMEC’s CyberTipline.
What I can’t do: Reach into a user’s device to delete content. XtrkR has no server access, no accounts, no cloud sync I control — the data lives only on the user’s phone. Reports are handled at the user-account level (termination, notice) and through coordinated takedown, not remote deletion.
If I update this policy, I will update the “Last Updated” date. Given the app’s local-storage architecture, meaningful changes would likely only occur if the app’s fundamental design or data flows change.
General inquiries, bug reports, and feature requests: hello@xtrkrapp.com
Abuse or privacy concerns (72-hour response): abuse@xtrkrapp.com