You're using IE. Scroll down.
home :: tech

So Long, and thanks for all the Tech

The news of Steve’s death were expected but still came as a shock for everybody. Like if the guy was holding on for one last product launch.

Lots of people wrote extensive, thoughtful and well written eulogies. I will just remark what most impressed me about Steve Jobs, he was a master of simplicity. Simplicity is hard, everyone who tries to write software knows this. For me simplicity is really hard, I’m a crufter so seeing someone churn out products by removing, not adding, features is like magic.

Steve came back from NeXT to Apple, brought UNIX and built an aesthetic and simple UI around it. Then he did the same to the mp3 player and to the smart phone. My first analysis of the iPhone was focused on what it lacked, not what it had. It sounded pretty foolish as soon as iPhones started filtering into people’s hands and it became obvious it wasn’t missing anything. Everything that couldn’t be made perfect was removed. Deliberately. That kind of focus and courage is unique.

/tech | edited on 2011/10/06 -- permalink, click to comment

Programing for Nokia

  • 2007: Symbian is great, you should all be using our awesome C++ API and our awesome IDE!
  • 2008: Maemo is the future! We don’t like the Gtk+ C APIs but we don’t know what we’re gonna do. We hear Flash Lite is great!
  • 2009: Maemo6 is going to be awesome! And it’s all Qt C++!
  • 2010: Did we say Maemo6 ? We obviously meant Meego! Excellent news, common UI Qt API in Meego and Symbian!
  • 2011: Windows Phone is totally awesome so we’re going with that! Symbian is going to die. Qt what ? No, you’re totally going Microsoft now.

This latest jump shouldn’t bother anyone as anyone with a shred of sense has given up hope 2 years ago.

/tech | edited on 2011/02/13 -- permalink, click to comment

What Should Nokia Do ?

Tomorrow Nokia will probably announce their demise. So I’ll write here what Nokia should actually have done. Two years ago at least.

  • Put Symbian on life support. This is a no brainer but life support in Nokia context will probably mean a 1000 headcount considering all the legacy to support.

  • No more S40. All devices under 150EUR come with Symbian^2. We all say Symbian is crap but it’s still a lot better than anything else in featurephone space.

  • Don’t do 100 phones at a time. Nobody needs to choose from 30 models in a given range. Focus on a much smaller number and do them well. Nokia knows how to, technically, build good phones. But it fails at building compelling phones.

  • And finally, get the Maemo/MeeGo team on top. They seem to be the only team capable of delivering in interesting product in the last 2 years, even against the rest of the company. And then make them integrate Android for everything from midrange to highend. And meanwhile make them do a MeeGo tablet.

But this is not what Nokia will do.

/tech | edited on 2011/02/10 -- permalink, click to comment

FinalWebPro

Apple is probably working on a pro HTML authoring tool. Lets review the recent events:

  • Apple keeps Flash out of iOS;
  • Apple removes Flash from the Lion install, whoever wants it needs to get it from Adobe;
  • iWeb is missing from the iLife11 announcement while mail templates are demonstrated from something that felt like 1 hour.

So my take on this is the Web team is hard at work on a HTML5+JS pro authoring tool to obsolete Adobe Flash. In fact, all Apple needs to declare full out war on Adobe is to throw in a decent Photoshop replacement.

And lo and behold, between writing and publishing time Adobe concedes defeat and announces a flash-to-html tool. Flash is now irrelevant.

/tech | edited on 2010/10/30 -- permalink, click to comment

The iPad use case

A number of people asked me if I’m in line for an iPad. The short answer is, I’m not. I lack a clear use case for it and that kind of money can buy my kids some nice holidays. But the iPad is a beautiful machine. It looks like something out of the future and while I haven’t held one yet I’m pretty sure it feels like that too. Somewhat like the guy who designed the first flipphone cause he wanted a Star Trek tricorder, but totally better.

I don’t have a use case for the iPad but then again I’m not the typical user. We already have a netbook on the couch the wife uses for Facebook games (which, for the time being, is about the only reason Flash is important on something) so that’s covered. I myself have been, as of late, living on my N900 and while sometimes annoying for lack of horsepower (and little Maemo5 snafus) it has been rendering my workstation more and more as the thing I use to do development and gaming on. The N900 is a proper computer and fits in my pocket which are two very important requirements for me. The 98% of the population who isn’t like me will use the iPad exactly as I use the N900 and for them it will slowly and steadily become their personal machine. So, to the people saying the iPad isn’t a real computer and won’t catch on cause it’s neither a PMP nor a notebook I say poo poo. That’s a weak argument if I ever heard one.

