[3834] Sharing Knowledge

As this application is intended for mass consumption, on several mobile clients, it would make sense if the information were distributed rather than centrally located. At any rate, the bare minimum should allow for any one user to tap into reviews of a certain place, or allow protected contact between a user wishing to go somewhere and someone who has recently been to this place, who would like to go to the same place, or who is currently at that location.

To differentiate users, one must first have some sort of authentication so that each user may be uniquely identified. It was first suggested that the user's mobile number be used as an identifier, but this is too easily spoofed or otherwise abused, since we all have a ready list of others' mobile numbers in our phonebooks or SIM cards. (indeed, that is the point of a contact list, isn't it?) So as an alternative, the use of the IMEI number was suggested as an identifier.

However, while this 15-digit number is unique to each handset, it is difficult to remember, and the methods for accessing it from J2ME are not standard across all handsets. This would also cause accounts to be tied to the particular handset in use, and not the user. Another option would be to use the Bluetooth device ID unique to each handset - while this 48-digit hexadecimal ID is longer, and still restrained to the particular handset, it is easier to retrieve consistently using the correct library objects (javax.bluetooth.*)

Alternatively, the hostname of the handset could be used (java.lang.System.getProperty("microedition.hostname");) but this would require that the user knows how to set the hostname on the device.

One common solution, though it provides weak security, would be to ask for a username/password combination which could be stored server-side. The user would then be required to log in each time he or she uses the app, which might be a mild inconvenience. Papers detailing currently-developed and in-use technologies for user authentication on mobile platforms are being searched for a viable alternative.
Comments