Reporting a security vulnerability
If you have found a weakness in our app, our servers or this website, we want to hear about it and we will not treat you as an adversary for telling us.
- Report to one address
- No legal action for good-faith research
- Acknowledged in 5 working days
How to report
Email [email protected] with the subject Security vulnerability. Describe what you found, where, and the steps to reproduce it. If a proof of concept helps, include it; if it involves data belonging to somebody else, describe it rather than sending it.
We aim to acknowledge within five working days. We ask that you give us a reasonable period to fix an issue before publishing it, and that you avoid accessing other people's data, degrading the service, or acting in a way that would harm a user.
In force since
What we commit to
- An acknowledgement within five working days, from a person rather than an automated reply.
- An honest assessment. If we think a report is not a vulnerability we will explain why, rather than closing it silently. If we agree, we will tell you roughly when we expect to fix it.
- No legal action for good-faith research conducted within the scope below. We will not pursue or support a claim against a researcher who follows this policy, and we will treat a report as a contribution rather than an attack.
- Credit if you want it. We will acknowledge you by the name or handle you choose when the fix ships, and we will not name you if you would rather remain anonymous.
- Confidentiality. We will not share your identity with anybody outside the company without your agreement, unless we are legally compelled to.
- What we cannot offer: a paid bug bounty. This is a small company and there is no reward programme. We would rather say so plainly than imply otherwise.
Scope
In scope: the Telvio mobile applications, the API and servers they communicate with, and this website. Anything that could expose a user's call records, credit balance or installation identifier, allow calls to be placed at somebody else's expense, or allow a number displayed on a call to be altered, is of particular interest.
Out of scope: findings from automated scanners with no demonstrated impact; missing security headers with no exploitable consequence; anything requiring physical access to an unlocked device; social engineering of our staff or our users; denial of service; issues in third-party services we use, which should go to those services directly; and reports about the absence of a feature — a rate limit that could be stricter, an option we do not offer — rather than a defect in one that exists.
Please do not test in ways that affect other people. Do not access, modify or delete data that is not yours, do not degrade the service for users, do not place calls at another user's expense to prove that you can, and do not use automated tooling at a volume that amounts to a denial-of-service test. If you need an account or credit to demonstrate something, ask and we will arrange it.
How the service limits what a breach could expose
The most effective security control available to a consumer service is not holding the data in the first place, and that is the main one in use here. There is no registration, so there is no user database: no names, no email addresses, no phone numbers and no passwords exist to be stolen, and there is nothing for credential stuffing to attack because there are no credentials.
Payment is processed entirely by Apple and Google. We never receive a card number, an expiry date, a billing address or any other payment credential — only a signed receipt identifier. A compromise of our systems could not expose a payment instrument, because none is stored.
Call audio is never recorded. It is carried in encrypted form for the duration of the call and does not exist afterwards in any form. Contact lists are never uploaded: if the app is granted contacts access, the list is read on the device so a number can be chosen, and it stays there. Precise location is never collected.
What does exist, and what a breach would therefore expose, is set out honestly in the privacy policy: an anonymous installation identifier holding a balance, call records of the kind a phone bill contains, purchase receipt identifiers, and technical data including IP addresses. Call signalling and audio are encrypted in transit, as is all traffic between the app and our servers, and access to call records is limited to the people who need it to run the service.
Security questions that are not vulnerabilities
Three things get reported regularly that are working as intended, and it saves everybody time to state them here.
Every call displays the same number. That is deliberate, published on its own page, and is the opposite of a caller ID weakness: the app offers no way to present any other number, which is the property that makes it unusable for the impersonation most telephone fraud depends on.
There is no login, and that is not a missing authentication control. There is no account to authenticate to. The installation identifier is a bearer token for a credit balance and is treated as one; anybody able to read it from a device could spend that balance, which is why it is not displayed except in settings and why device compromise is out of scope.
The app cannot receive calls or messages. A report that inbound calls are not authenticated is a report about a capability that does not exist. There is no inbound path at all.
What a useful report contains
None of this is required and all of it shortens the exchange. A report we can reproduce is a report we can fix; a report we cannot reproduce becomes a conversation, and conversations are slower for everybody including the person who found the problem.
- Where it is — the app and its version, an API endpoint, or a URL on this website. The three have different owners internally and knowing which one it is routes the report immediately.
- What you did, in order. The steps someone else would follow to see the same thing. A sequence of requests is ideal; a description of the shape of the problem is fine.
- What you saw, and what you expected instead. This is the part that distinguishes a finding from a scanner's opinion.
- What an attacker could do with it. Not a demand for a full exploit chain — a sentence about the realistic impact, which is what decides how quickly it is fixed.
- Whether you want credit, and under what name or handle. We will use whatever you say, including nothing.
- Not other people's data. If your finding involves somebody else's records, describe it rather than sending it. We do not want it and you should not be holding it.
What happens after you send it
A person reads it and replies, within five working days and usually sooner. The first reply either says we have reproduced it and roughly when it will be fixed, or asks the one question we need to reproduce it, or explains why we do not think it is a vulnerability. We do not close reports silently, and we do not send an automated acknowledgement and then nothing.
For anything with real impact, the fix ships and we tell you it has. We ask for a reasonable period before publication — long enough to fix and release, which for a mobile app includes an app store review cycle outside our control — and we will tell you honestly if that is going to take longer than usual rather than letting a deadline pass in silence.
If we disagree with you, we will say so and say why, and you are free to publish that disagreement. A disclosure policy that only works when the researcher agrees with the vendor is not a policy.
Bottom line
Email [email protected] with the subject “Security vulnerability”, describing what you found and how to reproduce it. Acknowledgement within five working days, from a person.
Good-faith research within the scope above will not be met with legal action, and we will credit you if you want it. There is no paid bounty, and we would rather say so than imply otherwise.
The service is designed to hold very little: no accounts, no passwords, no payment details, no call recordings, no contact lists and no location. That is the security control doing most of the work.
Frequently asked questions
How do I report a security vulnerability to Telvio?
Email [email protected] with the subject Security vulnerability, describing what you found, where, and the steps to reproduce it. We aim to acknowledge within five working days and ask for reasonable time to fix an issue before it is published.
Does Telvio have a bug bounty programme?
No. There is no paid reward programme. We commit to an acknowledgement from a person, an honest assessment, credit if you want it, and no legal action for good-faith research within scope.
Will Telvio take legal action against a security researcher?
Not for good-faith research conducted within the published scope. We will not pursue or support a claim against a researcher who follows this policy and avoids accessing other people's data or degrading the service.
What would a breach of Telvio's systems expose?
An anonymous installation identifier holding a credit balance, call records of the kind a phone bill contains, purchase receipt identifiers and technical data including IP addresses. No names, email addresses, phone numbers, passwords, payment details, call recordings, contact lists or location data exist to be exposed.
Are Telvio calls encrypted?
Call signalling and audio are encrypted in transit, as is all traffic between the app and the servers. The final leg of any call to an ordinary telephone number is carried by the traditional telephone network, which is outside the app's control and is not encrypted end to end — that is true of every service that dials a real phone.
Why does Telvio have no password?
Because it has no account. Nothing is registered, so there is no credential to protect and nothing for credential stuffing to attack. The installation identifier acts as a bearer token for the credit balance, which is why device compromise is treated as out of scope.
How long should I wait before publishing a vulnerability?
Long enough for a fix to be built and released, which for a mobile app includes an app store review cycle we do not control. We will tell you our expected timeline in the first reply and tell you honestly if it slips, rather than letting a deadline pass without comment.
Will Telvio tell me when a reported issue is fixed?
Yes. We do not close reports silently. The first reply either confirms we have reproduced the issue with a rough timeline, asks the one question needed to reproduce it, or explains why we do not consider it a vulnerability.
