I've just discovered J2ME and I love the possibilities that it presents. I'm currently working on a simple application and I'd like to maybe release it as an open-source project sometime in the future.
As part of my research into J2ME and mobile devices, I looked into applet signing. It seems that people who want to create applets for free are caught between and rock and an awful shite-place. Applet signing is extremely expensive and extremely convoluted - and the expense can't be justified when coding for free.
There are a huge number of J2ME compatible devices out there - I think it would be a shame to have to ignore them, and just wait patiently for the next wave (e.g. Android).
I was wondering if other people have any ideas about ways to approach this problem?
UPDATE: I found this blog article which summarises the problem for those interested... http://javablog.co.uk/2007/08/09/how-midlet-signing-is-killing-j2me/
I thought about setting up a non-profit umbrella organisation for open-source J2ME developers who want a VeriSign certificate (as a certificate can sign code an unlimited amount of times). I would aim to raise the $500 and then enable group members to share the purchased certificate. Had a quick chat to a VeriSign rep and they thought the idea could work (as long as the organisation was registered as a legal entity).
However, since handset manufacturers now seem to be moving to support only UTI root certificates (which you can only get through the 'Java verified' programme) - this might not be as useful as I thought it could be... if anyone has any ideas would be great to hear them.
I am afraid that you are fighting a battle that you can't win. Using the restricted APIs is getting harder and harder and this is not accidental. As you've read in the blog entry you've mentioned the biggest problem is the network operators. Even if you buy a certificate from Verisign or Thawte (which is by the way cheaper), your application won't run in network operators branded phones, since these have their own CA rules.
At first it was possible for a developer to install his/her own certificate, but even this is now not possible. This strict rule is mandated by the phone manufacturers (Nokia for example) and applies to all phones (even no branded ones). I believe that this too is not accidental and is mainly because of pressure put to device manufacturers by the network operators.
Finally, although MIDP 3.0 has been announced for years, nothing has really come out of it. It seems that even Sun believe that J2ME is only for games.
All of these have been extensively discussed in J2ME forums for a long time. The general consensus is that the network operators do not want to have every phone available in the market operate as a smart phone and be able to run a third-party application. Then it will be very easy for everyone to use a cheaper, web-based alternative instead of SMS messaging for a example. This may sound as a conspiracy theory, if you are new in the J2ME world, but have in mind that network operators sell phones with their own firmware that lock even basic functionalities (e.g. transferring photos via Bluetooth or using MP3s as ringtones) to force the owner to use paid services!
I don't know if this is going to change now that smart phones (iPhone, Android, Windows Mobile) are gaining momentum. Have in mind that restrictions apply also for these platforms (notably Symbian, which is also very unfriendly for open source).
You can create a signing certificate
that you self-sign. Your users have
to be willing to trust you.
You can instruct your users how to
create a cert and self-sign with it.
Then the users have to be able to
trust themselves.
There are more or less open CAs; you
have to be willing to trust them and
convince your users to trust them.
The Java Tutorial has a section on signed applets that will lead you through the steps.
I'm a J2ME application developer and i totally agree your post. The costs for signing a MIDlet are simply unaffordable for open source initiatives and unless your're developing simple games, you'll soon or later end up in using restricted APIs to access sockets or Location API just to name two of them. This is very frustrating and if you consider that the permission policies are not always threated the same on various devices, the thing get worst: on some mobile phone you can tell the OS to trust the entyre MIDlet and never bother you at all, other continue to ask you permission every time you call for a restricted method. It's tragic!
I rellay appreciate your proposal and i think it would be a great achievement for JavaME developers.
Related
I'm a software developer. The only browser I have at work is IE7. I don't have freedom to select my browser.
I am constantly learning and researching things online and, of course, IE7 is a very poor tool for doing that work.
I've been invited to present a business case for replacing the dev team's IE7 browsers w/ a something more modern. I don't want browser recommendations, and this isn't about which browser the users of my software/webapps will use, but...
... what behaviors/traits/sideeffects of IE7 should I highlight when making the case that it has a very real negative impact when I'm trying to do my work as a software developer?
Do I talk about security vulnerabilities (on my workstation)? Do I talk about the cost of waiting for tabs to open all day? Do I talk about the memory leaks? Do I try to measure how often the browser just flat-out crashes on me? What would resonate best with the corporate decision makers?
Words that important people like to hear:
Security (use open security vulnerability charts and such)
Standards (talk very briefly about web standards, but then hammer in the point that IE does not follow them throughout the presentation)
Productivity (here's where you get to talk about speed, additional features etc)
Also make sure to talk about the minimal cost that the switch will have in terms of IT time required.
You did not explain what you are developing, and who you do it for. If you develop for an audience of 15,000 IE7 users, I think you have a weak case.
If you develop public websites, you have a very strong case, and many arguments to support it. It all depends ....
Our clients must pay a monthly Fee... if they don't, what is the best way to block the asp.net software usage?
Note: The application runs on the client own server, its not a SaaS app...
My ideas are:
Idea: Host a Web Service on the internet that the application will use to know if the client can use the software.
Issue 1 - What happen if the client internet fails? Or the data center fails?
Possible Answer: Make each web service access to send a key that is valid for 7 or 15 days, so each web service consult will enable the software to run more 7 or 15 days, this way the application will only be locked after 7 or 15 days without consulting our web service.
Issue 2 - And if the client don't have or don't want to enable internet access to the application?
Idea 2: Send a key monthly to the client.
Issue - How to make a offline key?
Possible Answer: Generate a Hash using the "limit" date, so each login try on software will compare the today hash with the key?
Issue 2 - Where to store the key?
Possible Answer: Database (not good, too easy to change), text file, registry, code file, assembly...
Any opinion will be very appreciated!
Ah, the age old issue of DRM. And that's what you're talking about here. Frankly, the fundamental answer to your question is: you can't. No matter what you do to the system, it can be hacked and modded in such a way that your DRM authentication scheme can be bypassed and/or broken.
This is a fundamental fact of software development: it can and will be pirated.
So, the answer to your question is that you will have to trust the client to pay you the fees you determine to be correct (which is the whole point of contracts in this situation).
Any other actions you take are a hardship and annoyance on your paying customer, and has the potential to erode your customer base.
Now, if you want control of your software in the nature described, then do not provide it to users to run on their own servers. Force them to be SaaS. In that way, you control all of that. But this is the only way.
Something that you don't appear to be thinking about, but I have seen networks which do not allow any type of "dial home" solutions, as a majority of the systems were internally focused and thus these internal servers were NOT allowed to contact the outer internet. At all. It was deemed a security risk to even allow them access. How would you handle those networks?
Frankly, if I was the customer, and I paid my fees to license your software (which I installed on my own device) I would be irate if I had to allow that device access to the internet in order for it to work. Doubly so, if the software in question was any type of financial management, customer management, HR management, quality management, inventory management, sales, or just anything related to my business, customers or employees. I don't trust software developers enough to have their software talk to something else when my business-relevant data is held in their software.
In the end, what you are describing is an antagonistic approach to take with your paying customers. If you don't believe me, look at the comments that UbiSoft is getting for their latest customer-hating DRM scheme.
IMO, you have two good paths here:
Go SaaS
Ensure your contract has a
bite for non-payment
usually you provide an scrambled key that includes a valid authorization token and the expiration date through which service is paid. Then the installer will use this to "activate" your software. Not sure how this would be viewed if you have 1-2 week periods. you'd want to warn them about upcoming expiration. Also not sure how to tell if they've set their own clock back.
In short, nothing will be perfect.
I've dealt with this before and its not possible to make a perfect system. There are risks in anything you do. The best thing is to weigh your options, and determine the method that has the least likelihood of being hacked and the most likelihood of working correctly and easily for the customer.
Like others have said, they could change their clock and invalidate the license checking mechanism. If you didn't trust the user, you could make the license system connect to your servers. You would then need to ensure that they always have a connection to your servers to check the license.
What if there is a valid reason that they cannot access your server?
Their internet connection has a problem.
YOUR internet connection has a problem.
In that case, should you disable the application? Probably not. But then again, what if they shut down the connection on purpose? Then you would WANT to disable the application.
If you give them a monthly key, you're adding a monthly annoyance and you may lose a customer after a while (people tend to do business with those who make it easy).
For example: If you base it on their clock, and the application needs their clock to be accurate for some reason, then its unlikely that the customer will change their clock.
I agree with Stephen but ultimately, I think that your contract is your best ally here.
As been previously mentioned, you don't want to inconvenience customers, especially if you have a large deployment.
As for SaaS, if I were a customer using your product and you said that the model is changing and we need to access the software from your server and ours must be decommissioned, I'd not be happy. I'd probably use the opportunity to switch packages.
In corporate settings, the contract really is the best way to handle these issues. I've worked on licensing issues for desktop and ASP.NET applications and they can cause a number of headaches for both you and your client.
However, if you insist on using something like this I suggest you go with a middle ground. Instead of only unlocking the application for a week or two, provide a license for 6 months or a year. This way, if you run into licensing issues (and you will run into issues) they only occur once a year rather than a couple of times per month. That will be cheaper for you in support and your clients will be less unhappy about dealing with licensing issues. If the company stops paying and you need to terminate the license you can handle that on a one-off basis, using contract enforcement as needed.
On the web service or client license options, I think a good license system would incorporate both. A client license to provide a the application a stable license and a web service to generate and deliver the license key when it is time for the application to be renewed. If the client won't allow the application to call home to get the license key also provide a manual entry method.
If you are going to store a license on the client, do not try to build a component yourself. There are many components available which will be much more robust and reliable than the one you build. There is a .NET .licx-based licensing method and a number of 3rd party methods that you can use. Which one is most appropriate depends on your scenario: how flexible you want the license and what other options you need. Most importantly, find something reliable - any time your customers spend fixing problems caused by licensing is non-productive for them and will reflect poorly on the application.
The important thing to keep in mind is that no system is fool proof. If your application is valuable, someone is going to figure out how to steal it. But at the corporate level and with custom software it's more likely the licensing will be used to remind people to pay rather than stop wholesale piracy.
I'm not a Silverlight developer (yet) and what is putting me off - and many others, I think - is the relative lack of browser installations of it compared to Flash.
But I'm not clear on why website visitors have to explicitly install Silverlight themselves - which appears to be the major stumbling block.
Since the vast majority of computer users use Windows, is there a reason that Microsoft are not forcing Silverlight onto Windows machines through a Windows update?
They do this (and continue to do so) with the .NET framework runtimes, so why not with Silverlight? Legal issue, perhaps?
Getting sued by all its competitors is what stops this
There are several reasons why not to do it.
Users should have choice over what gets installed. I realize from a developer standpoint we know some users who are clueless about what this software does, so why put the choice in their hands? Fine, MS should make it easy for users to install it if they don't have it when they visit a site that uses it. Then they can make an informed decision. Do I want to use this site or not?
Corporate Approvals. Companies go through software validation procedures and that is why some will still be on XP for some time. If they were forced to validate these pieces because microsoft was forcing them down the pipe, they'd be pissed off. So thus MS gives corporations control over the windows updates that get approved/installed. And corporations are where MS makes their money.
PC Manufactures choosing what software to preinstall. Here the manufacturers have the ability to push silverlight or not.
Competitor's software isn't automatically installed. You actually have to install flash. Some PC manufacturers might bundle it with the PC but if you install yourself or for a corporate deployment, it isn't there by default.
The monopoly power abuse concerns mentioned. But I think this is actually the least important reason.
Silverlight won't hit mainstream adoption till there is that one app that everyone must have that uses it. Like the office online example above.
I think that would be the wrong way to go about trying to gain adoption. The product should merit installation on it's own, not lean on the Windows installation base for support. Writing the free version of Office online (EDIT: I meant the Office Web Applications) in Silverlight, however, is a great way to gain adoption (even with the non-SL version available too http://blogs.msdn.com/officewebapps/archive/2009/08/05/9858563.aspx).
Also, since this is a browser plugin, how would that work? Can a Windows update install plugins for firefox, opera, or whatever browser the user prefers? Doesn't seem feasible to me but I'm really not sure.
They actually suggest it in Windows Update. I politely refuse it.
There may be an anti-trust reason for this also, remember what happened with Java, even when it was from Sun they still had a problem with it.
If you keep waiting for Silverlight to catch on, it never will be enough, start developing now and when there are many great web-apps that support Silverlight then maybe it will get more popular, plus it is very easy to install and you can target Mac and Windows, and some extent Moonlight too as it reaches support for Silverlight 2.0 and some 3.0 there may be Mac-Windows-Linux apps you can write.
I recommend Silverlight to anyone who develops in .NET, I am a little biased as I'm writing an application at the moment in Silverlight.
I suspect that they are waiting for the technology to mature and/or gain more acceptance. Once a critical mass of sites and/or users have it installed they might do.
The other alternative is that they might be waiting until they've completed the "merger" of WPF and Silverlight. I can't see them continuing to keep these two very similar technologies separate.
After all Adobe don't force Flash on everybody.
Can't speak for Microsoft, but I am dismayed by the question. I don't want extra crap pushed to my machine (or into my life in general). I only want extra stuff if I pull it. Stuff like that should always be "opt in" instead of "opt out" or "no option at all."
The european union has filed anti-trust suits against Microsoft which is probably why they don't put it in their updates.
I however don't install it because i don't like unnecessary processor cycles being used up for advertising much in the way that flash is used. Flash I've uninstalled on many of my computers in protest, though i admit it's on my media center in the living room because people use it for you tube.
For all the hype, Silverlight is not all that great to develop in and doesn't bring anything to the user experience that couldn't be better achieved through dhtml/ajax.
We regularly convince our clients of the values of having a good quality intranet and systems, but within my organisation it doesn't seem that we're "eating our own dogfood".
We have really lacklustre intranet systems - a hastily thrown together sharepoint install that no one really oversees. An additional cobbled-together legacy intranet system that's been dragged "into" sharepoint by loading it in frames.
The general approach is that the senior developers are "too valuable" to waste on internal development, so responsibility for these systems falls to the least qualified, the work experience guys, etc. At least until they're found more lucrative work, and shipped off to a client. Hence the cobbled-together nature of our systems.
It's very much a case of the mechanic driving a shoddy car.
So how do you handle it? How can I convince management to spend effort on our internal systems?
Or is it actually that within a tech company that it's not worth it? Are high-quality systems only required for non-technical users?
Do it the same way that you convince the clients. Show the business value of the investment. If that can't be done, then it would be a waste of resources.
The best choice is adopting common Internet structures, such as blogs and wikis. Wikis, in particular, are very effective.
Having some kind of karma system can also be useful. Many people will do for status what they wouldn't do for money.
I would like to set up some WMV Video Streaming, using Windows 2003's Streaming Media Server and Silverlight.
Now, unfortunately Silverlight only supports HTTP, which means that people can just download the videos. While that in itself is not a problem, I wonder what options there are to prevent them being playable outside of the network.
Of course, DRM comes into mind. Is there an easy way to get it and set it up? I do not want to have some complicated User-Scheme, it essentially boils down to "If you can reach the server (which is only in the internal network), you get a license, otherwise not".
Any experience with WMV DRM or Content Protection in that area?
What would I need on top of Windows 2003 Server and Silverlight 2?
DRM is a negative sum game. You lose money and time in implementing it that you could have spent on something useful to your users, and your content becomes less valuable to your users. It is also impossible to implement effectively. I'm not going to address any specific DRM scheme, but the core of the argument is that in order to show content to the user, the user's computer must be able to decrypt it. Therefore, the decryption code, and the decryption keys, must be present on the user's computer. Encryption can only protect data from interception and tampering between two secure endpoints. If one of the endpoints is compromised (and you are assuming this in your distrust of the user), then cryptographic techniques are useless.
Michael: you could do a few things. You could use IIS7 and create a web playlist which can be protected by SSL certificates to secure the stream. Additionally Silverlight does support a no-touch (from the end user's perspective) DRM scheme we call PlayReady. It does involve having a server to issue the license so that may violate your desire for a no/low cost solution (but DRM solutions rarely are). These are two options though.
In this session the baseball guy talked about making the URL's usable only once. I assume it's not a 100% solution but it could prevent users from copypasting url's.
An alternative to in house DRM is hosted DRM.
We "EZDRM.com" offer a great low cost solution, and still provide you all the features of DRM.