[Proposal] Web Flash Call API for Secure Phone Number Verification

[Kebba Jallow]

Hello Chromium Devs,

I'd like to propose a new Web API to enable a more user-friendly and secure method for phone number verification: the Web Flash Call API.

The Problem

The current standard for web-based phone number verification relies on SMS One-Time Passwords (OTPs). This method introduces significant user friction. Users must:

1. Leave the web application.
2. Open their messaging app.
3. Copy a code.
4. Return to the web app to paste the code. This process is cumbersome and can lead to user drop-off. 😥

A superior alternative, flash call authentication, exists in the native app ecosystem. It works by placing an automated, single-ring call to a user's phone, with the caller ID containing a unique verification code. The native app then reads this code from the device's call logs to verify the user without any manual input. This is not possible on the web platform due to critical security sandboxing.

Proposed Solution: A Secure Picker API

I propose a new, dedicated Web API that enables this functionality without compromising user security. The API would not grant a website direct access to a user's call logs. Instead, it would act as a secure, browser-managed "picker," similar to the Web Share or File System Access APIs.

The API would work as follows:

1. A web application calls the proposed API, for example, navigator.telephony.flashCall(), passing the user's phone number.
2. The browser's operating system displays a clear permission prompt to the user, requesting consent to listen for a flash call from the service.
3. If the user grants permission, the browser's underlying platform listens for a single incoming call to that specific number.
4. When the flash call is received, the browser securely extracts only the last few digits of the caller ID.
5. This sanitized data is then passed back to the web application as a promise result. The web page never gets to see the full call log, and the process is completed automatically for the user.
6. The web app can then send this extracted code to its backend for verification.

This approach provides a seamless user experience while strictly adhering to Chromium's privacy and security principles.

Security and Privacy Considerations

This proposal is designed to directly address the security concerns of accessing sensitive data.

• No Direct Call Log Access: The web page is completely isolated from the user's call history. It only receives the specific, sanitized verification code needed for the transaction.
• Explicit User Consent: The API requires a clear, explicit permission grant from the user, ensuring they are always in control.
• Data Minimization: The amount of data shared with the web page is minimized to only what is necessary for the single verification task.

This solution offers a pragmatic way to bring a critical native app feature to the web, improving the user experience for web-based applications that require phone number verification, such as web-based phone apps.

I look forward to your feedback and discussion.

Best regards,

Kebba

[Reilly Grant]

It's not clear to me what the benefit of using a flash call over an SMS message is. The SMS-based approach is already possible on the web using the WebOTP API without the steps you list above.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAJPYs8kOq3CaezFq3tUqLiH3DSS1_CwwbHncj4okwUx%3D1K8jQg%40mail.gmail.com.

[Godday Ajie]

Not Clear to  me either please explain how to used it.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEmk%3DMZyHH0-L7Vk743sEE3VFfPWpCcV80t9NKJR5kR6D36XJw%40mail.gmail.com.

[anppraveen akki]

Hi,

Please refer 

https://youtu.be/xt5F2sSzTnM?feature=shared 

For more information.

Thanks & Regards

A N P Praveen

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAM6icLwrDezn36UYS-nE1K%3Dr7tQcCeRfsXwCMXO4S21LQGL4mg%40mail.gmail.com.

[Kebba Jallow]

Hey Reilly, thanks for the feedback.

You're right that WebOTP is a great solution for SMS-based verification on the web. However, our team has already implemented a flash call authentication system for our web app for a couple of key reasons:

 * Enhanced Security: Flash call verification is generally more secure than SMS because it's less susceptible to SIM swap attacks.

 * Cost-Effectiveness: Our SIP provider offers flash calls for free, making it a more economical solution for us.

The current setup requires users to manually check their call logs to find and input a 6-digit number for verification, which creates friction. Our main goal now is to find a way for the web app to access the call log and automate this process, providing a seamless user experience that matches the low friction of WebOTP, while still leveraging the security and cost benefits of flash calls.

We're looking into potential solutions to bridge this gap and make the flash call method as smooth as possible for our users.

[Reilly Grant]

I doubt there's any security benefit. A SIM swap attack will redirect calls just as much as SMS messages. It sounds like the benefit is mainly that networks don't currently charge for flash calls. I wonder whether they will eventually catch on and start charging providers that are exploiting this billing loophole.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

[Godday Ajie]

I hope so too!

[Reilly Grant]

I recommend reading further on WebOTP, because it enables the same zero-trust method: https://developer.mozilla.org/en-US/docs/Web/API/WebOTP_API#sms_message_format

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

On Thu, Aug 28, 2025 at 8:10 PM Kebba Jallow <kjal...@gmail.com> wrote:

That's an interesting point. While both calls and SMS messages can be redirected in a SIM swap attack, the security benefit of using flash calls for authentication isn't about preventing the redirection itself. The advantage lies in the fact that it's a zero-trust method.

Think about it this way: a flash call authentication doesn't rely on the user to receive and enter a code. Instead, it works by the system programmatically verifying the call from a pre-determined number, without the user ever picking up the phone. This removes the "human-in-the-loop" step, which is where many phishing and social engineering attacks succeed. It makes it much harder for an attacker who has hijacked a SIM to also trick the user into revealing a one-time password (OTP) or to bypass the security measure in real-time.

Regarding the billing, you're right to question it. The service we've partnered with operates on a clear, pre-negotiated agreement. It's not about exploiting a loophole, but rather about leveraging an established service within the telecommunications network that provides a more secure and efficient authentication method. We have a direct partnership with the provider, and the terms of that agreement are in place. This ensures the service is reliable and sustainable, rather than being dependent on an temporary billing oversight.

[Kebba Jallow]

That's an interesting point. While both calls and SMS messages can be redirected in a SIM swap attack, the security benefit of using flash calls for authentication isn't about preventing the redirection itself. The advantage lies in the fact that it's a zero-trust method.

Think about it this way: a flash call authentication doesn't rely on the user to receive and enter a code. Instead, it works by the system programmatically verifying the call from a pre-determined number, without the user ever picking up the phone. This removes the "human-in-the-loop" step, which is where many phishing and social engineering attacks succeed. It makes it much harder for an attacker who has hijacked a SIM to also trick the user into revealing a one-time password (OTP) or to bypass the security measure in real-time.

Regarding the billing, you're right to question it. The service we've partnered with operates on a clear, pre-negotiated agreement. It's not about exploiting a loophole, but rather about leveraging an established service within the telecommunications network that provides a more secure and efficient authentication method. We have a direct partnership with the provider, and the terms of that agreement are in place. This ensures the service is reliable and sustainable, rather than being dependent on an temporary billing oversight.

On Thu, 28 Aug 2025, 4:15 pm Godday Ajie, <godda...@gmail.com> wrote: