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

Answering your questions inline:

> @samuelgoto we are just picking this up at our Tokyo f2f. We're unclear as to the current thinking regarding permissions? 

Ah yes, totally my fault here, I need to fill out the security/privacy questionnaire. Will report back here, but before I do let me try to answer these questions in an unstructured form.

> If you are not considering an additional permission request, can you describe what the mitigation is against potential abuse? 

I think the latest thinking from our internal privacy / security reviews is that some sort of permission prompt is required. We are still experimenting with a variety of permission models, each with their own trade-off.  You can see here the variations that we are exploring:

https://github.com/samuelgoto/sms-receiver#alternatives-considered

Our intuition at this point is that [this](https://github.com/samuelgoto/sms-receiver#unblocking-ux) may work best, but we feel like we are very much early in the process learning what works best, so we do expect a significant amount of iteration on the right permission UX.

Does that answer this question?

> The security & privacy self check seems to be missing. If you have not yet filled this out, can you please take a look at the new privacy & security self-check we just published?

Yep, will do.

> If the intended use of this is as a general replacement for log in, we are a bit concerned that this means service providers will always have the phone number (and therefore be able to correlate user's identity with their telecom provider)? 

I don't think "the intended use of this as a general replacement for log in" represents well the goals. It is noted today in our explainer as a [non-goal](https://github.com/samuelgoto/sms-receiver#introduction).

> This could be concerning from a privacy perspective. It's not that this is a new thing. It's been possible using existing technologies to ask for a user's phone number and then ask them to enter a code that is sent to them by SMS. The issue is that use of this API would make it so much easier to do this that you might risk this becoming the only means of authentication. 

> Is that issue being discussed at all and if so do you have any thoughts on mitigation?

I don't think we have put much thought into this. I think it is a very good observation, I just don't have anything off the top of my head right now other than it is deliberately marked as a non-goal, but I see your point about second order and unintended consequences, so let me circle this around and get back to you with a well thought out position.

-- 
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-531065676