A month ago, my blog was hijacked by spammers for a few days

About a month ago (just before my vacation), several people notified me, that my blog has been hijacked by spammers. Wassim Melhem even created a bugzilla entry (which was a great idea!).

Spammers replaced my blog with their stuff including a new pink layout. If you want to see it: scharf.gr/hijacked_blog (I don't link it from here, but you can paste the link into your browser).

Google/blogger.com recognized that my blog was spam and they locked my account (I was still able log in but I could not add new blog entries). All my old bog entries were gone. I send some mail to Google and after a day or so they restored my old blog and apologized.

But how could they get into my blog? I don't think they were able to guess my username/password, because it was pretty safe. Else I guess, they would have changed my password. Looking at the spam blog, I just realized that the same content is there two times (looks like pasting it two times). I think, they just replaced the entire blog template with their crap. I see two possibilities how they could have done it:

• They hacked into the blogger server and did it from inside. In this case other blogs would have been hijacked too.
  
• They used some clever javascript that navigated to my blogger template site and they dumped their stuff. Because my blogger account is my google account and I was lazy logging out, a script could possibly have done that. Changing the template is much simpler than creating a new blog entry, because there is no "enter the text from the scrambled image" type of verification needed.

Do you have other theories how this could happen?

There is a interesting new type of spammer attack: they use pieces of real blogs in their spam blogs to make their spam blog appear "real". Marko Schulz has sent me a link, but that spam blog is fortunately gone....

Talking about spam: since a week I get much less e-mail spam (on some of my accounts) than I used to get (tens instead of hundreds per day). Maybe spammers started thinking about spam efficiency: to get most out of their spam bot nets they concentrate on Internet newbies. Therefore it pays off for them to eliminate e-mails that are in their lists for years. The probability that someone who is new to the Internet believes the spam is much higher than for experienced users. If they would mostly attack new e-mail addresses, they would also get out of focus of the experts who are fighting spam and therefore have a much higher success rate in delivering spam. In addition, if spam is sent in low volume, spam defense would probably miss new variations of spam. Or is there another explanation for this decease in spam?

Eclipse is worse than any commercial IDE (in an ideal world)...

At his keynote at EclipseCon 2007, Robert Lefkowitz made the following provocative statement: "Eclipse is probably worse than any commercial IDE!". Why? Because it's free! In an ideal (capitalistic!?) world you don't pay for anything that you can get for free. Any tool that is worse than a free tool would just run out of business (if both tools would cover the same market). Well, and we have seen quite some commercial IDEs die, since eclipse is available.

One implication of this observation is, that when eclipse increases it's quality, competing commercial products have to increase their quality to survive. But wait! Instead of improving the quality of your commercial product, you could just prevent eclipse from become better. I know, this is very provocative. Fortunately, making (and saving) money is not the only force in our world. And fortunately, the way eclipse is organized, this will not happen:

Although, most of the work on eclipse is sponsored by companies that sell products based on eclipse, the work is done by individual committers. And the human factor is very important. Everybody can see what committers do. It's not anonymous hackers that do the work, because unlike wikipedia, anonymous users cannot change eclipse. Eclipse is a social community with a focus on individual responsible committers. This is very important for the survival of eclipse. That's why new committers have to be voted into protects after they have shown credibility. That's why new projects must have committers from multiple companies. Eclipse committers are humans with emotions. Nobody wants to be accused of being destructive.

It is an honor to be an eclipse committer.

My favorite 3.3 feature: Quick Access

I just looked into Eclipse 3.3 - New and Noteworthy. Lots of cool new things! My favourite is Quick Access. This essentially allows you to type commands instead searching the command in the menus. If you have customized your perspective, to get rid of annoying tool-bar buttons, you still have access to commands that are not visible in any menu or tool-bar!

I have bound Quick Access to ESC-X (like in emacs) and it feels a bit like the emacs minibuffer.... Very cool!

BTW: I wish eclipse would allow links into the "News and Noteworthy" pages (see bug 194993), that's why I created my own copy of "News and Noteworthy"...

I don't like XML! But what are the alternatives?

I think XML is one of the worst formats for data. It is extremely ambiguous. There are so many ways to put a simple data structure into XML. For example:

<book 
    title="The Return of the King"
    author="J.R.R. Tolkien"/>

or

<book>
  <title>The Return of the King</title>
  <author>J.R.R. Tolkien</author>
</book>

And in the second case, can there be more than one author? And more titles?

XML is not self describing. Look at the XML below. It is very ambiguous (if you don't use one of the many schema descriptions (DTD, XML-Schema, XMI, DSD, ...)).

<data
 x="null"
 y="true"
 z="42">
 <a>NULL<a/>
 <a>false<a/>
 <b>TRUE<b/>
</data>

What is a String? What is Boolean? What is a number? Is x a list? You simply can't infer it from the XML. When you want to write the data, which fields are written as tags which are written as attributes?

There is also a huge problem with IDs and references. From a plain XML file there's no way to figure out what an id of an object is and what references are. A good example are plugin.xml files. They are full of IDs and references but it is so hard to know which string refers which other XML element. Control-click does not work. Why? Because references are difficult to resolve!

Are there any good alternatives?

JSON is much simpler, self-describing, less verbose and much better suited for data storage and exchange. But it has no notion of IDs and references. And it does not name object (record) types (it has only lists, maps, strings, numbers and boolean).

What else is out there? I want something like JSON + an ID/Reference model + named Records...

Customize Perspective is annoyingly inflexible...

I just read Kims post about removing removing the default visibility of the menu and toolbar Working Set items. It triggered once again one thing that annoys me from time to time, the inflexibility of the Customize Perspective dialog:


You can either enable both, Menubar and Toolbar items or nothing. That is very annoying, because it breaks the principle that the toolbar items are optional. Unless the provider of the actionSet defines two action sets, one for the toolbar and one for the menubar, you have the choice between all or nothing.... But providing two action sets would duplicate the number of item on the command tab, which is already overloaded.

I think it is not the responsibility of the plugin writer to decide which items the user wants to see in the toolbar! (See bug 182714)

Surprises in eclipse 3.3: double click instead of single click

Since some time, the 3.3 patch editor (Team->Apply patch...) does not work for me anymore. Well, I was using patched milestones (we had some enhancements for the patch editor in our product). So, I was not surprised that it did not 100% work. What went wrong? If I select a file to patch, nothing is shown in the compare area below:

Since the problem remained even with an unpatched 3.3m7, I filed bug 186481 and after some discussions, it turned out that I have to double click instead of single click to select the patch. That was not obvious to me! In 3.2 a single click was enough! After double clicking the patch it looks like this:

Now I see exactly what I expected! But why double click? Well, because calculating the diff is expensive and doing that by simply selecting a file may not be a good idea... Another reason is that there's now a context menu on the items in the "Patch Contents" pane and you don't want to do the expensive calculation of the diff just to get to the context menu. Therefore, the paradigm changed from master-detail to open semantics.

But this is not without drawbacks! First of all, I'm sure I'm not the only one stumbling over this problem. Actually the semantics has changed in other compare related views too. If you set Preferences...->General->Single Click, you get the old master-detail behaviour.

Second drawback, is that the selection and what you see easily may get out of sync. Look at this screenshot:

What happened? I have selected (not double clicked) the plugin.properties file but the difference of a java file is shown. The bad thing is there is no indication which java files is shown here! Unfortunately it's too late in the game to change this (see bug 186481 for further details)...

Take-home message: Report bugs early enough....

No real support for dynamic extensions (aka dynamic plugin.xml)

Eclipse allows (theoretically) to add extensions dynamically (see "Leave Eclipse plug-in headaches behind" or "Contributing items to a toolbar dynamically"). Unfortunately, there's no way a normal plugin can do this without using internal classes :-(. Here's the proposed hack how to do it:

  IExtensionRegistry reg = RegistryFactory.getRegistry();
  // ExtensionRegistry is internal!!!!
  Object key = ((ExtensionRegistry) reg).getTemporaryUserToken();
  Bundle bundle = Activator.getDefault().getBundle();
  IContributor contributor = ContributorFactoryOSGi.createContributor(bundle);
  try {
   //  I have the content of my dynamic plugin in a file 
   // called dynamicplugin.xml
   InputStream is = FileLocator.openStream(bundle,new Path("dynamicplugin.xml"), false);
   reg.addContribution(is, contributor, false, null, null, key);
  } catch (IOException e) {
  }

Unfortunately ExtensionRegistry is an internal class and getTemporaryUserToken() is not exposed in any official way. Bug 112954 asks for a way to get to getTemporaryUserToken(). The solution is to use null as the key (token). Well, almost. In order to make this work, the system property eclipse.registry.nulltoken has to be set to true (Bug 112954 comment 25). But a normal plugin cannot set a system property before OSGi starts....

This effectively means: there is no way a normal well behaving plugin can provide a dynamic extension. Therefore I filed bug 174967 to fix that problem....