5 ms·

So you'd assume this but older members of my family regular seem to not understand this. Either they just assume that their phone number is their "account" or i

So you'd assume this but older members of my family regular seem to not understand this. Either they just assume that their phone number is their "account" or in some cases make no distinction between the app and their account. They installed the app so where did their data go? This is especially pronounced now that application sync between devices is more or less universal on iOS and (to a lesser extent) Android. To the layman, the intuitive perspective is that it "just works" and is exactly how they left it previously, regardless of whether they have wiped their phone or replaced it. This isn't a dig at tech illiterate people but it is just how things are for the normal person. Hell I have been almost burned by this in the past when I moved phones and a certain app(FGO)'s data didn't transfer over. TLDR The most intuitive thing is working out of the box and seamlessly transferring to a new device. The easiest way to do this is to allow it to be bound to a user's Google account, Microsoft account, and Apple ID.

numpad0 6y ago
Japanese phone carriers had carrier specific mechanisms that plain HTTP requests invoked from link in HTML with certain parameters gets captured by a proxy to include subscriber ID for authentication. Those little security-by-securing-all-handset mechanisms kind of worked while there weren’t any publicly known rooted phone, in the wild, that can establish a session on featurephone APN, but emergence of iPhone and Android extinguished it.
- MayeulC 6y ago
  Actually, that sounds kind of a good idea to me. Like, have http://my.number/ http://my.number/ return the phone number for identification (though it would need some permission, I don't want every app to have access to it). Make a HTTP POST with some data to http://my.number/validate http://my.number/validate and have it signed by the carrier, validate it against a list of public keys per carrier. Not sure why that wouldn't work today? It could even be a private/reserved IP address routed by all carriers to their auth service. Edit: obviously, it wouldn't work over Wi-Fi without some cooperation at the OS level.
- frederikb 6y ago
  This (partly) exists for some mobile carriers. I know of at least one carrier, but is only usable for their own customer self care portals/apps. There it is possible to auto-login to their app if it is accessed via their network and not via Wi-Fi. For security reasons only a limited amount of functionality is accessible. Neither customer data can be changed nor can any actions resulting in additional cost (buying packs / options) be performed without additional authentication mechanism of a higher security level (auto-login via SMS or use of a password). The MSISDN is only added to the HTTP request internally in their secure network and never exposed externally.

numpad0 6y ago

Japanese phone carriers had carrier specific mechanisms that plain HTTP requests invoked from link in HTML with certain parameters gets captured by a proxy to include subscriber ID for authentication. Those little security-by-securing-all-handset mechanisms kind of worked while there weren’t any publicly known rooted phone, in the wild, that can establish a session on featurephone APN, but emergence of iPhone and Android extinguished it.

MayeulC 6y ago
Actually, that sounds kind of a good idea to me. Like, have http://my.number/ http://my.number/ return the phone number for identification (though it would need some permission, I don't want every app to have access to it). Make a HTTP POST with some data to http://my.number/validate http://my.number/validate and have it signed by the carrier, validate it against a list of public keys per carrier. Not sure why that wouldn't work today? It could even be a private/reserved IP address routed by all carriers to their auth service. Edit: obviously, it wouldn't work over Wi-Fi without some cooperation at the OS level.
frederikb 6y ago
This (partly) exists for some mobile carriers. I know of at least one carrier, but is only usable for their own customer self care portals/apps. There it is possible to auto-login to their app if it is accessed via their network and not via Wi-Fi. For security reasons only a limited amount of functionality is accessible. Neither customer data can be changed nor can any actions resulting in additional cost (buying packs / options) be performed without additional authentication mechanism of a higher security level (auto-login via SMS or use of a password). The MSISDN is only added to the HTTP request internally in their secure network and never exposed externally.