Intent to Experiment: SMS Receiver API

[Sam Goto]

Contact emails

go...@chromium.org, s...@chromium.org, jsb...@chromium.org, rei...@chromium.org, jun...@chromium.org, ay...@chromium.org, sligh...@chromium.org  

Spec

Explainer
WICG thread

SMS Receiver Design Doc  

Summary

The SMS Receiver API gives developers the ability to programmatically read SMS messages that are delivered to the user’s phone that are addressed to their origin (via a special formatting convention), eliminating a manual step for one-time passwords (OTPs).

Link to “Intent to Implement” blink-dev discussion

Goals for experimentation

Developer feedback:

• Impact on completion rates

• UX design feedback between InfoBars and alternative formulations

• API design feedback between a declarative and an imperative formulation

• Unanticipated use cases

User Feedback:

• User trust for allowing SMS access

• User interactions with button options

• Flow completion rates

UMA usage count [Googlers only]: https://goto.google.com/sms-receiver-uma-usage 

Experimental timeline

M78 - M80

Any risks when the experiment finishes?

We may have to iterate on the UI and API shape depending on developer / user feedback after experimentation before shipping. 

Ongoing technical constraints

None

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Origin Trials will be for Android only (excludes WebView). 

Support for Android WebView has been excluded from this initial iteration because it is currently challenging to route SMS messages to the appropriate app (it currently uses app hashes, which is unknown for WebViews. We believe a long term solution involves some sort of collaboration with the android team). 

Support for desktop will not be implemented for this iteration, however we plan to explore adding support through cross-device integration as a next step (see early design exploration here). 

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5873577578463232

[Jochen Eisinger]

I'm not sure that this experiment will help to answer UX questions, e.g., to determine which UX sufficiently protects against UX would assume that we'd get a certain level of abuse during an origin trial.

--
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/CALdEk-xddJVdJMOv_zFMR_44W--j6Y_scS%2BGmKmMxn_s%3DH4DLw%40mail.gmail.com.

[sligh...@gmail.com]

Sure, if we don't get enough traffic through the API or use by developers, it's hard to draw conclusions from any experiment.

Sam can clarify, but I know we're already in touch with multiple partners who have prototypes and would test the flow during the OT.

We can commit to collecting and externalizing their feedback along with usage data from the experiment. Will that help address your concerns?

Regards

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

[Jochen Eisinger]

not really, I don't think any of our partners will try to abuse this API. I'd recommend to work with the security & privacy team as usual to assess the bar for the UX.

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/e1df5ad9-0bfc-4339-b6ac-d757bb102b67%40chromium.org.

[Thomas Nattestad]

Note that it isn't just our partners who will use this API during OT since it's available to everyone. We can do a pass on the origins and see if there is any malicious usage during OT. Would that help assuage concerns? +Steven Soneff FYI 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjhuieg%3DcGuXPsGUHmNwMvbdKpwr-QcAnkObBCkyTESNnS9ng%40mail.gmail.com.

[Sam Goto]

+ balaz, martin 

On Mon, Sep 9, 2019 at 1:56 AM Jochen Eisinger <joc...@chromium.org> wrote:

I'm not sure that this experiment will help to answer UX questions, e.g., to determine which UX sufficiently protects against UX would assume that we'd get a certain level of abuse during an origin trial.

The goal of the experimentation isn't to help us answer which UX sufficiently protects against abuse: we have already established that the ones we are investigating/experimenting with do protect us against abuse, with the recommendation / guidance of the security and privacy team (per privacy review, martin/balazs CC-ed). 

What we are hoping to learn isn't whether it sufficiently protects the user's privacy, but rather / which formulation would decrease friction and increase conversion rates (for example: we started with a blocking UX dialog - which protects user's privacy -, but learned quickly that it is too disruptive for multi-input forms - so, not as effective at fulfilling the UX flow, but orthogonal to abuse/privacy).

does that make sense?

[Balazs Engedy]

Yes, for clarity, the experimentation is carried out with the purpose of identifying which UX is best for usability, while staying within the confines of hard requirements identified by cross-functional reviews. 

[Chris Palmer]

Indeed, the team has been working with us as usual. :) This feature has our (Security Team's and Privacy Team's) approval in the launch tracker.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e1df5ad9-0bfc-4339-b6ac-d757bb102b67%40chromium.org.

[Chris Harrelson]

LGTM to experiment.

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/39b1081d-08d7-427a-95e2-00b6bae31c46%40chromium.org.

[nitin.c...@indiamart.com]

This feature is awesome and we are waiting for it to launch fully across all browsers.

We have used this feature and observe a huge jump in the verification across various touchpoints.

Hoping to see it coming in a few days.

[Sam Goto]

On Thu, Mar 12, 2020 at 2:20 PM <nitin.c...@indiamart.com> wrote:

This feature is awesome and we are waiting for it to launch fully across all browsers.

We have used this feature and observe a huge jump in the verification across various touchpoints.

Hoping to see it coming in a few days.

That's great to hear. I'm glad it was useful / supportive for your business. 

 

I'll keep you posted,

Thanks, Sam

--

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/62869f07-1d10-4388-9188-d5eaaa77b5d9%40chromium.org.

[Sam Goto]

We are aiming at M83.

On Tue, Mar 17, 2020 at 10:06 AM Nitin Chaudhary <nitin.c...@indiamart.com> wrote:

Hi Sam

We are excited to hear from you that when should we get this feature?

--

Best Regards

 Nitin Chaudhary

Call: 7240466496

[Nitin Chaudhary]

Sorry Sam I didn’t get this M83.

[Nitin Chaudhary]

Hi Sam

We are excited to hear from you that when should we get this feature?

On Tue, 17 Mar 2020 at 10:22 PM, Sam Goto <go...@chromium.org> wrote:

[PhistucK]

https://chromiumdash.appspot.com/schedule can give you estimated dates for Chrome 83 ("M83").

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM7zNfQvR8dToge27xY8h-riAeP9Ee05akAPhrRV%2BYA%3DWBEq%3DA%40mail.gmail.com.