Meanwhile, iPhoneOS 4.0 has came out which will bring, among other things, proto-multitasking to the iPad enabling IM, music player and VoIP. Next year an iPad2 will surely come out with a front facing camera, iChat and Skype videocall. If everything goes according to Apple’s plan, Flash will be a memory like Java applets are now and the iPad will be the personal device.
Speaking of Apple’s plan, the iPhoneOS4.0 SDK basically kills the upcoming Adobe Flash iPhone cross development GUI app. That gotta sting, not only Adobe but also all the Flash developers who were planing to code the next iFart in Flash and become millionaires. They’ve become upset and trash talked Apple and I wouldn’t be surprised if a lost profit class-action suit cropped up (please oh please do, that would be so entertaining). My take on the whole thing is, iPod/iPhone/iPad is a closed system, Apple never made representations otherwise and if you want to make money off it you listen to Apple and play by Apple rules. Don’t like them ? Pack up, leave and develop for Android which is an open system or buckle down and learn Objective-C/Cocoa. Either way, shut up.

/tech | edited on 2010/04/11 -- permalink, click to comment

The XNA Javaness

Microsoft is very excited about unified development for PC, XBOX and Mobile. They’re talking about the exact same game, with minor adjustments, on all 3 platforms. Most people can see some kind of fault with that reasoning. They can’t.

One size fits all tends to end up with whatever the worst platform can handle. This kind of works from XBOX and PC, with the XBOX being a crappy PC and PC developers being used to develop for crappy PCs. It doesn’t exactly work cause controls on a PC are much richer than on an XBOX. And console games are simpled down versions os PC games anyway.
But let’s face it, a Snapdragon mobile phone isn’t exactly a crappy PC. It’s not even a PC, it’s just a low power CPU with lowend 3D graphics. You’ll end up playing on your 2000USD PC a game your phone can render.

What works is having, not versions, but aspects of the game. You play some parts on the XBOX or the PC and some parts on the mobile. Example, on an adventure game you play some wicked 3D combats on XBOX and do your adventuring on the mobile taking advantage of all the nice things a mobile has, such as a touch screen and mobility. This isn’t rocket science, Nintendo did this with Zelda on Gamecube+GBA (expect the cable made it awkward), and in the end what you need for a compelling game is making the best experience possible all around, not go easy on the developers.

/tech | edited on 2010/03/10 -- permalink, click to comment

The Microsoft Vapourization

One of the reasons Microsoft is on the way down is they gave up on shipping products. The last few things that made a blip don’t actually exist. Let’s review. There’s Surface which never could make it as a product, there’s project Natal which was announced 18 months ago for 4 months ago, Windows Phone 7 Series which will exist in real hardware at best, next Christmas and now Courier which they promise will be really awesome if it ever exists.

I can imagine Ballmer standing before the Board going “We’re going to make a killing next Christmas, just you wait. We have this really really amazing stuff just about ready to come out”.

/tech | edited on 2010/03/08 -- permalink, click to comment

The Pin&Chip frakup

Recently researchers at Cambridge examined the protocol between EMV banking chip cards and point of sale terminals and demonstrated an attack against the system where they make a payment without inputing the correct pin. This attack is trivial. I’m not talking about the research which is not only interesting but complex in nature. What I’m saying is, the system is fundamentally flawed and so trivial attacks are possible. I’m not exaggerating, a computer science undergrad could have come up with a better system. He wouldn’t even have to think too hard. He’d just need to copy it from a textbook.

The press always makes this things more spectacular than they actually are so to back up my claims we’re going to design a point of sale payment system and see what we can come up with. We’ll start with the chip in the card. This is small processor that’s designed to do cryptographic operations and hold secret information. This chips have been in use for a few years and are effective. Effective here means unless you’ve stollen Bill Gates’ card chances are you’ll steal less money than it would cost you to attack the card itself. Also, given people notice cards are missing odds are the card will be revoked before you get results from an attack on the chip. So, for this purpose, we’ll consider the chip effective. Unfortunately, as far as I know, most cards issued to this date are issue with ineffective chips and are similar to the old magnetic strip cards. We’ll ignore those and design for effective chips.

