The last couple of days, a company named DigiNotar was in the news for issueing fake SSL certificates. I don't need and want to go into details, but what was clear before, has now officially been proven big time: The whole trust concept of SSL certificates and with it a corner stone of http security does not work and thus is completely worthless. The sad thing is, that this is the only http/web security system supported on a large scale to this day.

Overall the concept of trusting a hand full of companies out of good will is just stupid. Each and every one of them is very susceptible to single hackers or small groups of hackers, not to mention foreign agencies and more importantly local agencies with proper funding or even a "legal" way to mess with certificates.

So, what is a solution that works? Learn from filesharing. To this day a lot of filesharing networks have been put down due to the SPOF nature they share with the CA companies. A single target which can compromise the whole network and system. What followed was decentralization - and with so many other systems (from network architecture over source code management and storage systems) that prove how good this works, this clearly is the way to go.

So what's out there to accomplish this? Sadly: nothing that works out-of-the-box and/or everywhere. But there are some concepts:

• Web Of Trust, closely related to GPG/PGP
• Convergence, a firefox plugin to allow a completely decentralized web of trust

Sadly, all of those come with some effort and are not available for every browser, let alone on every machine. I will evaluate these and probably other solutions in the next time, and report back.

Update: I forgot to mention this before: the whole situation is actuall that bad, that google decided to hard-code certificates (or probably their fingerprints) in Chrome, something Noscript apparently does, too. This is a horrible concept, but it seems the only way to make the CA system work as it is.

Of course, in the long run, it would mean, that every single certificate would have to be hard-coded in every single browser(engine) and every CA would have to be distrused. Certainly no system that is desirable.

While I was on vacation, my old vServer provider decided to inform me via a 2-liner that my vServer has been nuked. At first it was supposed to be only a short power outage, but a day later a mail came in, that all data is gone. This certainly wasn't the first time I doubted the ability of the provider to maintain his machines, so it finally pushed me to move on.

Anyway, while it might be overkill for me, I'm finally on real hardware (and OVH is ridiculously cheap) and while it isn't failsafe in any way, I'm much more comfortable by being able to maintain it myself completely.

As you can see, my old blog is also gone. I could have restored the backup, but I wanted to move from blogofile 0.7 to 0.8 for a while and never had the time and motivation to do so - so I decided to just restore my few posts and set up blogofile 0.8 with the simple-blog profile from scratch. I'm currently working on the templates and the CSS to make it look decent again, but this may take some time, as I plan to finally learn more cool CSS stuff (one of which I already started to implement, thanks to a hint from josch). It's really amazing what you can do with CSS nowadays, finally there is no more reason to do any design in html.

As everybody should know by now, Mozilla did a huge change in the their Firefox release policy. It is highly controversial, so I felt sharing my thoughts might help.

Until very recently Firefox had a very "old-school" versioning scheme: Major.Minor.Bugfix Bugfix-releases happened rather often, usually about once a month. Minor releases happened every few months, Major every few years. I don't need to explain what bugfix releases were for. Minor releases usually introduced minor new features like support for new web standards, minor UI changes, and bigger improvements on existing features. Major releases happened very rarely and usually introduced big UI overhauls, major feature additions and support of a bigger range of web-standards.

So what did this mean for support of actual websites and web-applications? I will tell you: Nothing. Besides adding support for new stuff, there hardly ever were any deprecations and regressions. If your website worked in 1.x, it probably worked just as well in 4.x because the standard didn't change. Maybe it looked a little worse because the standard changed a little, or the implementation behaved a little different.

Let's come to the new and current system, that's meant to stay, at least for a while: The new scheme is: Major.Bugfix It's generally more of a rolling-release cycle. Every new feature, no matter how small or big, is implemented in a new major version. These are released on a regular, scheduled, basis that targets on getting a defined set of features in and get it released in time. Bugfixes are applied between releases to keep the current release secure. Any new release will automatically deprecate the last one. There won't be bugfix-releases for old majors like there used to. So what did this mean for support of actual websites and web-applications? I will tell you: Nothing. What worked in the last Major, will work in the new Major - but not necessarily vice versa. If it doesn't, it's a bug. Web applications and websites may not be browser specific. We used to have that in the corporate world and everyone knows: it sucks, and it is wrong.

