On this page
1. What this document is
This is a plain-language summary of TravelMedID's privacy posture — how data actually flows, what TravelMedID does and doesn't hold, and what legal frameworks apply. It supplements the full Privacy Policy rather than replacing it. If there is any conflict between this summary and the full policy, the full policy governs.
2. The on-device architecture
TravelMedID is a fully static web application — there is no server-side database, no user accounts, and no data transmitted to TravelMedID's infrastructure during normal use. All card data is stored in the user's own browser via localStorage, which is:
- Scoped to the user's specific browser and device
- Not accessible to TravelMedID remotely
- Encrypted at rest when App Lock is enabled (AES-256-GCM, key derived from the user's PIN via PBKDF2 with 100,000 iterations)
- Permanently deleted when the user clears their browser data
3. What TravelMedID actually holds
| Data type | Where it lives | Does TravelMedID see it? |
|---|---|---|
| Card fields (name, passport, medical, insurance, contacts) | User's browser localStorage | No |
| App Lock PIN | SHA-256 hash in localStorage — never the raw PIN | No |
| Backup file | User's own files (downloaded by the user) | No |
| Uploaded medical records / passport photo / insurance card | File name and upload state flag in localStorage — not the file itself | No |
| XRPL wallet address | localStorage (public address only — never the secret key) | No |
| XRPL anchor transaction hash | localStorage + published on the public XRPL ledger | Transaction hash only — not the card data |
TravelMedID's servers (Netlify static hosting) serve only the HTML, CSS, and JavaScript files that make up the application — no user data passes through them.
4. Medical records: the special case
Users may optionally upload medical records (images or PDFs). These are flagged as on-file in localStorage but the actual file bytes are not stored persistently — they exist only during the browser session in which they were uploaded. TravelMedID never receives, stores, or views the file contents.
Because medical records constitute sensitive consumer health data, TravelMedID treats this feature as subject to the following, regardless of how the data was provided:
- FTC Health Breach Notification Rule: TravelMedID is not a covered entity under HIPAA (records are provided directly by the user, not through a healthcare provider relationship), but complies with the FTC's Health Breach Notification Rule for consumer health apps.
- State health-privacy laws: Washington's My Health My Data Act, California's CMIA/CCPA, and equivalent laws in other states may apply. TravelMedID does not sell consumer health data and does not share it for purposes unrelated to providing the service.
- No secondary use: Uploaded records are not used for advertising, profiling, or any purpose other than displaying them back to the user.
5. Legal frameworks
| Framework | Applies? | How TravelMedID addresses it |
|---|---|---|
| HIPAA | No — not a covered entity or business associate | Records come directly from users, not through a healthcare provider relationship |
| FTC Health Breach Notification Rule | Yes | Treats health data as sensitive; complies with notification requirements |
| Washington My Health My Data Act | Yes (where applicable) | Does not sell consumer health data; provides deletion rights |
| California CMIA / CCPA / CPRA | Yes (where applicable) | Does not sell or share data; provides access and deletion rights |
| FTC Act Section 5 | Yes | No unfair or deceptive practices; privacy claims match actual architecture |
| State breach notification laws | Yes | On-device architecture minimizes breach surface; notification obligations apply to any data TravelMedID does hold |
TravelMedID is registered as a business in Michigan. Governing law for disputes is Michigan, with jurisdiction in Michigan courts, and a mandatory individual arbitration clause applies as described in the Terms of Service.
6. XRPL and blockchain data
When a user anchors their card, a SHA-256 hash of their card data is published to the XRP Ledger Mainnet. This is a one-way cryptographic fingerprint — it cannot be reversed to reconstruct the card's contents. The following is published on-chain and permanently public:
- The user's XRPL wallet address (a pseudonymous identifier)
- The SHA-256 hash of the card data at the time of anchoring
- The timestamp of the anchor transaction
7. Third-party relationships
| Third party | Role | Data shared? |
|---|---|---|
| Netlify | Static site hosting | No user data — serves HTML/CSS/JS files only |
| TW Global Protection | Travel insurance provider (outbound link) | No — user interacts directly with their own site |
| MoonPay | Crypto on-ramp (outbound link) | No — user interacts directly with MoonPay's platform |
| InstantCard | Physical card printing (outbound link) | No — outbound link only |
| VerraLinQ | Planned credential verification (pre-launch, not yet integrated) | Not yet connected |
| XRPL public nodes | Blockchain read/write for activation and anchoring | Wallet address and transaction hash — no personal or medical data |
8. User rights in practice
Because data is stored on the user's own device, most privacy rights are already satisfied by design:
- Access: The user views all their data directly in the application at any time.
- Correction: The user edits any field directly in the application.
- Deletion: The user clears browser data or uses the in-app delete options. Once deleted, TravelMedID holds no copy.
- Portability: The user downloads an encrypted backup file at any time via the "More" menu.
- Opt-out of sale: No sale occurs. TravelMedID does not sell personal or health data.
For any privacy-related requests or concerns, contact: travelmedidllc@gmail.com
9. Honest limitations
Additionally: the on-device architecture that minimizes TravelMedID's data exposure also means that if a user loses their device and has no backup, their card data cannot be recovered by TravelMedID — because TravelMedID never had a copy. This is a deliberate design tradeoff, not an oversight.