Intent to Implement: Phone number API

[Vasilii Sukhanov]

Contact emails vas...@chromium.org

  Spec Public explainer: https://docs.google.com/document/d/1Zn_aiPwYZqFz_2qfBL3XYvvE_I8S7W2XjjrHHxo_frw/edit

Summary Allows a site to retrieve the phone number of the user. It can be used on sign-up or later.

As a separate step a site can send an OTP via SMS and retrieve it via the API. That step can be used as a second factor authentication or to verify the phone number.

Motivation Current sign-up process looks like this:

• Type the phone number manually (in case of autofill it's still two taps/clicks).
• Submit the form.
• Wait for an SMS and open it.
• Copy the OTP inside.
• Switch back to the browser tab and paste the code.
• Submit the form.

Instead it can be:

• Pop up the blocking dialog. The first row is a phone number on the current SIM card.
• User taps on the correct number.
• Server sends an SMS.
• The browser reads it and returns to the site immediately.

The user made only one click. The similar functionality already available to Android native apps. Web should not lag behind.

Interoperability risk Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals Compatibility risk N/A Ongoing technical constraints None Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no. The best experience will be on Android. We can implement the dialog part on all the platforms. There are different data sources available to Chrome to get a good coverage. The SMS part is hardware dependent. However, we could use Chrome Sync to deliver the SMS content even if the user doesn't have the phone close at hand.

The doc elaborates the strategy on different platforms. OWP launch tracking bug http://crbug.com/670299 Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/6642364835692544 Requesting approval to ship? No

[Elliott Sprehn]

That spec document seems to have permissions so I can't open it, can you put it on GitHub instead so people can file bugs?

[Brian Smith]

On Thu, Dec 1, 2016 at 7:51 AM, Vasilii Sukhanov <vas...@chromium.org> wrote:

Contact emails vas...@chromium.org

  Spec Public explainer: https://docs.google.com/document/d/1Zn_aiPwYZqFz_2qfBL3XYvvE_I8S7W2XjjrHHxo_frw/edit

Summary Allows a site to retrieve the phone number of the user. It can be used on sign-up or later.

As a separate step a site can send an OTP via SMS and retrieve it via the API. That step can be used as a second factor authentication or to verify the phone number.

As an end-user, I'd prefer browsers to **not** implement this API as it is overall user-hostile. It is very rare that I want to give my phone number to a website and it isn't a significant inconvenience to type it in when I need to do so. Implementing this API will encourage more websites to demand my phone number. Further the API would make it difficult or nearly impossible to lie to websites that demand my phone number, if they insist on using this API instead.

> The user made only one click. The similar functionality already available to Android native apps. Web should not lag behind.

Please all remove the Android API.

Cheers,

Brian
--

https://briansmith.org/

[Brett Wilson]

This does seem weird to me as a separate feature.

It seems this should be a feature of autofill. We should make sure the current phone's number is always suggested in the phone number autofill suggestion popup which will solve a lot more use cases if we don't already do it. Form fields work across browsers and platforms which is a much better interior story than a Chrome-on-Android one-off special API.

With a properly annotated form, the UI should be (1) tap on form field, (2) tap on number. I think this should be pretty close to your proposed API.

Brett

[Vasilii Sukhanov]

I copied the private document with more details here. It contains the implementation details. I already have a public post on wicg.io here.

I'll create a GitHub entry once we have something more formal than an explainer.

[Vasilii Sukhanov]

On Fri, Dec 2, 2016 at 1:33 AM, Brian Smith <br...@briansmith.org> wrote:

On Thu, Dec 1, 2016 at 7:51 AM, Vasilii Sukhanov <vas...@chromium.org> wrote:

Contact emails vas...@chromium.org

  Spec Public explainer: https://docs.google.com/document/d/1Zn_aiPwYZqFz_2qfBL3XYvvE_I8S7W2XjjrHHxo_frw/edit

Summary Allows a site to retrieve the phone number of the user. It can be used on sign-up or later.

As a separate step a site can send an OTP via SMS and retrieve it via the API. That step can be used as a second factor authentication or to verify the phone number.

As an end-user, I'd prefer browsers to **not** implement this API as it is overall user-hostile. It is very rare that I want to give my phone number to a website and it isn't a significant inconvenience to type it in when I need to do so. Implementing this API will encourage more websites to demand my phone number. Further the API would make it difficult or nearly impossible to lie to websites that demand my phone number, if they insist on using this API instead.

• The sites would prefer to use email and not the phone number because email addresses rotate less often.
• There are legitimate use cases for using phone numbers as a primary ID (e.g. messengers).
• People in developing countries only use smartphones. Many of them have no idea about emails.
• It doesn't make it difficult to not provide your phone number. You just dismiss the dialog and fall back to the current flow. Or you pick up a fake one from the autofill database.

 

Re: autofill

There is a caveat here (covered in the doc). If we make a step forward then we'll support the email address together with identity tokens (basically we verify that the user really owns the email, no need to send a link for activation). The tokens are just BLOB. They don't fit into the autofill model. In addition to that the site may have to tell us "I support sign up with Google and Facebook".

[vas...@chromium.org]

I addressed the feedback from this thread and rewrote the public explainer:

https://docs.google.com/document/d/1Zn_aiPwYZqFz_2qfBL3XYvvE_I8S7W2XjjrHHxo_frw/edit?usp=sharing

[PhistucK]

I wrote this in a separate thread where someone shared your document (I missed this one) -

Note that SMS verification is deemed as insecure by the National Institute of Standards and Technology.

http://thehackernews.com/2016/07/two-factor-authentication.html

I am not sure this should be encouraged by offering an API for it.

Also, note that you have (or had? I cannot access Google Docs right now) a chromium.com e-mail address mentioned in it, instead of chromium.org.

☆PhistucK

On Wed, Mar 15, 2017 at 7:31 PM, <vas...@chromium.org> wrote:

I addressed the feedback from this thread and rewrote the public explainer:

https://docs.google.com/document/d/1Zn_aiPwYZqFz_2qfBL3XYvvE_I8S7W2XjjrHHxo_frw/edit?usp=sharing

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Fernando Jiménez Moreno]

