Security
There is no password on your account, on purpose.
The thing worth protecting on an Orbislo account is a wallet balance that does not expire and an eSIM profile that connects a person a long way from home. Both are more valuable than they look, so here is exactly how they are held.
Passwordless by default
Most accounts are not lost to clever attacks. They are lost because a password was reused on a site that later leaked it, and somebody tried the same pair here. Removing the password removes that entire class of failure.
Sign in is a one time code to your email as the floor, and a passkey as the recommended setting.
A passkey is a key pair created and held by your device, protected by the same face or fingerprint that unlocks the phone. The private half never leaves the device and never reaches us.
The browser will only offer it to the real orbislo.com origin, which is what makes it resistant to phishing in a way a code in an email is not. Setting one up is a single tap in your account, and you can hold as many as you like across your devices.
Sign in methods, compared
| Sign in method | Resists phishing | Survives a leak elsewhere | Works with no signal |
|---|---|---|---|
| Passkey, recommended | Yes, bound to the origin | Yes, nothing shared to leak | Yes, the key is on the device |
| One time code by email | Partly, a convincing fake can still relay it | Yes, no stored secret | No, you need to reach your mail |
| Password, not offered here | No | No, reuse is the usual cause | Yes, which is its only advantage |
| Code by text message, not offered here | No | Partly | No, and it fails exactly where you are abroad |
Text message codes are absent deliberately. A travel product that sends a verification text to a home number you cannot receive abroad has designed its own lockout.
Sessions, devices and getting back in
A session is a convenience, so it is short enough to matter and long enough to be usable. The rules below are the whole policy.
- A session lasts 30 days of activity on a trusted device, then asks you to sign in again
- Buying, changing your email address or moving a profile to a new phone always re authenticates, whatever the session age
- Every active session is listed with its device, its rough location and its last use, and any one can be ended from any other
- Ending all sessions also rotates the tokens behind them, so a stolen cookie stops working immediately rather than at expiry
- Signing in from an unrecognised device sends you a notice with the time and the rough location, whether or not it was you
- Your balance belongs to the account rather than the handset, so a lost phone is not a lost wallet
Payments, and why we hold no card data
Card details are collected by a payment processor certified at the highest level, inside a frame we do not have access to. The number goes from your device to them without passing through anything we run.
We receive a token that is only usable through that processor and only for your account, plus the brand and the last four digits so you can tell one card from another.
The practical consequence is worth stating plainly. If our systems were breached tomorrow, there would be no card numbers in them to take.
That is not a claim about how good our engineers are. It is a claim about what we chose not to store, which is a much stronger thing to rely on. Refunds, including the automatic one that fires after a failed provisioning, run through the same processor back to the original card.
The coverage dataset, designed not to identify you
Every speed figure on our coverage pages comes from real traffic on real customer sessions rather than from synthetic speed tests, because a speed test spends your data to tell us something we can already measure for free.
That design creates an obvious privacy question, so here is the answer in engineering terms rather than in reassurance.
1 km
geohash precision, never a precise position
25
distinct samples before anything is published
0
browsing history or message content collected
1 tap
to switch measurement off, effective immediately
The sample floor is the control
A measurement carries the carrier, the radio type, throughput observed on traffic you were already sending, and a geohash of roughly one kilometre. Records are aggregated before anyone sees them, including us.
The 25 sample threshold is the important part, because it is a k anonymity floor. A published figure is always the behaviour of at least 25 distinct sources in a cell, which makes picking out one person impractical by construction rather than by policy.
Where a cell has fewer than 25 samples, the page shows no data. We would rather have a gap than a number that describes one traveller.
Measurement is explained at onboarding rather than buried, and one switch turns it off. Turn it off and the published dataset loses your contribution, and nothing else about your service changes. The full detail sits in the privacy policy.
How we build
None of these are unusual. They are listed because a security page that only describes the exciting parts is hiding the ordinary ones.
- Least privilege by default, with production access granted for a task and expiring on its own
- Dependency and container scanning on every pull request, and a merge is blocked by a critical finding
- Secrets held in a managed store, never in a repository, rotated on a schedule and on any departure
- Data encrypted in transit and at rest, with European customer records stored in the European Union
- An independent penetration test annually, and again after any change to the authentication or payment path
- Subprocessors published, and the list updated before a change takes effect rather than after
Responsible disclosure
Write to security at orbislo.com. A human replies inside 24 hours and a triage decision follows inside 72. Tell us what you found, how to reproduce it and what you think the impact is.
We will keep you updated until it is closed, and we will credit you by name in the fix notes if you want that.
Scope, and our promise to researchers
In scope: orbislo.com and its subdomains, the iOS and Android apps, and the public API. Out of scope: denial of service testing, social engineering of our staff or our carriers, physical attacks, and anything that touches data belonging to another customer.
Please do not access, modify or keep data that is not yours, and give us a reasonable window before publishing.