pagetop
Javablog
by Java coders, for Java codersRSS

How MIDlet Signing is Killing J2ME

August 9th, 2007 by Sam

I recently wrote some major updates to OpenLAPI. The update allowed our OpenLAPI to be shipped with a J2ME application, wrapping the Location API (JSR-179) if it is available on the device, otherwise falling back to GPS over Bluetooth mode, or a variety of backends (e.g. CellID lookup).

I was going to blog about the technical challenges that I encountered in doing this, but the changes were rolled back and will never see the light of day. Instead I’m going to tell you all about how stupid the security model is on J2ME and how the Unified Testing Initiative is killing J2ME. I’ll also explain why it means libraries like OpenLAPI will always have to be device specific.

How MIDlet signing used to be

In the beginning of J2ME, it was decided that applications should be signed by a trusted authority or the user would be prompted to grant access to sensitive APIs. Practically, this meant that J2ME developers had to buy a signing certificate from somebody like Verisign or Thawte, costing about $500 for an unlimited number of signatures per year. Or you could upload your own self-made certificates to your handset for development purposes. David Hayes wrote an excellent tutorial on the subject.

The benefit was… nothing… actually. The user is still prompted to allow the application to access the network and instead of the user getting a confusing technical note during installation about “this application is not signed”, they get a confusing technical note saying “this application has been signed by XYZ”. So nobody signed their MIDlets.

Then along came the JSRs

MIDP2/CLDC1.1 was an upgrade to the initial J2ME offering, adding a bunch of APIs that everybody was craving (mostly for games). They did this really well… the APIs were developed with input from the developers and I am especially impressed by how nice javax.microedition.lcdui.game.* is.

Having laid down the foundations of J2ME, standards for optional libraries were created to allow support for device hardware such as sms and cbs (JSR-120), bluetooth (JSR-82), file system Access (JSR-75), cameraphone and speakers (JSR-135), webservices (JSR-172) and location awareness (JSR-179).

This was a great idea! However most of these new APIs require a trusted signature on the application. So, forking out for a Verisign or Thawte signature made it impossible to write hobby projects. This was the death of open source J2ME beyond gaming.

Then along came the clowns (network operators)

When people started having to sign their applications, they realised that Versign and Thawte and Geotrust and their friends were not supported on the devices in circulation! The reason was simple… J2ME never specified a list of default certificates that should be supported.

Handset manufacturers would ship with seemingly random collections of certificates meaning that developers had to get their key signed by every authority they could find. This pushed the entrance price up to a few thousand dollars a year.

But it got worse… the network operators were “customising” the certificate stores on handset requiring everything to be signed by them as well as the handset manufacturer! And the handset manufacturers stopped allowing developers to upload their own certificates in order to run their own code on their own device.

The Unified Testing Initiative

Seeing a problem, the J2ME working groups decided that they needed a single place where applications could be verified as non-malicious and signed with a certificate that would be guaranteed to exist at runtime. Wonderful news! Until somebody seen that they could make a fortune by bleeding the developers dry.

The central repository is the Java Verified Program. It lets you upload your jar/jad file and then it does some automated tests (which are b0rk3n… more on this later). It then lets you decide which devices you wish to test on before letting you select who to send your application to.

Yes, it needs to be manually checked! And only by commercial entities that struck an insanely lucrative deal. To give some examples… it costs about $300 per test, per device! That means if you want to write a J2ME application that uses a “restricted API” on all supporting devices, you could potentially end up spending $30,000 per bug fix! It’s not unrealistic to spend half a million dollars per application. It gets worse… some operators may also require you to dual sign your applications with them, so this may well only be half the cost of the signing process.

I noted that the automated process is broken. This is the reason why a single OpenLAPI jar cannot be part of a UTI-signed application. The whole point of OpenLAPI is to detect JSR-179 and use it if it is available, otherwise using alternatives. It does this using a combination of reflection and wrappers which know when a cast is valid. The UTI process detects that javax.microedition.location.* is used, and plain refuses to allow the tests on anything other than high-end Nokia phones. Defeating the entire purpose! This is why the next release of OpenLAPI will not be as amazing as it could have been.