The chip knows 2 things, one is your pin to authenticate you and the other is a secret to authenticate itself with the bank. When the chip is reasonably convinced the person using the card is who he claims to be, through providing the correct pin, it will use its own secret to create a command the point of sale can send to the bank. The bank in turn will look at the command it received, verify it was generated by the correct chip after seeing the correct pin (through the secret the chip shares with the bank) and if it’s convinced the operation is legitimate execute the payment command.
So to get this thing going we only need an operation between the point of sale and the chip. The point of sale provides the inputed pin and the transaction to the chip. If the pin checks out the chip encodes the transaction so that the point of sale can send it to the bank. It the pin is wrong the chip returns an error to the point of sale and it gets displayed to the user. This system is far from the perfect, the user must trust the point of sale won’t steal his pin (which can be used with the stolen card). The user must also trust the point of sale will ask the chip to encode the correct transaction and not some other debit. But the bank can trust the chip saw the right pin and making a better system would involve a slower system and a more complex and expensive chip. This of course is not the end of the story, the system needs to be properly engineered to ensure it’s trustworthy. The devil is usually in details like making sure the transactions are not repeatable (so that a malicious point of sale can’t just reissue the same transaction over and over) or that a stolen card will lock itself up after a number of attempts.

Now that we designed a working system lets look at how the actual system works. The Cambridge researchers found the system has not one but two separate operations, validate pin and encode the command (actually, there’s a lot more around this but the essence of the system can be described this way). The points of sale don’t have a validate pin operation so this doesn’t seem to make much sense, the separation comes from the huge amount of complexity existing in the EMV system. So lets try to design a system as secure as our original one but with this extra constraint (such is the life of an engineer). We’d have to relink the two operations making the command encoding depend on the pin verification. This is done by having the chip give a random number, called a token, to the point of sale when it validates the pin. The point of sale in turn passes this token back to the chip along with the transaction it needs encoded. The chip confirms the token is valid and encodes the command for the transaction, guaranteeing the pin was correctly entered. This is heavier on the chip but is nearly as secure as our method (some design flaws on the chip might make this method weaker). Now lets look at how the EMV system actually works. On their system the validate pin operation doesn’t return a token. It just says yes or no and then the point of sale decides how to proceed. As the observant reader probably realized we just placed a lot of trust on the point of sale, the trusted chip is no longer master of our pin but must instead rely on the point of sale doing the right thing (which might be go to signature authentication). An obvious attack is having a point of sale that doesn’t do the right thing. It might go ahead with the transaction when a wrong pin pin is entered or delay printing the receipt a bit and issue a few extra transactions. But there’s another weak link on the system, the point of sale to chip communication goes through an unsafe interface, the chip contacts and point of sale reader. That’s what the researchers attacked, they inserted a device between the card and the point of sale that always reported “pin ok” coming from the chip (I won’t go into details about how to do this, it’s not trivial but it’s not very hard either). This type of attack wouldn’t even exist in our initial system. On our modified two operation system the attack wouldn’t work cause the attacker can’t just inject a known reply into the stream. In fact, it would only be possible to attack the chip-point of sale interface if the chip had a design flaw on the verification of the tokens. In all truth the EVM system does include some safeguards designed not to prevent but to report this kind of inconsistency. However this safeguards are so poorly designed and implemented they are not effective.

So by employing advanced cryptographic chip technology EMV ended up with something worse than the decades old magnetic strip cards. The problem with magnetic strips is they are easily copiable so someone using a “skimmer” that reads the card and intercepts the pin (recently some skimmers where found attached to ATMs and physically tampering a point of sale terminal to skim card is fairly easy) can easily create a duplicate of the skimmed card and then use it together with the skimmed pin. As mentioned before most currently used chip cards employ simple chips and are as easy to duplicate as magnetic strips. That together with the attack above make them less secure than strip cards. Newer Pin and chip cards can’t be skimmed but on the other hand a robber can use just the card without bothering with the pin. There’s even deeper problems with this system caused by having the two separate operations. The ability to coax the card into generating encoded commands allows someone with access to a large stack of cards (stolen, old discarded or blank unissued) to run something called a plain text attack. The attacker generates large quantities of encoded text from known plain text and then analyses the encoded text to try to derive knowledge about the encoding system. A successful attack may, depending on how well the system is engineered, compromise the whole system an allow havoc like easy card cloning.