FWIW Mozilla implemented a similar API [1][2][3] for Firefox OS. Unfortunately, we never enabled it for other platforms and it was removed from Gecko when Firefox OS was canceled [4].

Cheers,

/ Fernando

[1] https://wiki.mozilla.org/WebAPI/MobileIdentity
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=988469#c5
[3] https://github.com/mozilla-services/msisdn-gateway/blob/master/API.md
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1252573

[Philip Jägenstedt]

I normally don't look very closely at Intents to Implement, but jochen@ asked for a predictability perspective on this, so here goes.

The explainer is now for an API to read a token from an SMS given that a sites already knows the phone number, which is a bit different to what was in FirefoxOS it seems.

From a predictability perspective, I have two questions:

What is the risk that this would end up as a Chromium-on-Android-only API? Does this correspond to a similar API that exists on iOS and other platforms, and is there interest in pursuing an API of this shape from other vendors? I realize it's early to judge this, but that's what I'd wonder in an Intent to Ship later.

Second, how would this be tested using web-platform-tests? Does the feature involve (optional) user prompts that would have to be automated?

[Vasilii Sukhanov]

It shouldn't be limited to Chromium. Other browsers on Android can implement the same. The feature is mostly targeting developing markets. I don't know yet how much Apple targets them.

There should be a user prompt asking for permission to verify the number. It should be automated.

Vasilii Sukhanov

Software Engineer

vas...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

[PhistucK]

So this is an Android-only feature? That is generally not a valid outcome.

☆PhistucK

--

[Vasilii Sukhanov]

The doc explains how it can be done on desktop too.

[PhistucK]

As in, Android-only and not iOS.

The question is whether iOS can support this.

☆PhistucK

[Vasilii Sukhanov]

The question is if iOS wants to support it. And if they want, they can.

[Elliott Sprehn]

On Apr 5, 2017 2:30 AM, "Vasilii Sukhanov" <vas...@chromium.org> wrote:

The question is if iOS wants to support it. And if they want, they can.

I don't think this is true. iOS doesn't let apps retrieve sms messages like Android. There's no concept of getting a value back through the API.

I think we should make sure this API is something that could be implemented in their privacy and security model and that they'd actually consider doing it.

The iOS ecosystem today makes you enter your phone number and manually enter your confirmation code near as I can tell. That's all possible on the web today, indeed it's how Lyft's PWA works.

[Rick Byers]

On Wed, Apr 5, 2017 at 6:24 AM, Elliott Sprehn <esp...@chromium.org> wrote:

On Apr 5, 2017 2:30 AM, "Vasilii Sukhanov" <vas...@chromium.org> wrote:

The question is if iOS wants to support it. And if they want, they can.

I don't think this is true. iOS doesn't let apps retrieve sms messages like Android. There's no concept of getting a value back through the API.

This is definitely an important point when it comes time to evaluate the interop risk at "intent to ship".  From what I've seen, I don't think Apple is very likely to expose new APIs / capabilities on iOS just for the sake of the web / Safari.  Some capability currently not being exposed to native iOS apps makes the interop risk pretty high.  If having the capability would violate the privacy principles of the underlying platform than that makes the interop risk extremely high.  At the very least we should reach out to someone on the Safari team to ask if they could imagine shipping such an API some day if developer demand became high enough. I suspect the answer would lead us to say "Safari: opposed" (instead of simply "no signals").