Conclusion

I really do not see any reason why the signing process has to be bundled with a testing process. And given that J2ME is entirely sandboxed anyway, I don’t see why a human needs to check the application for malicious behaviour.

The decision to restrict JSRs to signed MIDlets was possibly a wise one (identity management through SSL certificates is A Good Thing™). However, it killed open source and hobby J2ME development.

The decision to standardise the certificates on a device was a logical and common-sense answer to a problem that had plagued everybody.

The decision to unify the certification and testing, relying on third party developers in a lucrative position to charge whatever they wanted, whenever they wanted or your application doesn’t hit the shelf is possibly the stupidist thing I have ever heard!

What should have happened is that the J2ME standards committee should have given out a list of standard certificates that must be on a device. They should also have suggested that handset manufacturers allow the uploading of self-signed certificates so that open source and hobby programmers could write programs for their own handsets.

What has now happened is that nobody can afford the prices of testing and signing anymore, so developers stick to creating games. Innovation has been completely killed and if anybody really wants access to the hardware, they either write it entirely in Symbian or use a Symbian component to speak to Java. My understanding is that the Symbian signing process still allows Verisign and self-signed certificates.

So that is why MIDlet Signing is killing J2ME. Long live the iPhone! Let’s hope Apple give all these operators and manufactures a good kick up the butt, just so we can feel some form of vengeance for their incompetences.


This entry was posted by by Sam on Thursday, August 9th, 2007 at 12:42 pm, and is filed under J2ME, Java, MIDlets, OSS, OpenLAPI, Security, Signing. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.



46 comments on “How MIDlet Signing is Killing J2ME”

Regarding “Long live the iPhone!”

By all means, but you can’t access anything in the phone via web applications like you can via MIDP, Symbian etc.

I’ve tried to strike a middle ground: I develop mobile applications (not games) but I don’t certify. Instead I try to avoid the most warning-intensive functions, like file access etc. E.g. it’s possible to make an application that accesses the Location API with only one warning during start and then none. Same with camera etc.

I wrote a similar post a few months ago:

http://www.spenceruresk.com/2007/05/26/the-hidden-problem-with-j2me/

I agree completely - signing is basically killing hobbyist and open source development the way carriers currently use it. This is unfortunate because there are so many cool things you can do with J2ME in theory.

I don’t see why you are cheering for the iPhone though - it locks out all development basically, and they are being exclusively offered through AT & T, who is one of the operators using signing to keep small players out of mobile app development.

Thanks for your comment Anders!

I’m aware that the iPhone suffers from hardware problems… I was meaning this as “I hope Apple cut into the pockets of the people who did this to us” rather than “the iPhone is a wonderful development environment”. I certainly don’t think the iPhone is a good mobile development environment :-)

Good point about the camera phone… but I’m afraid the location API is not as forgiving. If you check the Motorola specs you’ll see that MMAPI (camera phone) requires user permission, but Location API requires a signed MIDlet and permission.

It’s also very annoying that user permission is not persistent across sessions… but that’s another rant for another day.

I’ve tested on Nokia and Sony Ericsson phones and Location API only gives off one warning the way I use it, and after that it’s smooth sailing, even though I read out coordinates constantly, so the Motorola behavior is not universal.

Thanks Anders… that’s interesting to note and also more proof that the security policy destroys any hope of device homogeneity that J2ME gave us.

I agree that when the midlet is signed (no matter by who) it should stop the prompts. Users should assume the risk if any.

The sentiments are absolutely spot on, though you have rewritten history a fair amount to improve the narrative flow ;) Saves me the trouble of writing a similar post, I gave up on code signing when I first tried it 3 years ago as it was immediately clear that it was a nice idea that had been destroyed by the greed of operators and some manufacturers (Moto are bad, others are better).

It’s worth noting that not every API you mention requires code signing to work - WMA works without on pretty much every device. The user does get asked for permission before doing things like sending an SMS, but that is a sensible security requirement IMHO.

suryavardhan agrawal wrote:

Hi,

