Enhancing the security prompting for Java apps
We have been working on enhancing the security prompts in S60 Java for some time (actually quite a long time for that matter). Nearly always the Java application security prompts are an annoyance in user’s perspective. When using applications that go beyond the very basic things and would use more of the Java Runtime provided APIs users need to consecutively keep accepting all sorts of security prompts. This means that application’s user experience is ruined as the UI flow gets The reason we have these is due to very strict security standards in Java: mainly MIDP, JTWI and MSA specifications.
These standards mandate runtime security prompts for unsigned and even for signed third party applications. The issue is that the specifications do not even allow user to grant applications to have access even if they would like to. In many cases user is not allowed to grant application to access similar functionality in future but requires user to accept the same thing over and over again in the same application run. These very strict rules prevent many application use cases completely. On the other hand, on S60 platform having very strict security rules for Java does not really make sense as native applications and other runtime applications do not have to follow the same rules. That means that due to strict security Java applications have been less capable in past.
We decided to implement two things to make the situation better for Java developers on S60:
- A new kind of runtime security prompt which allows user to directly change the security setting for the application (pictured here)
- A set of security policy changes allowing user more control on the settings levels for untrusted and trusted 3rd party
The picture shows the new security prompt. User is able to directly choose the security setting for the function group from the prompt. In the example picture the function group is “NetAccess” as the prompt text talks about network usage. The different access groups and which API methods are tied to them are specified in MSA specification. In earlier S60 Java runtime implementations the security setting could only be changed from Application Manager / General Settings menu where MIDlet specific settings are located. The current security setting is highlighted by default in the prompt. And initial value for the settings is defined in the security policy in use. Security policy defines the setting values based on whether application is signed or not and what kind certificate has been used as a root.
Since the policy defines what setting values are available for the user we found out that just with the enhanced prompt we won’t help much. The issue is that the MSA defined policy is way too strict for many use cases. We started to look on the MSA policy and wanted users to have more control on the application capabilities too. The idea of the new policy is to allow for signed MIDlets (identified third party in spec lingo) by default to have session access. This means that for a certain API access user would only be asked once for the same MIDlets runtime. This helps signed applications using SMS/MMS messaging, file access, and application push invocations. For unsigned applications (untrusted / unidentified in spec lingo) we have added user some more freedom to choose the security level on these same access groups but the default access is the same as previously (except for Network access that we decided to go back to MIDP 2.0 / JTWI Session access from more restricted Oneshot access of MSA). On multimedia recording group we decided to allow user to go event to blanket level (no security prompts).
We believe these changes allow Java developers to do more innovative applications on S60 Java as access to many APIs is now also in practice allowed also for 3rd party applications. Earlier the very strict default values forced too many security prompts for user rendering many use cases totally unusable.
The enhanced prompts will be added to upcoming 3rd edition FP 2 (and later) devices but we are seeking to get this enhancement also as a correction to some existing products via Nokia SW update.
S60 licensees and operators can still configure the old MSA security policy for their devices. Nokia devices by default will have the above mentioned security policy.
About time, those prompts are deeply irritating. Apps written in S60 Java, it really have to be extra special to get on my handset.
test
That was the greatest news for a long time, eventually the Nokia/S60 crew used some common sense. I cant imagine how anyone designed MIDP, JTWI and MSA security so overly strict to begin with, did they ever wonder about user experience at all? I’ve been developing Java ME applications for some years now and the security prompts have rendered many API:s unusable and they have certainly not made anything more secure! Too many security prompts and nobody will read them before accepting.
Keep up the good work Aleksi, love your posts!
Giving the user more control, as long as they have clear, understandable information that is sufficient for them to make an informed decision, is surely a good thing, so congratulations on that!
One thing that worries me about your screen shot though is, where is the option for “no, and don’t ask me again”? That’s a really important option for dealing with malware, as we have seen with Cabir and Commwarrior, where initially the user will say “no, don’t accept this” but the malware tries again and again, and eventually most people will just say “Yes” in the hope that the prompts will go away.
This sounds good, but I’m a little bit skeptic about this. Currently in Application Manager / General Settings for the midlets user is limited on permission options for unsigned midlets. For example trust settings for Fle connection Read and Write can only be set to “Always ask”, so it seems to me that these changes will also suggest user just “Allow once” and “Do not Allow” options in case of File operations for unsigned midlets. If this is the case than developers will not be motivated to start programming on Java ME when we have to pay 300 - 500 $ for trusted certificate, and users will have to click “Allow once” for every sensitive situation, and things will be similar like now.
If “Allow always” option will exist for unsigned midlets, then this can move Java ME development from the dead point in which it is now.
sounds pretty simple. shouldnt be too hard
This looks like something very exciting! Well done nokia!
Now if only these improvements could be incorporated in the web runtime…
Will this make the prompt that appears when I call LocationProvider.getLocation() go away? As it works now, it prompts every time the program updates the GPS-coordinates of the phone…
Great news!
This will keep me up with the development we have in course.
Does anybody know whether the SW Update with said features is already available?
If not, any idea when it should be?
I visited Nokia`s site now and did not find anything…
Will this mean that untrusted MIDlets could use the JSR-75 API (particularly Read User Data) on S60 3ed FP1 with ‘Ask First Time’ or ‘Allowed’ protocol for prompts? If so, when will the software updates be available?
Perhaps the bigger issue has been forgotten? Even if Nokia backwards supports previous devices with SW updates, who in the general public will know or even care to perform a software update.
Although news like this may be good, it could be years before we can safely assume that this problem has gone though changes in the security model or midlet signing. A lot of apps we create must have some commercial viability, and if they are not user friendly, revenue cannot be generated. If the kind of security support does not exists across all devices across all manufacturers across all networks, then it will never work.
Referring back to post 9 and 11, I agree that these changes are useless unless JSR-75 is freed up. On a Nokia 6220 for instance, which is 3rd edition FP 2, every access to the file system generates prompts, which cannot be disabled. The only two options are Only Allow Once and Do not allow. This seems how it’s supposed to be if you read the blog carefully. This will not do. Buying certificates is too cost prohibitive, especially if you have to do it for every bug release again if I understand it right. The Java motto of make one run everywhere is made a joke of. I saw a video by Apple on the Iphone on developing for it. Apparently they will put your app for free in their store, and make it available to every Iphone owner for free, as long as you set your price at $0, more than that and it is 70/30 share between you and Apple of the revenue. Now that’s what I call inviting people to develop apps for your device. Benefits everybody. This restrictive Midp security model stops developers dead in their tracks once they understand how it works. The potential for really interesting apps for j2me phones exists, but compared to the Iphone and the like, what’s out there now seems amateurish in comparison, could this restrictive policy be the reason?