Signed Midlet Permissions - File I/O

[dmost]

We have a Java ME Midlet that uses JSR-75 to access files on the memory card. Our midlet accesses many files, so to be practical, the user must not be prompted more than a single time for read permission (and a 2nd time for write permission) per app start-up. This is a commercial product and we strongly believe it is unacceptable to instruct users to find the App Manager and manually bump permissions to "Always Allow".

We are attempting to determine the broadest distribution we might be able to achieve for S60 handsets. Specifically E71, N95, and N96. Are there any options that will meet our needs across multiple carriers?

Some additional details:

Paraphrased from from AT&T's site: The AT&T Policy for both Read & Write permission is DENIED (Application can never use respective function) for both Untrusted & 3rd Party Signed domains. For the AT&T Signed domain No, One-Shot, and Session options are presented.

From Nokia documentation: "It is also important to notice that the permissions are given in a file-to-file basis. This means that the user may be prompted for each file or directory that is being accessed."

Based on the above, I infer that even AT&T Preferred cert would be insufficient as the user would get the "session | ask first time only" permission for each file/dir. Is that correct? (This behavior would make our application horribly unusable.) Luckily, one might forge a business relationship with AT&T and upgrade to the AT&T Trusted cert giving blanket permission.

However, this only (potentially) solves the issue for devices with the AT&T branded firmware, and would not work for the many AT&T customers who purchased their devices from overseas.

Will using Java Verified meet our needs for other carriers, or will that give us 3rd Party Trusted status, resulting in a multitude of permission prompts? Will Java Verified work for AT&T as well?

Any insight on how we might solve this dilemma is greatly appreciated.

Most Sincerely,
Dave

[arpit2agrawal]

Purchasing a digital signature certificate (DSC) from VeriSign (US$500 for a year) or Thawte(US$300 for a year) and signing your application will make the application in 3rd party trusted domain. Java verified will also make the application in 3rd party trusted domain. There is no such thing as "Java Verified domain".

So, purchasing a DSC will solve your problem on most of the non-Motorola handsets including but not limited to all Nokia handsets.
Then you just need to purchase another DSC from Motorola for all Motorola handsets.

Once you do that, after the installation of the application, user can set the permissions "ReadUserData" and "EditUserData" to "Always Allowed"

I hope you are aware of the fact that Nokia S60 devices have very poor performance for JSR 75 API compared to other phones like Nokia Series 40

And which AT&T handsets are you talking about, I mean which manufacturer's handsets?
I suppose AT&T don't manufacture handsets...

[dmost]

Thank you for your response.

Purchasing a digital signature certificate (DSC) from VeriSign (US$500 for a year) or Thawte(US$300 for a year) and signing your application will make the application in 3rd party trusted domain. Java verified will also make the application in 3rd party trusted domain. There is no such thing as "Java Verified domain".

I've contacted Java Verified. It seems that when they sign the midlet, it will be in the same domain as Verisign/Thawte - 3rd Party Trusted.

So, purchasing a DSC will solve your problem on most of the non-Motorola handsets including but not limited to all Nokia handsets.
Then you just need to purchase another DSC from Motorola for all Motorola handsets.

I don't believe this is the case. We have tested with both Verisign & Thawte certs on N95 & N96 handsets. The user is prompted for permission for each file read/write attempt, which for our customer is unacceptable. We access MANY files, so the permissions dialog that appears needs to contain the "always allow" permission for this to be viable.

Once you do that, after the installation of the application, user can set the permissions "ReadUserData" and "EditUserData" to "Always Allowed"

We'd hate to have the midlet install, and maybe the user chooses "Run" at the end of installation... only to find they cannot use the software and must exit, find the App Manager, and manually update permissions.

I hope you are aware of the fact that Nokia S60 devices have very poor performance for JSR 75 API compared to other phones like Nokia Series 40

And which AT&T handsets are you talking about, I mean which manufacturer's handsets?
I suppose AT&T don't manufacture handsets...

For AT&T, the solution is to use "AT&T Trusted" cert; which requires a strong business relationship with AT&T. The standard "AT&T Preferred" cert prompts too much.

Thanks again,

Dave

[arpit2agrawal]

I don't believe this is the case. We have tested with both Verisign & Thawte certs on N95 & N96 handsets. The user is prompted for permission for each file read/write attempt, which for our customer is unacceptable. We access MANY files, so the permissions dialog that appears needs to contain the "always allow" permission for this to be viable.

If you make your MIDlet in 3rd party trusted domain by signing it and then if you go to Suite Settings of your MIDlet then you should be able to set the permissions "ReadUserData" and "EditUserData" to "Always Allowed". Are you able to do this?
Read this: http://wiki.forum.nokia.com/index.ph...2C_S60_3rd_FP1

We'd hate to have the midlet install, and maybe the user chooses "Run" at the end of installation... only to find they cannot use the software and must exit, find the App Manager, and manually update permissions.

Nothing can be done. You cannot set the permission to "Always Allowed" automatically using some kind of programming. User has to do it manually.

For AT&T, the solution is to use "AT&T Trusted" cert; which requires a strong business relationship with AT&T. The standard "AT&T Preferred" cert prompts too much.