I have a J2ME application, also I have got a certificate from Thawte, but when I run the application on certiain Nokia devices, it prompts me for certian permission. Can you explain me what can be the exact reason behind this.

Suryavardhan Agrawal, I think you just proved my point.

Situation is quite similar in Symbian with native applications: http://www.ivankuznetsov.com/2007/08/symbian-os-platform-security-good-or-evil.html Certification was a nice idea, but as they say the road to hell is paved with good intentions.

Justin Pretorius wrote:

Surely its obvious that the future of software / application development is in mobile devices.. and then doesnt it make sense to feed the need by creating easy paths from concept to market. The only way that this kind of developement can thrive is for security levels to be REDUCED (exactly as they are on the PC) and allow the user a choice whether to trust a piece of software or not (potentially signing could be a criteria .. but in a more productive way). We are currently developing software that requires extensive use of jsr-75 (file api) .. you can imagine the absolute stupidity of 2 questions for every read / write operation .. my word .. LETS MOVE FORWARD.

What I really ‘love’ about signing J2ME apps is that the certificate is only valid from the date you bought it (not valid for the past). So _even_ if we manage to get past all the problems mentioned _and_ we’re willing to accept that the user is still going to be bugged by a certain amount of security questions, if the user didn’t set the date on their handset (not that unusual, people generally use their handset for the time only) and it defaulted to something like 1st Jan 2002, the certificate will not be valid and the user gets a nice friendly “install failed” message which makes us look great! (I asked verisign once to sell me a certificate that was back dated by 10 years but they couldn’t do it.)

Derek Konigsberg wrote:

I never realized how bad it was, given that I only develop for the BlackBerry. On the BlackBerry, you basically have signed and unsigned APIs. (and can do quite a bit with the unsigned APIs) To use the signed APIs, you just have to fork out $100/year to RIM, that’s it. I thought it was annoying, but now I realize that I should be grateful for it.

Yes, I do write an open-source non-game application for the BlackBerry. I’ve been doing everything and anything to avoid a signing requirement, simply because of the implications it would have for an open-source project. I know I’ll have to bite the bullet eventually, though.

Ali Kianzadeh wrote:

“Java Verified Program” Is realy bad, you can’t get certifcation before test and you can not do real test on many devices without certificate. Some phone manuafactures doesn’t let you to import your certifcate to thier device.

I think is time to open source community find a way to issue developer certificate free or with a low price.bore J2ME died.

It really is that bad. If you want to read some first hand J2ME experiences and tips, see http://www.j2mesecrets.com where I tell the whole sorry story.

John Dickerson wrote:

Axiom:

Those who have the authority to make J2ME a very exciting and cutting edge platform have behaved like a bunch of useless and intellectually deficient muppets. The result is much J2ME innovation and open source contribution has been totally killed through a combination of human stupidity and greed of opportunistic companies charging to verify and sign applications.

Does anyone from the J2ME standards committee or companies that charge extortionate fees for testing and signing J2ME applications have anything to say about this Axiom?

We want to know!

J2ME, in my opinion, is going to die over the next few years. It might have an enormous market share but the cost structure is too high due to : porting costs, testing costs, signing costs, and the need to hire someone full-time to pander to the carriers. BREW is messed up because it still has high porting and testing costs (not as bad as J2ME but still bad). Plus the way Qualcomm has set up the business model makes it very difficult.

Windows Mobile, Symbian, Android, and potentially the new iPhone SDK are much easier to develop for because:

  • they are easier to port to multiple devices of the same OS
  • provide far more hooks into the native OS and other applications, allowing for more compelling applications.
  • having easier signing requirements
  • Allow for clean upgrades of a binary for version updates/bug fixes.

FlashLite, unfortunately, seems to be far behind in what it can offer.

Man I don’t know how the mobile development world got so ugly. I hate to say it but I wish it was like the PC world where you just have to create Windows and OS X, and perhaps a Linux version — and you’re done.

Why should you have to have a certificate on a phone, but not on a PC?

Hello Sam,