Congratulations. If you read through the article and were able to follow you are now better at designing payment card systems than EMV. This kind of absurd failures are usually the result of committee design and pressures from manufacturers to make the system cheaper to build or less interoperable so that it generates vendor lock-in. In this case there was also no effective independent review, a key element in successful design of security systems. Sadly, the specification seems to cover so many usage possibilities and provides such latitude to proprietary implementations of key features by individual banks it would would be impossible to review. More distressing even is the EMV was probably never meant to be secure. It was meant to be marketed as secure to stop credit card signature fraud claims from stores. And it’s arcane enough to thwart any attempt to prove pin fraud so the end user is stuck with the cost of the frauds. In fact, the researchers claim to have been contacted by a number of pin fraud victims where the banks and EMV just claimed misuse of the card and never even investigated on grounds of the system being secure. Considering the simplicity of the attack I’m sure a number of criminal rings, who actually put resources into cracking this kind of systems, have known about this for quite some time. I’m also sure the laws the media and make-believe-security industries are trying to push to the effect of banning security research would also prevent us, the public, to ever know about this gapping flaws.

Looking forward, the researchers list some ways the system could be improved but are hard to implement in practice cause it would mean changing a number of existing systems. There’s another way which sheds signature verification altogether, making cards only create a valid transaction within a reasonable time after a successful pin authentication is performed. This would make the chip a bit more complex and more expensive so I’m sure the banks would never switch to this type of cards. After all, they already managed to shift the liability to the end user so why bother with actually protecting their customers ? Easy, market the cards that actually work bundled with a fraud insurance and obviously, an extra monthly fee.

/tech | edited on 2010/02/14 -- permalink, click to comment

About Flash on small devices

Adobe is obviously annoyed at the “no flash here” broken plugin icons on the iPad. And people are pointing out Flash is a huge, bloated, crashy pig on the desktop.

Guess what, Flash is a huge, bloated, crashy pig on mobile too! My N900 has flash 9.0. It can play YouTube. But most of the time, guess what, I avoid it. I know you’re trying Adobe but the experience is just pain, pain, pain and then more pain.
And to sum it up the single greatest improvement in Fennec 1.0RC3 over RC2 was disabling Flash by default. And guess what, it got snappier.

Yeah, my N900 has Flash but for some reason the first extension I installed was AdBlock …

/tech | edited on 2010/01/29 -- permalink, click to comment

The iPad in evil review

Everybody’s calmer and most of the giddiness has passed so now it’s time for the evil review.

  • The UI is lukewarm. Everybody was expecting something new and brilliant in terms of interface. Turns out it’s a huge iPod. Same homescreen and all. And the onscreen keyboard is a dream to type on ? Really ? Didn’t hear anything about haptic feedback so it looks a lot like drumming your fingers on a glass table. And it basically fails for one hand input. Decent enough to type a quick email ? Sure. Dream to type on ? I’m sure Jobs had to force this words out of his mouth.

  • Did it have to be microsim ? Everybody else does really well with “regular” sims, even the people doing tiny phones. Were those extra couple of cubic mm really needed for something else ? The truth is obviously no, that tiny extra space could be sacrificed for compatibility. The real reason is appeasing the carriers. It’s unlocked, but they can control the deployment on their network by supplying (or not) the microsims. And since nothing else uses the microsims they’re also a price point tool, carriers can create special iPad packages, cheaper or premium. Yesterday I wrote I’d probably get the 3G version. That was obviously a mistake. Not with microsims and $130 premium, there’s a wonderful world of Joikuspots out there that manage to bridge that gap.

  • No DisplayPort ? No USB. For something that’s supposed to be nearer a computer than an iPod the connectivity looks pretty ipodish. And most of all, no front facing camera ? Just imagine Steve doing iChat AV on stage with the Pad, that would’ve blown everybody away. I’m also told college kids really like videochating hotties. Forcing people to see my ugly mug isn’t high on my list but it will probably hurt on the college market next September.

  • This thing has iPhone 3-year plan written all over it. It’s not like I can see into the future but I can see a 3rd gen iPad a couple of years from now with front facing camera and USB and regular sim slot. This isn’t exactly a cheap toy so people might just hold out for the next model, the one that’s really great.

  • And the elephant in the room is, this isn’t 3 years ago. 3 years ago the iPad would reign supreme and the closest “competition” would be from an HTC or HP “slate” running Vista (Intel, 2h of battery) or WinMo5 (350MHz ARM, 4h of battery) and it would be utterly irrelevant. Now, however, I’d be holding out for the snapdragon powered Android “pad” someone (my money is on Asus) someone is going to release in the not so distant future. It won’t be aluminum, the screen won’t be as stunning and it probably won’t be glass. But it will have a front facing camera, it will have have USB and 3G people can actually use. And it will be in the same class as the iPad.

/tech | edited on 2010/01/28 -- permalink, click to comment
blog comments powered by Disqus
Archive: