I can recommend this short but thought-provoking article over at The Mobile Technology weblog.
In essence, it critiques mobile J2ME and BREW because they’re denied access to the communications-centric functions of the mobile handset.
I’ve long thought the same thing. What I’d like to see is these environments deploy “opaque objects”. This means that they would be able to query and manipulate things like your address book, but without actually seeing the data. Only the phone OS would see the data itself; the program would just hold an object handle. Functions like iteration through the address book, comparison, and set operations, would all be offerred. A number of user interface components would be offered native to the device to perform standard operations like the selection of one or more contacts, or the addition of new entries.
This would help to reduce the danger of privacy and security lapses. A progam that can’t see your actual address book data can do less harm to your privacy.
I also believe that the provisioning of access permissions of applications could be substantially improved. When I download a J2ME application, and it wants to access the network, I’m forced to go through a handset-mediated screen asking every session if I want to accept once, repeatedly (but just for the session — not forever), or not at all. This is a gross inconvenience. We don’t pop up a “do you really want to make this phone call” confirmation when you press the green button.
What I’d rather see is the permissions get set at install or purchase time. The install-time part is fairly self-explanatory — you set the access parameters to resources like profile, address book and network. The purchase-time one is more subtle, and really refers to the wired Web. The download app would come with a digitally signed set of permissions from the retail environment, where you have provisioned your access preferences. When you buy a certain networked game, you just tick a box saying “I understand that this game will be given access to my address book, and may access the network incurring packet charges.” The appropriate permissions are then tagged on, and you are never asked again on the handset.
Some of these could be parameter-driven. For example, my email application may be allowed to transfer up to 1Mb a day without asking, but above that I should be asked to give my consent. Waiting until the app is on the phone is too late to start provisioning this kind of thing.
This would possibly give network operators’ in-house mobile portals a large advantage, as third party sites may not have access to this signing facility and their user experience will suffer. Users downloading from third party sites would have to deal with more intrusive access screens on the handset.
Naturally, a balance is to be struck between privacy and convenience. You can ask too many authorisation questions and put people off. But today’s model of simply not allowing some highly valuable functions to be accessed by handset applications is decidedly not convenient, either. There are many low-level functions in the phone which could contribute to an enhanced application experience, if only the operators and handset makers weren’t so scared of exposing then.
This model also extends to Windows applications. We won’t see it, because Microsoft has gotten lost in the wilderness, but here’s what I’d like Windows to do when I install a new app. I should be presented with a human-digestible list of the key permissions it is requesting: “Access the web site ‘foo.com’”, “Modify files in the ‘My Documents’ folder”, etc. (By default, it should only have access to its own preferences directory. And I should be able to increase or decrease permissions — not just ‘take it or leave it’.)
Just because an app gets a buffer overflow or has a control logic bug shouldn’t mean it gets to trash my whole hard drive and access the whole Net. All those worms that download via browser bugs would have a hard time, because being able to execute arbitraty code wouldn’t automatically enable access to all OS functions. If you go to hax0rs.com by accident, and get a pup-up from the Windows OS asking if you want to authorise access to your address book, you should be deeply suspicious.
(As an aside, the security model of Windows is very broken, and will stay that way, because actions are done on behalf of users, and not applications. Just because I downloaded and installed an application doesn’t mean it should be trusted as if it were me. The user model doesn’t match the trust model. Unix/Linux is barely any better, but at least you can fake it by creating a different user for each app and constraining its actions accordingly. Ideally you’d have a file system where any haywire application could be terminated and the changes it had made simply undone. Windows also doesn’t make it easy to distinguish pop-ups that have come from the OS itself from those generated by the application. Another security headache.)
I hope you’ve managed to follow this rather abstract stuff, but really it’s very simple. If you’re going to give applications access to data and facilities that could harm the user, you need to put in appropriate controls, and make the provisioning of them simple. It may be just my ignorance of current developments in 3GPP standards etc., but it seems we are lacking on all three fronts.
Posted by Martin Geddes at 01:31 PMTrackBack URL for this entry:
http://www.telepocalypse.net/cgi-sys/cgiwrap/mgeddes/MT/mt-tb.cgi/521.
Listed below are links to weblogs that reference Just a game:
»
Just a game from Skype Journal
I can recommend this short but thought-provoking article over at The Mobile Technology weblog. In essence, it critiques mobile J2ME and BREW because they're denied access to the communications-centric functions of the mobile handset. I've long thought ...
[Read more]
I think looping through such things as an address book wouldn't be useful for building especially advanced applications unless one could do comparison against values, and once one can do that the whole thing is up for grabs.
Posted by: at July 20, 2005 03:11 PMAll your requests about limits of J2ME MIDP will be actually covered by next generation embedded Java based on CDC configuration and OSGi (http://www.osgi.org) component model.
Particularly, with JNI, it will be possible to encapsulate native feature in OSGi Bundle to provide services to others Java components.
Peter Kriens, OSGi Release 4 editor gave a great (but quite long) presentation at French OSGi User group recently
http://www-adele.imag.fr/osgi/meeting2/OSGi-BasicArchitecture2.pdf