Now that doesn't mean we shouldn't ship the feature, we just need to weigh that risk against the benefit.  How much better is this for the web than the user having to type in their auth code manually?  Can we gather any data (eg. from Android) on how much more likely users are to complete such verification when it doesn't involve manually typing in the code?  From what we've seen in the payments space, I suspect that the dramatically reduced friction here does really matter, but a compelling argument would include some sort of data to back that up.

If our goal is improved user security via 2FA, there's an argument to be made that using SMS actually does more harm as a second-factor (in terms of false confidence) than good.  What does Chrome security think about this?  Or perhaps the motivation is more about super-simple user identity (eg. WhatsApp-style) than improving security?

It's also possible to reduce the interop risk somewhat by showing how a native platform which was unwilling to grant access to SMS messages generally could implement this API in a secure manor.  There's some debate in the explainer around this (eg. whether the token will contain a cryptographic hash).  We can continue to debate the details there so hopefully by the time of "intent to ship" we can see clearly how a platform like iOS could potentially have an API to enable this use case without compromising any privacy principles.  That could help convince the API owners of the potential for "plausible interoperability" here.

I think we should make sure this API is something that could be implemented in their privacy and security model and that they'd actually consider doing it.

IMHO I don't think we should block on the "the'd actually consider doing it" part - we don't want to allow Apple to be a gate-keeper of new web APIs in Chrome.  But certainly we should reach out and do our best to maximize the chance for "plausible interoperability".

[Vasilii Sukhanov]

• There is a privacy respectful way to implement an OS API allowing an app to read an SMS only if it was clearly sent to that app.
• We expect more user value for the phone verification scenario. I hope we will get some reinforcing stats soon.
• Regarding 2FA. Rick, you link leads to https://crbug.com/621631.. The article you posted in the doc says "Adding a layer of SMS-based verification to your login process is certainly better than relying on a password alone", but there are much better ways.

[zk...@google.com]

Hey Rick (and others)-

Thanks a lot for this discussion. I think there are a lot of good points here. A few thoughts:

* iOS does have support for this, at least at an OS level. For example, as part of the setup flow on an iPhone, apple sends an SMS OTP to the phone number associated with your account. This is automatically pulled out of the SMS and applied by the OS during the FRE. So while it's true that they don't expose this as a standard API, the functionality itself is actually built in. It's not a stretch to imagine Safari getting this same functionality in the future, even if it never becomes a standard API available in iOS.

* I think we also have to look at this from the perspective of markets that would benefit the most from such an API, which I think is largely EM. In India, for example, all online credit card transactions require the use of an OTP. We can argue about whether or not OTP actually provides additional security, but that doesn't necessarily change the reality of the situation. This is also the case for "phone number as identity." I realize that many folks don't like it, but the reality is that it is one of the most common identifiers in EM.

* I think your idea to better flesh out how other platforms could implement this in a secure manner is a good idea. We'll take this effort on and share later for comment.

* I've reached out to Safari to start the conversation.

I have more numbers on the impact of OTPs for conversion in India, but I'll need to get permission to share before doing that on this thread. We'll start the implementation process and in the mean time use Rick's advice to help frame the discussion around if/how the pros outweigh the cons for this particular feature.

Thanks,

Zach

[Rick Byers]

I talked with a few folks about this offline but realized I never updated the thread - sorry.  I agree with the argument that SMS is THE way many apps choose to authenticate in a lot of EM markets, and that makes it pretty important for chromium.  We know that mobile users often abandon transactions when typing is required, so the mitigation of manually copying the code is not really sufficient, when this is unnecessary for Android native apps.

Since chromium is effectively the only engine used for mobile browsing in markets like India, implementation interest from others engines is unfortunately not likely.  Still perhaps Mozilla or even another Chromium browser (eg. Samsung, Opera, UC) would show support for this API if asked? Given that EM is a strategic focus for the chromium project, if we have examples of developers who claim this would help make their PWA more competitive with android in EM, then I'd argue the benefit justifies the interop risk. Of course we'd still expect a good spec (with opportunity and engagement on design feedback) and whatever tests we could reasonably write in case interest develops in the future.

Rick

[Paul Kinlan]

I just returned from a trip to India where we met up with a number of the leading retailers and aggregator sites and they all indicated that they would like some clean way to verify the device number phone number (for sign up) and user presence (for transactions) and they do believe that they will see an increase in conversions because of that. Every developer noted that they lose a lot of people on the web at these points, but they don't on the native experiences.

Right now they are all using SMS to verify the user in a 2-factor auth manor, knowing it's not the most secure, but for transactions OTP is mandatory and for sign-up the ecosystem does not use email as an ID the way people do in the US and EU.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_OObMwYL3dSkpZVZ5kk58f8-QbLZ8_embrM5OXCKstsw%40mail.gmail.com.

[Rick Byers]

That's great data, thanks Paul!  Do you have contact info such that we could get some of them to test it out if we get it implemented behind a flag?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.