Enough with the explaining, let's go take the criticism on the model and describe why it is invalid:

• Websites/apps break with new Major releases

• No they don't. If anything, they were broken before

• Updating is more difficult

• No it isn't. Updating works the same way for new major releases as it did for old minor or major releases

• Addons break

• That's partially true: addons contain a version mask to indicate with what versions they were tested and should work. Until now addon developers usually set a wildcard like 4.* This kept addons working even after new minor releases. What you didn't know: minor releases could break the addon api, and make addons not work properly! Setting the wildcard makes it run on untested versions, so why not do it now, too? If it breaks it has to be fixed, that's how it used to be, that's how it will be. Also, there is a new addon-api for simple addons (named jetpack), which will remain more stable and keep a lot of the updating trouble away.

• Users will do fewer updates and not receive security updates

• Not true. Updating has been as intrusive as it is now, and there are always people who are not willing to update. Nothing's changed.

• Distributions will have a hard time updating

• No they won't. Every minor release had to be tested as intensive as every major has to, now. With big applications like Firefox, there has to be some trust in upstream, because it is impossible to do a full review and a full function test for new releases - major or minor - anyway.

• Companies will have a hard time keeping up

• Not true. As I already explained, web applications cannot be browser dependent. If they are, they are broken. Most of those company web applications are not actually web applications but horrible mutants only used internally. They never did actually run on Firefox and on any non-stoneage Microsoft browser. If they worked in Firefox, they will likely continue to do so. As with distributions, it is impossible to do a full review on any new major or minor version, so there is no impact at all.

• Companies won't be able to roll out a new release with the short cycle

• Not true. The reason it took companies ages to roll out new releases is because ancient versions were still in the support cycle. Companies are lazy, because lazy means less costs, so they won't change anything until forced to do so. The reason the web is partially in a really bad shape is, because IE6 is still supported, and 90% of companies have not yet moved on. And they won't as long it is supported. Rolling out new software is easy. There are people responsible for every web-application and they can easily test it to the necessary extent within the 6 week release cycle. It is trivial to make the software available via remote desktops, and there are builds in the beta and aurora channels available to make it really easy. Companies need to learn that they have to keep up, even though this breaks a very old (not to say ancient) habit.

Conclusion: It's time people, and companys, are getting real. The way and the pace the web develops today, there is no room for legacy. Chrome introduced the rolling-release strategy to the browser world, and apparently it works. With this (well, and a lot of marketing), it pulled a huge share of the Firefox market share (to remind you: IE users don't switch to Chrome, FF users do.), so apparently their strategy is valid. Until today firefox had trouble getting new standards supported. Not because the developers are too lazy or slow, solely due to their release politics with a over-a-year release cycle for new feature releases. It was time to act and they did. The reason why people don't adapt to new web standards and great things like WEBM isn't because Microsoft doesn't support it. For years and years nobody cared about Microsoft when it came to new cool things, because they are slow and don't support them anyways. Companies that use Firefox use it because it's not ancient, has cool features and people like it. They might still use IE for their broken apps, but their users hate it. While IE9 is very recent because even Microsoft moved to a new release strategy it's already pretty much outdated and will remain so, because Microsoft now does the old Mozilla strategy. New features come in new versions, but they make the horrible mistake to keep ancient-to-be versions, i.e. IE9 supported. By claiming to support IE9 for the next 8 years, the encourage companies to roll out broken web applications. They don't have to be standard compliant, but to work in IE9 (not in 6,7,8, not in 10, not in any other browser), and that's exactly what they will do. An interesting side effect is that tech companies will have to use 2 browsers again, because their customers expect nice standard compliant websites that work in their browser, and IE9 it won't be. So employes will have to use IE9 for intranet stuff and FF for their companys official websites/applications. And it will be FF, no matter if they release every 6 weeks or not - not IE10, or 11, because they need to keep it at 9.

So people, get real yourself. Be happy they did the change, be happy they don't support old versions and force you to use old websites and non-standards (like Flash), and be happy they force your distributor and your company to keep up, because you get a shiny, recent browser and a better web for it.

I usually don't like to do product reviews, but I find the following deserves one because of the misconceptions it is facing.

I recently bought Flea bike lights by Blackburn. In fact, I bought a set a while ago already, but I lost one of the lights. This is easier than I thought because those things are damn tiny, and I'm not even sure if I lost it on the bike or somewhere else.

As I was pretty happy with the devices, I decided to replace the missing one and got myself a new set; this time the 2011 edition in contrary to the 2009 I had before.

General

There are two main differences introduced in 2010 and 2011: The USB-Charger was introduced in 2010 and replaces the included battery-charger so you can recharge the lights on any 5V DC power supply over an USB port. New in 2011 is an additional led under the lights buttons that shows the charging state.

Here's a picture showing the new USB-Charger on the left and the old battery charger (that can be attached by magnets to any standard battery) on the right:

The chargers attach to the devices by 2 magnetic pins that are quite strong, so you can safely put it in any USB port without fearing it might fall off, and you can attach any battery without having to care if the contacts are attached right. What's really amazing however is, that the charging electronics is inside the lights housings so you can use any DC source from about 1 to 5 V without any additional electronics. It even allows to attach a solar panel with USB connector (Blackburn themselves offer one, but there's a ton of other similar devices on the market). With the 2011 edition the new colored LEDs indicate the battery status and also when charging is complete.

Attachment

Here's the complete set including straps and USB Charger:

As you can see on the pictures, the back-light has a clip that is not only used to attach it to one of the straps, you can also clip it to a belt or backpack which I find useful (great if you have a big backpack that might hide a light attached to the saddle, or if you're hiking without a bike at all). If you pull the strap tight enough, it works well and you can attach the light safely, and it stays in place.

The front light has no clip, only a rail for the strap. Here too, it has to pulled tight so the light keeps in place. It doesn't hold nearly as well as a proper hard mount, but due to the low center of gravity and the light weight it usually stays in place well enough.

Light

Every light has a couple of modes:

For the front light, it is normal, high, flashing, off, toggled through repeated pressing of the button. The back light has normal, flashing, chase and off.

The normal mode is usually good to be seen and to light the road if it's not totally dark. In the high setting it is surprisingly bright and well enough to see in total darkness. Of course it doesn't compare at all to 20 times as big, 40 times as heavy and 5 times as expensive lights with multi-Watt LEDs and so on, but it a) doesn't claim so and b) isn't made for that. I've seen a number of reviews and opinions that state that the Flea sucks, because it isn't as bright as their 200 EUR lamp with a 1 kg heavy battery pack - if you expect that, move along and get real. If you drive in darkness for several kilometers every day and don't want to charge twice a week, these lights aren't for you. If you bike for fun and need a pair of good, light and practical lights, or just a backup light, try the Flea.

I've made some photos in total darkness, no artificial light (besides the Flea) around, no moon and clouded sky without stars, to give you an impression how bright the lights are. The pictures are slightly overexposed, so they seem a little brighter than they actually are, but it still is close to how you actually would see it:

Conclusion

I guess people like pro/con lists (at least I do), so here it comes:

Pro

• Tiny
• Light
• Bright (for the size)
• Long battery life (for the size)
• Innovative charging concept

Con

• Not allowed as only lights (in Germany)
• No hard mount available
• A little bit on the pricey side

As usual, more pictures in my gallery.

Some days ago my Pandaboard finally arrived!

Currently Digikey is still the only reseller for it and it seems they are permanently out-of-stock since the Pandaboard is for sale. Anyway, over a month ago I decided to just order it, even though I don't really had enough time for it, because it seemed it could take some months.

Anyway, now it is here, as usually deliveded by FedEx in the blink of an eye. They did not even charge the usual import fees (EUSt) - it probably did not actually go through customs as a development kit.

As everyone seems to do unpacking pictures, videos and so on, I don't bother, but there are some nice pictures of the device in my gallery.

Anyway, it comes in a box and is very lonely because there is nothing else in it (what is good!).

You just need a 5V powersupply to get it running - according to the wiki it should even be possible to get power over the mini-USB port, though I haven't tried that yet.