Long-term plan for app hashes

[rowan-m]

Looking through the howto and the associated link for obtaining hashes on Android, is there a way to acquire the hash within the page? Currently it seems as if the developer would need to check the browser user agent to obtain a version number and map that to a specific channel which will also update on a regular basis.

Would there be any risk / issue to exposing something like navigator.sms.appHash?

Or given "Long term, we expect the formatting to be browser agnostic…" is the purely something that is an expected implementation detail for early adopters / experimenters?

/cc @agektmr

[samuelgoto]

Our current operating conjecture is that the long term solution to this problem isn't to expose the concept of the app hash on the web platform, but work with the android team to come up with different routing mechanisms for the SMS Retriever API.

One of the early ideas that we are discussing is making android aware of the server side formatting convention and routing HTTPS-addressed SMS to the default browser the user has chosen in their settings.

[tomayac]

FYI, the WebKit folks have now posted their proposal.

[mikewest]

As discussed in https://chromium-review.googlesource.com/c/chromium/src/+/2018331/15#message-2bd69f0c3fcef7e0382885593938c5db990d5122:

It seems to me that we'll be in a world where some version of Android support the formatting convention of the existing SMS Retriever API, and some other versions of Android support the new hotness we agree upon in https://github.com/samuelgoto/sms-receiver#formatting. What's your strategy for shipping the API in that world?

I still think it might be simplest to expose a suggested format to the developer, as suggested in whatwg/html#3745 (comment), which would let developers understand how to format messages on all platforms. An alternative would be to only expose the API on platforms that support the new format, which feels a little strange, but might be reasonable?

WDYT?

[samuelgoto]

It seems to me that we'll be in a world where some version of Android support the formatting convention of the existing SMS Retriever API, and some other versions of Android support the new hotness we agree upon in https://github.com/samuelgoto/sms-receiver#formatting. What's your strategy for shipping the API in that world?

I can't speak with absolute confident on GMS's core release schedule, but my current understand is that it gets propagated and distributed to all users reasonably quickly (~6 months, which is somewhat fast compared to standardization). That is, once/if we get to converge there, distributing to users such that all of them don't need an apphash anymore is within a reasonable time frame (from the point of deployment).

Makes sense?

[rmondello]

I can't speak with absolute confident on GMS's core release schedule, but my current understand is that it gets propagated and distributed to all users reasonably quickly (~6 months, which is somewhat fast compared to standardization). That is, once/if we get to converge there, distributing to users such that all of them don't need an apphash anymore is within a reasonable time frame (from the point of deployment).

But let’s get into the details of how a web developer knows whether to signal to the server backend that’s sending the OTP message that it needs to include an App Hash.

It seems like Mike thinks that putting a notion of templating into the API proposal is right. This is interesting, but I think it’s worth exploring a framing that makes it such that it’s only extra, non-standard client-specific data that can be included in the message format.

I think it’ll be important to tell everyone, Here’s what you do on all platforms and clients, always, regardless, and, Here’s where you look to see in the context of script running on the web if you should append anything client-specific to the message format. This is in contrast to asking the client for an entire message template.

[mikewest]

I think it’ll be important to tell everyone, Here’s what you do on all platforms and clients, always, regardless, and, Here’s where you look to see in the context of script running on the web if you should append anything client-specific to the message format. This is in contrast to asking the client for an entire message template.

This is a fine framing; I don't have strong opinions about the pros and cons of a complete template on the one hand, and a partial template on the other. I'd be fine with a proposal along the lines of what you're suggesting, Ricky.

That said, I am starting to be concerned about dropping the app hash entirely from the OTP format. AFAIK, the current plan for Android is for the underlying platform to route the origin-bound message to a user's default browser, as it has no mechanism for distinguishing application-bound requests in the current format. Is that the plan on iOS as well? I think that's a reasonable first step, but it seems like a bad place for us to collectively land, as it would make it difficult to give users the same experience in a browser they haven't yet decided to solidly switch onto.

[rmondello]

This is a fine framing; I don't have strong opinions about the pros and cons of a complete template on the one hand, and a partial template on the other. I'd be fine with a proposal along the lines of what you're suggesting, Ricky.

Cool! If the @# part of the message is known to be a universally good idea that every sender should do, and should be part of every server-side template, everyone benefits. And then, after that universal bit, if auxiliary data is needed, so be it.

That said, I am starting to be concerned about dropping the app hash entirely from the OTP format. AFAIK, the current plan for Android is for the underlying platform to route the origin-bound message to a user's default browser, as it has no mechanism for distinguishing application-bound requests in the current format. Is that the plan on iOS as well? I think that's a reasonable first step, but it seems like a bad place for us to collectively land, as it would make it difficult to give users the same experience in a browser they haven't yet decided to solidly switch onto.

Realistically, I’m not suggesting the app hash be dropped. I’m saying that its framing should be “auxiliary information to add after the @# if and only if the browser that triggered the auth challenge is a version of a browser running on a version of Android that won’t automatically route one-time codes”. There should be clarity on Day 1 for exactly when such a hash is required, and a clear path toward phasing it out over time, as the older versions of Android become less relevant.

I would be remiss if I didn’t say that I would prefer we build for the future, rather than complicating the deployment story to accommodate older version of Android. I would be very happy to see a focus on deployment to Android versions that know how to route one-time codes to trusted web browsers, never introducing the app hash wrinkle to what otherwise could be a cross-platform message format.

On iOS, code filling is managed by the operating system itself and filled by the system keyboard, releasing the code to the app only after user consent. We have none of these problems.

[samuelgoto]

Cool! If the @# part of the message is known to be a universally good idea that every sender should do, and should be part of every server-side template, everyone benefits. And then, after that universal bit, if auxiliary data is needed, so be it.

I think that's aligned with what I have in mind too.

To be clear, what I'm imagining is that developers use the following for chrome on android until android drops the need for ${APP_HASH}:

Hi, your OTP for example.com is 123.  ${APP_HASH}
@example.com #123

That is, GMS core (which is the library that needs to be changed and rolled out to all users), takes time to deploy (say, 6 months), but once deployed, reach a large number (all, I think?) of users within a certain timeframe.

So, I'm thinking, the message we send to developers, is something along the lines of:

1. if and only if User Agent == chrome on android, use the "auxiliary information in the form of chrome's app hash in the SMS":

Hi, your OTP for example.com is 123.  ${APP_HASH}
@example.com #123

2. chrome works with the android team to remove the need to have an ${APP_HASH}
3. Android team releases a new GMS core library
4. Library gets propagated to all users
5. chrome tells developers to move to the following format:

Hi, your OTP for example.com is 123.
@example.com #123

So that, long term, we all converge into the common convention.

Does that make more or less sense?

[samuelgoto]

To report back here and close the loop, I think we found a better answer. We are planning to use this API:

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

Which doesn't require app hashes at all (i.e. interoperable between browsers) at the cost of user intermediation at the OS level rather than the browser level. See mock [1].

From our experiments so far, while the UX isn't as efficient as the one we built, it gives a significantly better developer story here. We are finding that the UX is sufficiently good, has the right privacy properties and, importantly, doesn't corner us from making it better longer term.

We are still working with the Android team to polish either the API or the UI, so longer term we expect this to converge to something really solid.

Resolving this, since I think we found a formulation that works well for @rmondello and all. Feel free to reopen if you disagree.

[1] OS level user mediation