Several comments:

  • first, glad that you like MIDP2.0 Game API, as I was higly involved on it in my previous job (In-Fusio/CTO, where In-Fusio “donated” his Game API to the Java community

  • concerning security: it’s even worst now with Symbian 9.0, where you CANNOT deploy any app without being signed! In this regard, MIDP security model is like a dream! This require end user to sign himself, on the web, with his IMEI…Who will do this?

  • let’s hope that androids will drive things in the right direction. Not because this a new platform, so more fragmentation, but because JavaAPP are first class cityzen. So let’s hope that security model will be much more open and useful.

Last thing, I’ve been here through the OpenLAPI library, I’ll take a look at it, to eventually replace the code produced with my app, 8Motions ( http://www.8motions.com ).

One idea, use CellID as a location provider: http://www.opencellid.org

@Tomsoft thanks for your comment!

CellID is certainly something I’ve looked at quite a bit. Problem is that you can’t get the CellID on anything other than old Motorolas and Sony Ericsson. Motorola allow this iff your MIDlet is signed by Motorola (UTI isn’t even enough!).

I’ve also even investigated getting the CellID from the CBS headers, but J2ME strips them out! I was actually only able to find 2 CBS channels in the UK anyway, and both were on Vodafone networks… so that killed that idea.

Even then, you still need a reverse lookup database on the device or over the network. In the UK there has been some legal action prompting Ofcom (the industry regulator) to open up its database. This was recently appealed, but the appeal was crushed. Most of the network providers have since retracted donating their databases to Ofcom. There are community projects to map the CellID terrain.

I believe that you, like many people in the community, are exaggerating. 1. Does a question about a permission here or there really stops an end user from using an application? 2. You can make it less painful if you let the user know that they will be asked for a permission and that they are supposed to say ‘Yes’. 3. You can make as many alternatives as possible. I.e. let them use FileConnection JSR-75 to access a file, BUT still make it possible to access the file from outside the application.

/Yar @ YarMobile

I don’t think people are exaggerating. Try to write a directory / file size display program - for every file in the directory you need to say Yes twice! If you have 20 files in a directory, that is 40 Yes-es. Why cant we self sign?

Nobody is exaggerating for sure!

This article brings out darker side of J2ME development loud n clear. Yeah… http://j2mesecrets by Dan… superbly expressed, i read that few months ago. It is sad to see a technology like J2ME facing this. We have fast growing competition from BlackBerry and soon to come Android. Blackberry(BB) now issues signing certificate for $25. No carriers to play in between, no prompts. Anyone with knowledge of java and intelligence to understand & use BB APIs can start development on BB phone. In the wake of this, where do we see J2ME heading as a technology for individual developers?

Though i’d say j2ME is too important a technology to die down… but its time to take a call on J2ME signing issues !!

I pretty much agree with what you say after developing a J2ME application and wonder why it keep failing when using file system Access on a Nokia Phone when it run well in phone emulator. I reckon it is something to do with certification. Now I wonder if JavaFX Mobile can learn from this debacle and fix the issue because there is no point in advertising how good a technology is if ultimately the high ‘hidden’ cost of building a application is prohibitive.

Why are some APIs required trusted signature and others required user permission only ?

Could the following suggestions work ? - Application permission to use resource based on user trust. - All APIs are accessible without the need for trusted signature and user permission. - When certain APIs are used like network, file access, these information are stored in the jar file. - Within the mobile application, the J2ME runtime will construct a additional page in menu option to allow user to turn on/off those permission to use certain resources based on the ‘certain APIs’ OR If the mobile app is signed with trusted certificate authority, allow user to check this option to enable all permission to use any resource required in the app.

So in this way, it is up to user to either trust the certificate authority to access all resources or they can just turn on the permission to use those resources.

Developers no longer require to pay for expensive authority certificate or suffer certificate incompatibility, and if they want, can optionally purchase certificate to give user a piece of mind.

These mimic more or less of how applet works.

MICADeveloper wrote:

GeekyCoder, I am not sure that what you are saying is right. I have Sanyo Pro 700 and if I want to access the GPS data, it won’t let me. If you know a workaround, please let us know.

Thanks,

MICADeveloper, actually what I implying if Sun could implement some sort of my suggestions that work quite similarly to applet.

“All APIs are accessible without the need for trusted signature and user permission” This part is where the current APIs fall short because as the author has mentioned that some APIs required trusted certificate to work. “However most of these new APIs require a trusted signature on the application. “

[…] After many hours of googling, I had to conclude that it was either a problem with the hosting provider’s apache or php installation, and I still have no idea what the specific issue is - their Apache sends data using chunked transfer encoding, which is confusing. Their support just took my word that it was probably apache and said they couldn’t do anything about it, which was obviously fucking awesome customer support right there. My eventual solution was to create a temporary php script on my home server, which then sends the files on to my shared hosting server. It’s a crap solution. I had tried a great deal of other solutions, including direct socket communication with the server - this worked on the emulator, but sadly threw a SecurityException on my phone - apparently, making direct socket communications to certain ports (including 80) on a remote server is not allowed without a signed midlet. I don’t want to pay for a certificate, and I can’t use a self signed one with my mobile. I hate midlet signing. With a passion. This dude can explain why! […]

Sorry, I need to a.) find out what a pingback is and b.) turn the damn things off. Thanks for a good article!

