autocomplete=one-time-code underspecified

[jyasskin]

Following up from #3745 (comment), the autocomplete=one-time-code specification doesn't tell a website author enough to know how they should send an SMS that'll actually autofill on the user's platform. Do they need to user-agent-sniff to get the right format on iOS vs Android? Is @mikewest right in #3745 (comment) that browsers on Android can't auto-fill this at all?

[annevk]

cc @hober @domenic

[mikewest]

Is @mikewest right in #3745 (comment) that browsers on Android can't auto-fill this at all?

I don't think I'm saying that browsers on Android can't auto-fill this at all. I'm saying that they can't autofill it without either:

1. Platform-level support for a one-time-code keyboard type: iOS supports this via .UITextContentTypeOneTimeCode, but no other platform I've seen does.

2. Requesting broad SMS permissions to read incoming messages and thereby obviate the need for platform-level support.

On 2, Chrome (at least) is unlikely to ask for permission to read all of a user's SMS messages.

On 1, Android has taken a different tack from iOS by implementing a lower-privilege SMS Retriever API, which waits for incoming messages that meet a certain application-specific template, and passes just those messages on to the relevant application.

I think that latter approach is pretty interesting, as it creates the potential for browsers to add origin-specificity into the incoming SMS, which has the potential to mitigate phishing attacks (as the attacker could cause victim.com to send an SMS challenge, but couldn't easily make that challenge available to attacker.com). That's the proposal I naively sketched out in #3745 (comment), and that @samuelgoto et al. are exploring in more detail in https://github.com/sso-google/sms-otp-retrieval.

[samuelgoto]

I think it is interesting to decouple (a) the server-side template that enables a browser from gathering SMSes without the overly permissive read-all SMS permission through the Android imperative SMS Retriever API from (b) the notation developers use to benefit from it and (c) the user friction involved in each combination.

Here is an example of the type of server-side template that we are exploring that would preserve the privacy/security/abuse properties of native apps:

Here is your OTP: ABCDE
https://example.com

That is, I believe it is still possible to offer a declarative auto-fill API (viz Safari's) while still accomplishing (a).

<input autocomplete='one-time-code'>

Notably, another dimension that I think is worth factoring out, is (c) the UX mediation hops needed, which is where I think an imperative API can come in as a complementary API in (b).

let {content} = await navigator.sms.receive();

Specifically, in terms of (b), a declarative autofill API requires browser mediation (through, obviously, the autofill consent UI to share one-time-code) whereas an imperative API wouldn't necessarily (if SMSes are formatted appropriately as (a)).

For example, the Android SMS Retriever API has addressed a variety of privacy, security and abuse vectors which enabled them to allow native apps to access SMS OTPs without any user consent/mediation (e.g. when you sign up on native apps SMSes get verified automatically with no user interaction), and that's the kinda of user-benefit that we are hoping we can bring to Web users (in addition to, rather than in spite of, a declarative autofill API).

Does that make sense?

[annevk]

What's not really clear to me is to what extent Android's approach to this problem is favorable to iOS. It seems if anything we want folks to migrate away from SMS long term, right?

[mnoorenberghe]

the autocomplete=one-time-code specification doesn't tell a website author enough to know how they should send an SMS that'll actually autofill on the user's platform

FWIW, SMS isn't the only delivery mechanism for one-time passwords so I don't think defining how to use SMS to autofill the value should be a requirement for this specification. For example, some password managers have built-in TOTP clients that could fill their value into the field. Having the hint that a field is for a one-time-code makes this much easier for agents helping the user compared to autocomplete=off (especially on <input type=password> where that off values is often ignored nowadays).

[marcoscaceres]

Given that it does appear to be implementable on Android without having to access all the SMSs, and given the user convince and popularity of this method, might be "worth prototyping"?

[lol768]

Does anybody know how this is actually implemented in Safari, today? What SMS message formats trigger the autofill suggestion?

Educated guess: Is it just equivalent to the existing UITextField oneTimeCode textContentType? In which case:

The operating system will detect verification codes from Messages automatically (messages that contain the word "code" or "passcode") with this UITextContentType set.

Presumably this varies per locale..

The spec, and documentation on this are next to non-existent.

---

Edit: this appears to function even if you don't use the one-time-code attribute value 🤷‍♂️

[jyasskin]

https://github.com/WebKit/explainers/tree/master/sms-one-time-code-format is related.

[othermaciej]

Safari heuristically guesses what might be a one-time code field when the right autocomplete value isn't present, just as for all other autofill fields.

Safari guesses that a wide range of SMS formats signal a one-time code, and has a user action before filling (via UI in the OS keyboard on iOS, via browser UI on macOS). There seems to be a lot of agreement on the format in https://wicg.github.io/sms-one-time-codes/ , so that's probably what should be recommended for authors, while perhaps still allowing browsers to parse legacy formats if they should choose to.

[alystair]

My day job utilizes OTP as first-factor authentication, whether or not that's a good idea isn't up for discussion :)

For the sake of others in the same position I'd recommend having wording in the specification that implementations of input fields with the autocomplete=one-time-code property (especially in tandem with type=password) ensure that baked-in password managers don't ask the user if they wish to save the password - a foolish endeavor.

As all major browsers ignore autocomplete=off on password inputs at the moment of writing - our workaround has been use of the type=text input with a custom security-circle font, as text-security CSS isn't adopted outside of webkit.