Re: [w3ctag/design-reviews] SMS Receiver API (#391)

Thanks for the feedback @dbaron ! Replies inline!

> It seems like one piece of the security model here is that it's OK if the SMS ends up going to the wrong > tab at the correct origin. Is that correct?

That's a correct interpretation of the proposal. It is currently implemented in "registration order", so SMSes are delivered in the order in which they were requested ("one SMS message per request").

> That seems like it's fine for usage that's login-related, but 
> might be (maybe?) more problematic for cases where the SMS is being used as a second factor to 
> authorize a specific action. 

Wouldn't app developers be using action-specific OTPs to avoid the confusion? That is, isn't it the case that, in the current status of the world, app developers already have to deal with the multi-tab / multi-task scenario and the race conditions that can occur here, regardless of whether the SMS is received programatically or manually?

> Are there cases where SMS is or might be used that way?

Not that I'm aware of.

Interestingly, in the current proposed formulation, the entirety of the SMS is handed back to the developer (which generated it in the first place), so a lot of extra information can be embedded there. For example, one could use:

```
Your OTP for buying your item is 123!
For: https://example.com/buy_stuff.php?OTP=123
```

And use the following for logging in:

```
Thanks for logging in! Your OTP for logging in is 456!
For: https://example.com/signin.php?OTP=456
```

The message is entirely opaque for browsers, which only checks whether the `For: ` footer in the SMS matches the origin that has requested it (to protect the same origin boundary).

> I didn't see anything in the examples about how the site would figure out what hash it needs to put in 
> the text message so that it gets routed to the browser. Presumably this would need to be a somewhat 
> flexible API so that it would support mechanisms across different operating systems and browsers?

From a [server-side formatting convention](https://github.com/samuelgoto/sms-receiver/blob/master/README.md#formatting), we think that it suffices to specify a `For` attribute (with a URL as a value) that browser use to route the message (e.g. rather origins match).

Long term, we don't believe Android is going to need the app hash to route messages to browsers, so there isn't any proposal to expose the hash (or templates) from a Web API perspective.

> the explainer references GMS core which I guess is a reference to Google Mobile Services but doesn't > explain how that's relevant

Correct, GMS core is referring to Google Mobile Services and it is relevant because it is the low level operating API that browsers would use (on Android) to access SMS and that dictates much of the server-side [formatting conventions](https://github.com/samuelgoto/sms-receiver/blob/master/README.md#formatting) aspects of this API:

https://developers.google.com/identity/sms-retriever/overview

Does that clarify?

> I'd also note that there's been somewhat extensive discussion of this in mozilla/standards-positions#152.

I am in that thread and am trying to respond as much as I can. Is there a specific comment / concern that hasn't been addressed that you'd like to bring up to our attention (more generally, but also more specifically anything that relates to this TAG review)?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/391#issuecomment-511591615