I will ask the same question:

which AT&T handsets are you talking about, I mean which manufacturer's handsets?

[ggodart]

I hope you are aware of the fact that Nokia S60 devices have very poor performance for JSR 75 API compared to other phones like Nokia Series 40

What do you mean by 'poor performance' ? Low speed ?

Signing the official sun PDA PIM/jsr75 wtk demo midlet with a $500 verisign certificate allow me to prove that on the E51 even with all midlet permissions set in jad file and manually putted the read/write permission for personal data after installing the midlet, EVERY COMMIT NEED THE USER CONFIRMATION !!!

My midlet is well in 'secured 3rd party' as I can see in the application manager and 'Read user data' and 'Write user data' have manually been set to 'Always allow'.

You want to add one contact in native adress book -> user confirmation
You want to modify one contact in native adress book -> user confirmation
You want to delete one contact in native adress book -> user confirmation
Add 500 contacts -> 500 user confirmations

You want to add one envent in calendar -> user confirmation
You want to modify one envent in calendar -> user confirmation
You want to delete one envent in calendar -> user confirmation

todo list idem

Furthermore, the application manager doesn't allow to have at the same time 'network access' and 'auto run' both set on 'always allow'. When you set one to 'always allow', the other is automatically modified to 'ask first time' !

I would be interrested to have feedback for other mobile phones.

[traud]

– Known issue for S60
– Mutually exclusive permissions
– Signed Test-MIDlets

[stevejanko]

The sooner everyone understands that the person who purchased the device owns it and is responsible for what they install and run on it the better.

Signing authorities and the networks do not own the device and should have no say over what the user intends to run on it and how it should run.

All this whole signing process does is cock up perfectly good solutions, becuase when you sign an application it stops working on devices that do not support the signature you paid for or as above the networks apply their own restrictions.

When installing an application the user should have the ability to set whatever they want to always allowed, one shot, always ask or never allowed (which should be the default for all newly installed applications). Why is this so difficult for everyone to understand?

The sooner this whole sick joke of a process is scrapped the better for all developers and end users

Steve

[ggodart]

Steve I completely agree and I guess android will change all this, allowing a so easier way to develop in java on mobile phones. Developers will have choice between headaches on j2me (with api rights management, no phone api available...) or java 1.6 and freedom apis on android... Nokia should be very cautious with it's next choices...

[r2j7]

Hello ggodart,

Signing the official sun PDA PIM/jsr75 wtk demo midlet with a $500 verisign certificate allow me to prove that on the E51 even with all midlet permissions set in jad file and manually putted the read/write permission for personal data after installing the midlet, EVERY COMMIT NEED THE USER CONFIRMATION !!!

Unfortunately this is the case for S60 devices till S60 3rd Edition, Feature Pack 1. This has been enhanced starting from S60 3rd Edition, Feature Pack 2.

Regards,
r2j7

[stevejanko]

Hi ggodart

Yup I have heard about Android's security policies. Interesting ...

The part of the whole issue that really aggravates me is the shortsightedness, I agree that the end user should be protected from malicious applications but the methods currently put in place are just WRONG. How are we supposed to develop applications that are truly functional with all these limitations.

Now it is my belief that Nokia and the other mobile phone manufacturers should be catering to their customers needs (Yes I know that the networks subsidize phones but at the end of the day they are not the customer, the person who buys the device for their own use is, they pay for it at the end of the day).

It shouldn't take new competion (Android) to cause manufacturers to wake up. From forums such as this one they should see where the problems lie and "fix" them of their own accord.

I've been watching this forum for years now and nothing has ever been done to allieviate this whole problem of signing on the contrary things have only been made worse.

Who are the manufacturets catering for?

Steve

[traud]

Steve, (in many cases) you are able to hack your own phone to give any MIDlet any permission. There are guides out there on the Internet. Anyway, some are really complicated.

[stevejanko]

Hi Traud

I think hacking the phone defeats the purpose. Yes I have seen how to create your own certificates (that stopped working with S60 3rd Edition FP1) etc...

What I am interested in is the user experience. All the permission questions when running an app are painful (in some cases such as with JSR75 it makes many apps unusable).

My point is if I develop/buy an app it should work seamlessly and it is up to me as the OWNER of the phone running the app to decide if and when I wasnt to see warnings.

Regards
Steve

[arpit2agrawal]

Steve, (in many cases) you are able to hack your own phone to give any MIDlet any permission. There are guides out there on the Internet. Anyway, some are really complicated.

But when you are releasing your application in the market, you cannot expect normal user to do some complicated hacking process with his phone...

[mikemoore]

Who are the manufacturets catering for?

They cater to people who would like to use a phone, not a multi-purpose computer.

You can provide your end-user with simple instructions on how to configure their device so that the signed application only asks for permission once per run.

- Mike
NAVTEQ Network for Developers
The community for developing innovative location-based applications
http://NN4D.com

[drthomasmiller]

You can provide your end-user with simple instructions on how to configure their device so that the signed application only asks for permission once per run.

Can you? Wouldn't these be pretty complicated instructions - the Application Manager isn't exactly easy to find or a one-step process.

Thomas