I know people who have left Facebook, and others who are considering it, simply because of the ridiculous number of application requests they get. Every day my requests page is flooded with

• Kath wants you to be a vampire and fight off hobos and skeletons with the ninja turtles… sorry Kath, I live in the real world, and if I’m going to play a game, it will be a little more appealing than that.

• Jimmy wants to know how alike you are… If we were anything alike, you’d know that I f*cking hate these stupid application requests.

• Bob thinks you are sexy… Bob is a man. I am a man. This doesn’t work for me, no matter how sexy Bob thinks I am.

• Gemima wants to know what kind of lover are you…? If she really wanted be my lover, she would stop wasting my time having to block her Facebook requests and making mental notes to push her over next time I see her.

• If you add this application I will have anal sex with an Arabian orphan monkey and name my unborn child gumby… Well, I’d probably consider this one… only because Gumby rocks though!

I know I am not alone, my roommate has been saving his up for a few weeks and is at well over 400 application requests.

Any application request I get, I will automatically block. Why? Because if an application was really good, someone would tell me in person about it, or write on my wall about it, they would not spam me. That is what viral marketing is, not unsolicited, unwanted advertising in my face when I could think of nothing worse. The worst are those applications that don’t allow you to use them until you spam 20 friends.

This is the big Facebook fail as far as I am concerned – they are fabricating spam and alienating their users that are act over the age of 15. When the developer platform was released, the development community was excited, but the only people to benefit are those annoying people with too much time on their hands and that enjoy doing quizzes to see which pole dancing move is most likely to pick up the inbred transsexual they secretly desire.

Don’t get me wrong, I have enjoyed quite a few applications, especially Jetman during last exam period instead of studying, but none of the applications I have added have come from requests.

Facebook seem to slowly be warming to this theory with the “Ignore All Requests” and “Block Application” options now on the requests page, but it seems this is too little too late. Facebook needs to disable applications being able to spam users, plain and simple. Until they do that, I think their user base will begin to shrink.

As well as the annoying spam is going to a loser’s person’s profile and not being able to find their wall, photos or any other core Facebook features some people still use, because their page looks like a slightly more valid, but equally painful, Myspace page. The implementation of the extended profile was another fail by Facebook. As if any of these people of well below par maturity are going to remove these applications off their page themselves. The way for that to work is if all non core applications are automatically put there, and it is then a hassle to get an application back onto your front page.

Facebook started so promising, but day after day it is slipping into just another over stimulating piece of shit website that only 15 year olds will use.

Note: I am not leaving Facebook, but may consider it in the future.

First there was the fact that a self signed certificate wouldn’t do. This wasn’t a big surprise, but it wouldn’t even allow me to test my app to ensure it was working before I forked out the big bucks for the proper SSL certificate.

I had an idea, I have a code signing certificate from Thawte that is worth a pretty penny, surely it will at least allow me to test my app, if not be my solution. Strike 2. A Code-Signing certificate can only be used to sign code (JARs in my case), not for authentication – again, no real surprise.

So an SSL certificate was purchased from a company we have a good relationship with, so we got it for wholesale price and away we went… almost. Java’s Virtual Machine looks in a certain spot for trusted certificates, but unlike the major browsers, only has about 15 in there. Of course the certificate we bought was not one of them. Strike 3 – back to the drawing board. For anyone reading this because they are experiencing similar problems, use:

keystore –list –v –keystore %JAVA_HOME%/lib/security/cacerts

Password: changeit

to view the certificates that are in that cacerts file. This is the default file java will look in if you do not specify a trustStore property when calling your applet/application.

We found a certificate in here, were able to obtain a refund on the previous and now it was time to invoke methods remotely over secured sockets and love life… nearly.

The first test of this saw love. The problem was that test didn’t bring browsers into play. I ran the RMI Registry and the Server Implementation, downloaded the jar and ran it from the command line on my PC. Voila!

Hello World!

I was ecstatic. Until I ran the applet from the same jar and got an error telling me “bad certificate�. This didn’t make sense as the root CA of the certificate we were using was certainly in the browser (both Firefox and IE7). A bit of looking around the forums provided very few answers so I decided to post myself (I very rarely post on java forums as the answers to my questions are there if I look hard enough).

It turns out that the Root CA certificates in the browsers have a property that specifies what actions a certificate using that Root CA can perform. The certificate we were using was marked for Code Signing, Server Authentication, Email Authentication. Notice Client Authentication missing. *sigh*.

This was getting thoroughly annoying as I have now spent 3 weeks trying to test code that only took me a couple of days to fully merge with the older code.

I tried checking the Client Authentication box in the browser for out certificate provider, but this didn’t fool the browser for a second, and I was still denied. After a long chat with an RMI expert, it was concluded that it is not currently possible to enable client authentication in RMI using SSL in an applet. If the application is not running from a browser however, this works as it should. The reason is that when you use the browser, it looks for the certificate there rather than in the parameters specified by the applet.

The work around is buy one of the (I think) 2 certificates that support client authentication, though this is untested as we added security other ways and as such, didn’t purchase one of these certificates.

The applet is now running with SSL enabled using Remote Method Invocation. Hurrah!