Freedom comes at a price and that price is risk. I can walk around outside without being constrained or controlled because I have the right to that kind of freedom.

Nobody is constraining me because I might potentially do harm to others which is a possibility in the sense that its within my power should I choose to. We accept the risk that comes with freedom of choice. Much like I can climb into my own car and turn the key without first having to take a drug or alcohol test or seeing a psychologist to determine that I am fit to drive. I have this freedom because these are my rights - my rights to live my life as I see fit and to excersise my own judgment. But also I treat others with the same kind of respect and expect that they will act responsibly. It is this expectation that gives me peace of mind and a sense that humanity as a whole is moving forward… I don’t tremble in fear whenever I see a car driving down the road - I expect that person to have dignity, self control, I believe that overall humanity strives for the same things as I do - happiness, freedom, purpose… That in order to become better we must live as if we are better - we must believe it in ourselves and in our societies and prove that no constraints are required. Sure there will be instances of individual cases but should the risk that one person might act out of line justify that we are all to be treated as criminals?

To have the power to excersise choice and free will is part of my right as a human being. These are the things that make life worth living. How can we make a significant positive impact on the world if our hands are tied - Some might argue that a mobile is just what its designers intended it to be - a tool used to communicate. But we must not blind ourselves to the awesome potential of these devices. Something you might throw in the trash could have run an automated system to provide food, water and essentials to people in third world countries - It could have saved their lives. It would have been the ideal solution to this problem and many other less serious applications like re-using these devices to for example run a sprinkler system and alarm system or whatever. You could go to the moon and back… really.

Some people seem to believe that the answer lies in control: We are being watched wherever we go, what we do, who we talk to. Its all the same backwards mentality here. We are too damn afraid of freedom. Look at what they do in england nowadays… Youngsters carrying knives and thats a problem… The problem is also founded in that because they are treated like criminals they act like criminals. Its been proven in drills where police officers play the roles of prisoners to actually start behaving like prisoners. Where it this heading to? Here in my country I can carry an axe down the road and people wont start running thinking Im out to kill somebody… They’ll just see a guy with an axe walking down the street.. nothing to see here… Is this what we have devolved to? Animals? And if we start treating each other like barbarians then don’t you think that will have some impact on our self image? I mean if I treated you like an idiot wouldn’t you feel stupid? Would you still have self respect and will you have respect for others? What if everybody treated you that way all the time… If I treated you like a criminal won’t you take offense in that? I think all those CCTVs are making people feel that society has devolved and failed. I don’t live in a country with stuff like that and you know what - I wouldn’t like to and I can quite happily say that we don’t need to because we’re better than that.

