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

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

Ok, just trying to report back on this too. Answers below.

> 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)? 

The intent here is certainly not to offer this as a general replacement for log in.

SMS OTPs can be used to help verify phone numbers, which is the extent that this API is designed to help.

For the most part, WebAuthn can offer much tighter security / privacy properties.

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

Yeah, agreed that any global identifier makes collusion between parties possible. Emails have the same challenge. Obfuscated user ids too.

There is a larger discussion about global identifiers happening at [this](https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html) level, but nothing concretely affecting this specific proposal whose intention is to reduce friction (rather than decrease usage of global identifiers).

I think I empathize with your point about making more global identifiers (namely, phone numbers) more available, but I don't share the sentiment that moving the needle in either direction on that goal directly depends on the outcome for this API proposal (i.e. in practice, web apps **can** and will continue verifying phone numbers through SMS regardless of this API, e.g. safari has launched phone number verification some time ago without any major un-anticipated consequences as far as we can tell from where we are standing). 

So, yeah, acknowledged about the risk here of promoting more global identifiers (which are bad), but, yeah, I think that the trade-offs are well balanced in terms of user benefits / risks.

Does that answer your question?

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