I will not sacrifice freedom just for the sake of having the peace of mind that nothing can go wrong. Like removing all cars from the road just because someone might have played carmageddon a few too many times… Why don’t they build one gigantic prison and keep us all under lock and key. Surely then nobody would get robbed, killed or raped during late hours of the night… but at what cost? Are we willing to stoop to such low levels? Is that really necessary? You see the bottom line and many people don’t seem to get it. Sure security is needed to protect us from the minority that do want to cause harm but not to the point where it denies us from what the world would otherwise have been and worse to deny us the opportunity to prove people who assume less of us wrong - that the benefits outweigh the risks. It should be the end users choice - not giant corporations which brings me to my final point.

I believe that all these constraints are imposed by manufacturers so they can keep control of their products. If there is potential for say a manufacturer of mobile devices to build industrial controllers using the same technology they will want to exploit that for their own benefit - You the measly programmer such as I - we are utterly and totally at the mercy of giant corporations who are out to make as much money as possible out of everything - including developers like you and me. So its not really about security - its about control. They want to restrict what you can do so they can keep steering where things are heading. So they can take credit for adding some new feature to sell more devices. Whats funny is that they’re too damn stupid to see that if they make a device that developers will love and have the freedom to do amazing things with then those developers will write awesome software for those devices - this in turn will make it a hit with consumers who will just be amazed by what these things can really do. I’m sure everyone who has visited this site has been here… you have an awesome idea but no… you are assumed to be a criminal and just in case neither society or manufacturers are willing to give you the chance to prove otherwise… Its like throwing you in an intellectual prison - a slap in the face.. an insult to who you are and denying your rights on the premise that you might do something bad.

The hands of developers are tied - and end users are oblivious to just how much their mobiles could actually do. If they knew what you and I know - they would probably be protesting in the streets but to be honest they don’t have a clue of what is actually possible.

It saddens me sometimes to be part of the human race and I am ashamed for the larger part not of the individual atrocities but that we as society as a whole are starting to admit defeat and failure. I could go on for hours about this and don’t let me get started about morality and the media.

Id like to touch on this also because I think it fits into this theme…. You hear of people doing sick things on the news almost every day why? Why should I be subjected to that rubbish? In the old days all these evils happened… Stuff happened but it was handled discretely - justice was served but the rest of the people were just not so common to show interest in this… it seems people actually want to see this stuff - they are desensitized and they have no self respect left - nothing that sais… you know I don’t even want to know about it. And the worst of it is that its got absolutely nothing to do with me and doesn’t affect my life in any significant way except that it sickens me to have to listen to this or have to look at this kind of evil on a daily basis. There is a difference between when you are being told what to watch and what you can watch…

Bottom line: removing the choice from the end user or developers was wrong. They should have provided settings on the phone to disable these restrictions for each application - so you can say yes I trust this app but not that one…. Its really ridiculous and only proves that neither end users or developers are controlling corporations - instead these corporations are now using the J2ME security model to control you and me and regular users alike. The worst part of all this is that people knew this - Yes security is necessary but I want the damn choice - is it too much to ask?

@SomeGuy you get the award for longest comment… ever!

Hi

I have been rolling out security critical Java ME deployments for some years now and code signing is indeed one of the biggest stumbling blocks. I have always been supportive of Java ME, but given the insanity of the whole code signing process (plus other issues: platform fragmentation caused by optional JSRs, inability to detect phone models, etc.), I truly hope that Android and iPhone will render Java ME superfluous.

FRED

i probably have not understood the signing process entirely but what takes us from installing our own certificate on the phone and signing the code with that certificate? it is a longer process for sure but doesn’t it eliminate the need for buying a commercial certificate?

@ali, you can’t do that on most modern phones, e.g. all Motorola handsets.

I work at an operator, and even this problem is pissing me off. My role is to get applications from freelancers and companies, and for a freelancer, $500 is no small thing. This issue affects their productivity as well as mine. In this case, the iPhone is a better platform than J2ME (of course, as an operator, I don’t get money from iPhone apps though)

J2ME Signing…

Besides writing a mobile application specific to one type of phone (eg IPhone, Blackberry, Android, etc), if you want to build an application that’ll work on the bulk of the handsets out there the only real choice is J2ME (Java 2 Micro Edition). Besid…

[…] By coincidence, one of the first things I did when I joined Symbian in January 2002 (I think it was in my first or second week) was to represent Symbian at a meeting of the JSR 118 expert group which was working on the Java MIDP 2.0 GSM/UMTS Recommended Security Model. I had some serious misgivings about the document but, as it was about to be published just when I joined the group, it was too late to do anything about it. It defined specific “protection domains” (trusted third party, operator and manufacturer) which had hard-wired special cases (operator-signed applications were supposed to stop working if you changed the SIM, and so on). This worked so poorly in practice, with different manufacturers and different operators interpreting the spec differently, that most independent software developers saw no benefit from having their MIDlets signed. […]

Irving B wrote:

This is a very good discussion. An article that I read said that operators think of J2ME as being mostly for games. Given the problems with signing, this is a self fulfilling prophesy as writing applications is prohibitively expensive due in part to operators, etc.

Hello everybody,

I don’t know very much about Midlet signing and am a pure hobby programmer. So I have had problems with restricted access for many months. But some time ago I bought a HTC touch diamond with windows mobile. When trying again I stumbled on a site (xs2us.eu) where I found the solution that works for me!

@Peter B.

It is not possible to install a root certificate on all devices, a Motorola RAZR for example. The service offered by xs2us.eu is to provide you with a private/public SSL certificate pair… you can generate these yourself using the OpenSSL open source software. If you are impatient or confused by the OpenSSL documentation, $30 might be an option, but I personally recommend producing your own keys if your handset allows it.

@Sam

Oke, I only used it for my own HTC. At first I tried to use OpenSSL, but kept getting an error when installing my Midlet on the PPC. It said something like ‘unable to verify the digital signature …. ‘. So for me the $30 saved a lot of time.

While midlet signing has a valid reasoning behind it (to prevent ill-meant midlets from stealing valuable personal data), even developers themselves cannot get rid of the unnecessary checks even on their own phones!

Yes, I guess that’s Sun’s fault that it did a lousy job of checking the MIDP implementations of specific phone manufacturers - how would they ever get the “Java Powered” logo then?

Look at Android: http://developer.android.com/guide/publishing/app-signing.html “The certificate does not need to be signed by a certificate authority: it is perfectly allowable, and typical, for Android applications to use self-signed certificates.” - It could be that simple for MIDP as well but the phone manufacturers decided they knew better…

In fact, I’m about to start developing for Android now. The MIDP, as is, is just not up to the task of serious development.

As for CA certificate costs - yes, I also think the price is just insulting for typical midlet developers…

Thank you for your post! Even if it dated two years ago, the same crap happens today.

Luckily, we have Android now! I suppose that 90% of application developers will switch to Android because Google ever supports developers, while Sun and carriers are trying to make money. It seems that Android takes all the problems of mobile applicaiton development and solves them at one time!

Special thanks to “j2mesecrets” site author.

J2ME is dying. Long life, Android!

Yes, Android can be good thing. But it is new platform, not enviroment (like .Net Framework for PC) so only new (that means: high-cost) devices will support it. Of course, after couple of years the situation can be another. But yet there are a lot of devices, which requires JeME support, in the world. So J2ME still alive..

[…] Szukając materiałów na temat znalazłem wpis na pewnym blogu o bardzo wymownym tytule: “How MIDlet Signing is Killing J2ME” […]

Nice article.

My first mobile app and I run right into this crap. Can’t read the file system without a warning every time. Can self-sign the jar, but can’t install the certificate on the phone. Am not willing to pay $$$: I bought MY phone and want to run MY stuff on it. Its mine. But apparrently I’m not allowed. What a load of crap. Its all over for me and mobile apps - at least as far as J2ME is concerned.

I wish if I read this article earlier, after spending hours and hours on a j2me app, I’ve learnt that I cannot distribute it, only by paying hefty price, so my development is kind of useless!!! Well, this is what you get if you don’t research before starting development :) There must be a way around this, maybe getting a copy of Sun’s cert?!?

Leave a comment

Markdown is supported.

To include code snippets in your comment, use

<pre><code># lang java
... code here ...
</code></pre>

or use 4 spaces at the start of the line instead of using code and pre tags.

Comment feed: RSS