Category Archives: Javascript

How to know when Chrome console is open

tl;dr;

Although it’s not supposed to be supported – it’s possible to know whether the Chrome console is opened or not.
Check it out.

Reddit discussion.


Ever wondered if it’s possible to tell whether the browser’s Development-Tools are opened or not. Apparently it’s not possible in Chrome. And that’s a good thing, it’s no website business to know when I inspect their code.

The thing is… it is possible to tell.

When you run console commands it runs slower when the console is opened. That’s it. You simply run console.log and console.clear a few times and if it’s slower – than the console is open.

With this hack you can find out pretty reliably when the console is open and when it is closed.

Frankly, I don’t see how this can be mitigated without harming the performance of the browser. When the console is opened it has to be slower. Hence this hack will most likely continue to work. And I assume it’ll work similarly on other browsers and with other consoles.

Although others will claim otherwise, the only way I see this hack being used legitimately is by geeks to impress their peers.
Other than that the only valid reasons that I can think of are malicious, but I’m not gonna tell you how ;)


Making it perfectly accurate

In the demo I’ve used a benchmark ratio of 1.6 to determine if the console is open or not. In a perfect implementation the ratio will be dynamic and will change between environments.

Currently if a user will open the page with the console already opened it’ll be detected only after the user will close it at least once.

It’ll be possible to create another independent benchmark to tell whether the console was opened when the page first loaded.

Demo is here

To Listen Without Consent – Abusing the HTML5 Speech

tl;dr;
I found a bug in Google Chrome that allows an attacker to listen on the user speech without any consent from the user and without any indication. Even blocking any access to the microphone under chrome://settings/content will not remedy this flaw.

Try the live demo… (Designed for Mac  though it will work similarly on any other OS)

Watch the video…


The Sisyphus of computer science

Speech recognition is like the Sisyphus of computer science. We came a long way but still haven’t reached the top of that hill. With all that crunching power and sophisticated algorithms, computers still can’t recognise some basic words and sentences, the kinds that the average human digest without breaking a sweat. This is still one of the areas that humans easily win over computers. Savor these wins, as it will not last much longer;)

One must appreciate Google for pushing this area forward and introducing speech recognition into the Chrome browser. The current level of speech support in Chrome allows us to create application and websites that are completely controlled form speech. It open vast possibilities – form general improved accessibility to email dictation and even games.

The current speech API is pretty decent. It works by sending the audio to Google’s servers and returns the recognised text. The fact that it sends the audio to Google has some benefits, but from applicative point of view it will always suffer from latency and will not work offline. I believe that the current speech support was introduced with Chrome 25. From Chrome 33 one can also use Speech Synthesis API. – Amazing!

But…
Before this fine API we currently have, Google experimented with an earlier version of the API. It works quite the same, the main difference is that the older API doesn’t work continuously and needs to start after every sentence. Still, it’s powerful enough and it has some flaws that enable it to be abused. I believe this API was introduced with Chrome 11 and I have a good reason to believe it was flawed since than.


More Technical Details

Basically, this attack is abusing Chrome’s old speech API, the -x-webkit-speech feature.
What enable this attack are these 3 issues:

  1. The speech element visibility can be altered to any size and opacity, and still stay fully functional.
  2. The speech element can be made to take over all clicks on the page while staying completely invisible. (No need to mess with z-indexes)
  3. The indication box (shows you that you’re being recorded) can be obfuscated and/or be rendered outside of the screen.

The  POC is designed to work on Chrome for Mac, but, the same attack can be conducted to work on any Chrome on any OS.

This POC is using the full-screen mode to make it easier to hide the “indication box” outside of the screen.
It is not mandatory to use the HTML5 full-screen; it’s just easier for this demo.

As you can see in the demo and video there is absolutely no indication that anything is going-on. There are no other windows or tabs, and no some kind of hidden popup or pop-under.
The user will never know this website is eavesdropping.

In Chrome all one need in order to access the user’s speech is to use this line of HTML5 code:
<input -x-webkit-speech />

That’s all; there will be no fancy confirmation screens. When the user clicks on that little grey microphone he will be recorded. The user will see the “indication box” telling him to “Speak now” but that can be pushed out of the screen and / or obfuscated.

That is enough in order to listen to the user speech without any consent and without giving him any indication. The other bugs just make it easier but are not mandatory.

(For the tree in the demo I have used a slightly altered version of the beautiful canvas tree from Kenneth Jorgensen)

— The bug was reported to Google.

grey_mic

The Pains and Remedies of Android HTML5

Prologue: I’ve written most of this post some months ago and somehow didn’t publish it. Looking at it now, it’s a good reminder of some of the pains I already forgotten. The Android version statistics already changed a bit by now, but, still today and even with the new type of measuring by Google – the most problematic Andorid versions which are 2.2.x – 4.0.x are still running more than 50% of Androids out there. Hence everything here still applies. (note that most of the bugs are in 4.0.x and not in 4.1.x and above).
I’ve updated all the stats in the article to reflect the latest published stats.

These issues refer to HTML5 content running inside the native Android browser as well as  inside the native WebView (i.e. PhoneGap and alike)

———————————–

The promise of HTML5 is great, to be able to use the same code base on all clients and even on the server is really compelling.  While iOS has provided what it promise long time ago already – you can relatively easily create compelling HTML5 apps that will run on the iOS. Android HTML5 capabilities are still lagging far behind.

On paper Android 4.0.x (20.6%) was enhanced with many awaited features of HTML5. Similar to iOS 5. For example, Android 4.0.x was added with the important overflow:scroll, but, the Android 4.0 version is flawed. It has many other great features which are, sadly, mostly buggy. In fact this version is a buggy regression to the Android browser and WebView HTML5 capabilities.

It gets much better in Android 4.1, but this version still only holds only (36.5%) of Androids (48.6% including 4.2 & 4.3). Still today the most common version is 2.3.x which holds (44%) and that version can not be avoided. Generally, if you’ll try to push the HTML5 envelop of the Android it’ll probably push you back.

Even with the new and optimistic way of Google to measure Android versions distribution it’s still clear that 2.2.x and 2.3.x and 4.0.x are still massively out there and needs to be supported.

Having said all that, it doesn’t mean you can’t create decent apps with HTML5 that will run properly on the Android. But you’ll have to consider its lacking abilities from the get go. Design the UI as simple as possible, without too many fancy CSS, images, and animations.

I will put here a list of some of the issues I had to go through while adopting HTML5 on the Android, I will keep this list updated.

Canvas:
Pain:
 Android 4.1 – 4.3 render duplicated HTML5 Canvas
Remedy: None of the parents HTML elements to the canvas should have overflow: hidden or overflow:scroll

Pain: In all Androids and especially 4.x canvas drawing performance are extremely reduced by using canvas effects like shadowColor.
Remedy: Try pre-rendering or adding the effects only when needed and/or once in every drawing cycles. For example, in a live drawing app – adding the effects only when the user stops to draw.

Network:
Pain: Android 2.x.x Making PUT (protocol) requests with no body will have no Content-Length header, it’s rejected by some servers/proxies i.e. NGNIX
Remedy: Configure NGNIX to accept it or send a {dummy: ‘data’} in the payload. i.e. $.ajax(‘PUT’, url, {dummy: ‘1’});

Pain: Android 2.x.x PUT (protocol) is cached on some versions of Android
Remedy: Cache-bust it, cache-bust all requests to the server even if it’s PUT.

Content:
Pain: Box-scroll was introduced in Android 4.0.x  but it has numerous issue on that version.
Remedy: Don’t use box-scroll for anything under than 4.1, or use iScroll or similar. The best, most performant, solution is to use postion:fixed for headers and footer and to simulate box-scroll.

Pain: CSS pseudo :active selector is not working on 2.x, working badly on 4.0.x.
Remedy: It is only perfect from Android 4.1 and above, try to use your own implementation using touch events.

Pain: Making fixed content (position: fixed) issues on 2.x.x
Remedy: Works fine only  when the ViewPort is not resizable, use this in the html head:
<meta name=”viewport” content=”width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no” />

Pain: Scrollbars shows over fixed content.
Reedy: When using a native shell, scrollbars can be removed using
webView.setVerticalScrollBarEnabled(false);
webView.setHorizontalScrollBarEnabled(false;

Pain: Jumpy text inputs
Remedy (native shell): <activity android:windowSoftInputMode=”adjustNothing” />
Remedy 2 : don’t use *{ -webkit-backface-visibility: hidden} or try to override it with *{ -webkit-backface-visibility:visible !important; }

Pain: Styling text-inputs that has focus
Remedy: http://stackoverflow.com/a/9464837/275333, http://java-cerise.blogspot.co.nz/2011/10/dodgy-double-input-fields-on-android.html

Pain: Android 4.0.x, any tap implementation will not be responsive enough, it will miss a lot of taps. (works fine with all other versions)
Remedy: Essiest will be to revert to clicks on this buggy 4.0.x version

Pain: In Android 4.0.x long press is selecting text, on all other OSs it’s resolved with the css *{ -webkit-touch-callout: none; }
Remedy (native shell): Use this Java snippet http://stackoverflow.com/a/11872686/275333

Pain: Duplicated Input fields on Android 4.0.x. it happens because android uses another native input for fast typing response, it doesn’t work well with scrollable content. (very ugly hack google, if I may)
There are tones of hacks for that out there, most of it doesn’t work or at least doesn’t work good across devices.
Remedy (native shell): If you run in WebView – Don’t put text inputs inside a scrollable iframe or content with overflow:scroll. Putting this in the activity will auto scroll to the text-input (similar to iOS) android:windowSoftInputMode=”adjustPan” – only works on Android 4.0.x, not working on Android 4.1 and above (yeah really).
adjustResize is working on all Androids I’ve tested, but that is less pretty and leads to jumpy inputs on older androids 2.x. adjustResize needs to be on the tags in order for it to work. I do not recommend that as well.
So to summarize the fiasco, adjustPan which give the best UX (similar to the iPhone) is only working on Android 4.0.x.
adjustResize which is still nice in terms of UX can be made to work with all versions of Android, but can cause issues (jumpy text-inputs) for old 2.x
Remedy 2: Put this style on the text input -webkit-user-modify: read-write-plaintext-only;  Not great since it’ll make typing slower, it’ll be up to impossible to enter text on some devices. Swype keyboard won’t work either.
Remedy 3: Shift the input element off the screen, and use the change event to render the text into another element. (this is too cumbersome, try to avoid it)

Misc:
Pain: HTML5 PushState is supported since Android 2.2, but somehow it was forgotten on Android 4.0 – 4.0.2 and some 4.0.3 devices. Told you these 4.0.x are cr*p…
Remedy: Make sure your HTML5 app works well for devices without pushState support. Try a 4.0 emulator.

Pain: Incorrect dimensions, sometimes innerWidth & innerHeight might still read 0 even after the DOM is ready.
Remedy:  Wait a few (~100 millisecond) after the DOM is ready to ask it what’s the window size is.
Remedy 2: Use screen.width & screen.height (you’ll have to calculate the toolbar height)
Remedy 3: get the width/height from the server (using something like wufl)
Remedy 4 (native shell):  Get the size from the native shell.

Pain: WebSockets are not supported at all.
Remedy (native shell): Use this WebSockets PhoneGap plugin. Don’t get bothered by sockets unless you really need to.

Pain: Web Workers doesn’t work at all
Remedy: Who cares..?!
Remedy 2 (native shell): Multi threaded, yeah baby.

Pain: Android 2.x misses a lot of scrolls attempt because it’s stuck in touchmove event (error is: “Miss a drag as we are waiting for WebCore’s response for touch down.”)
Remedy :( No real remedy, I’m pretty sure there is no sulotion for that and using something like iScroll won’t solve it either.

Pain: DOM manipulation is extremely slow.
Remedy: documentFragments might help but don’t count on it.
You’re left with tricks, for example, It far smother to change visibility than to add/remove DOM elements.
It’s better to pre-render and just show() or hide() as needed, especially when animations are involved.

Some related links:
PhoneGap vs. Native: Some Thoughts on Going Native
Discussion in Hacker News
These are one year old but still very relevant (sadly)
Regarding point 1: Don’t remove images from the DOM, instead replace the src to a very small image (leason learned by the linkedin mobile team), 2: You can handle that, 3: There are good ways to do caching, 4: These days there’s reasonable debuging tools.

HTML5 for extending the device battery life (PDF)

Some other pains & remedies

 

Epilogue:  Everytime I come across a cool HTML5 example and wonder how well it tuns on mobile, I try it on iOS  and mostly like what I see. Only to be disappointed with the way Android native browser run it. And I’m not talking solely about the old 2.x.x androids that mostly run these in an unacceptable way. Even the newer androids with new version of the OS doesn’t play smoothly as the mobile safari or even UIWebView. The only solution to HTML5 on Android at the moment, is to keep it simple, very simple.

When targeting an HTML5 app to run on mobile browsers, one can not assume that  her users will use anything other than the native browser (as opposed to the more capable Chrome for Android, for example). But,  if your running your HTML5 inside a native shell (i.e. PhoneGap) There are few projects that attempt to solve the native WebView problem, by letting us bundle a better webview.
https://github.com/thedracle/cordova-android-chromeview
https://github.com/davisford/android-chromium-view
https://wiki.mozilla.org/Mobile/Projects/GeckoWebView
More on these will follow…

 

The Promise of Mobile HTML5

Less than a year ago it seemed like HTML5 was going strong. With Facebook and Linkedin adopting the technology to reach most of the screens on the mobile and on the desktop.

Linkedin had the better hybrid mobile app (HTML5 + native) and published a series of videos and articles about how they successfully did it with a team of “just” 5 developers.
Admittedly Linkedin app was really nice, but, after learning more about the internals of their app I’ve realized it wasn’t perfect.
For example the way they manage the application cache is not as good as the HTML5 app-cache that just works well out of the box. Using the term “it wasn’t documented” is not a good enough excuse, it was working well long before the debute of their app.
Also, their infinit scroll is just a not so infinit swipe, etc’

Anyhow, it appears that linkedin, similar to her bigger sister Facebook, ditched its mobile HTML5 in favor of native.
Linkedin senior director for mobile engineering Kiran Prasad claims are that there is not a good debuger and no performance measuring tool.
Firstly the debuggers are getting there every day (there are many more).
Secondly, profiling in the desktop and mobile Chrome will give you a general idea where memory is going. Profiling hybrid apps in iOS6 is also available.
I don’t think that these are really the reasons, they simply needed a stronger platform and HTML5 became too difficult to scale to their needs. That’s reasonable, mobile HTML5 is definitely not for everything.

Yet, the promise is still here – use the same code base and the same web development skillset to deploy for: native apps for mobile, browser apps for mobile, cross platform for the desktop (also outside of the browser), and so much more.

So why mobile HTML5 is not there yet? I’ll outline some of the main reasons here:

1. It’s not realy the same web development skillset
Well it is in a way, for the simple stuff it is still mostly HTML, Javasctipt and CSS. But, even for the simple stuff, things that works just fine on the desktop browser can greatly affet smoothness, battery consumption, memory usage, and eventually crashes, when used in mobile.
Every bit of code needs to be perfected in order to maintain the user experiance. Not even talking about specific glitches in specific versions and OSes.

2. Android – when it comes to HTML5 Android sux big time.
iOS had good HTML5 support from the get go. It reached full maturity from iOS 5 which is currently all that is needed to cover the great majority of devices out there.
Android on the other hand only reached HTML5 maturity with version 4.1 which is less than 25% and going up slowly. The notorious Android fragmentation is affecting HTML5 as well.

3. HTML5 apps doesn’t easily scale in terms of features
You needs to be vigilant about every piece of code that is added.
For example, adding just a small feature like an image or a text to every item in a list can greatly hurt performance.

4. HTML5 apps doesn’t easily scale in terms of crew
You needs to be vigilant about every piece of code that is added.
In order to deliver the promise of same code base in all mobile devices and in the desktop you firstly need that all of your crew will be highly proficient. Mobile HTML5 apps can easily be ruined.
Secondly if you want that code to be used in the desktop as well, you need a greater level of harmony between members.

5. Product ppl want stuff they see on other apps.
Some of these stuff are very easy to create nativly but are extremly painfull when created in HTML5.
Product ppl needs to better understand the technology that is used.

6. Native is not that hard to do
At the end of the day wrting native apps for iOS and Android is not that difficult, it’ll be easier than HTML5 in many cases.
It’s way more diffuclt to ruin the smothness in native UI though I see many apps that manage to achive that.
An avarage native developer can easily achive good user experiance.
When writing native you can get a way with poorly written apps. Even if you will make the UI render itself 10 times more than it really needs to, you can still achive good user experiance that will satidfy most users.

7. Peer presure, don’t be a chicken
Some idiot with a rooted and very old phone, will install Android 4.0 mod (worse Android OS for HTML5). And than will start to whine that things don’t work smothly.
– That’s not even a real phone, idiot.
Announcements from facebook and linkedin ditching HTML5 in favor of native lowers the moral of HTML5 supporters and help “classic” developers that are intimidated by stuff like javascript to raise their heads.
What?! Can’t you write it in native what are you chicken – nobody ever calls me chicken (btw, this is how we’ll be in 2 years)
You will (almost) always have doubts about switching to native.

∞. It’s not over, it’s barely just begun
Don’t be let down by facebook and linkedin moving to native, it’s always depends on the type of app, resources and the kind of people involved.
Mobile HTML5 apps are deliverable and in good quality for some time already.
You will gain the benefits mentioned above of same codebase and skillset along with way better deployment model.
Done right, you can deploy new app versions like deploying a website. Without the need for approval, and without sacrificing much user experience.

The bottom line is that mobile HTML5 is here for somewhat long time already, but it’s not for everything and definitely not for everyone – yet.

HTML5 Mobile Apps – Injection Heaven, Security Hell

Three weeks ago Path.com was fined for stupidly stealing their user’s contact list and saving it onto their servers. Path’s doing was obviously wrong but I’m not sure that their punishment was really justified, needing to pay this enormous bribe to the FTC using COPPA as an excuse. The lesson here is to always comply with COPPA.

Anyhow, in that same techcrunch article you can also find that “The FTC also took the opportunity to introduce a new set of guidelines for mobile developers“. Although they explain early in that article that it’s not meant to be a guideline, I still feel they misses a lot.

When it comes to HTML5 apps even the simplest app can greatly compromise the user privacy and security. If we’ll take the FTC example of a simple and harmless alarm clock app, If that app is built using HTML5 its size and complexity doesn’t matter. All that is needed is one javascript injection that will pass thorough.

How will that code be injected you may ask – all that is needed is for the app to load some content from a remote server the simplest example will be the “Terms And Condition” page which is mostly loaded into a WebView. It can be a more “complex” settings, like choosing the favorite color or loading the saved alarms. Any kind of sharing will probably be way more open to be exploited, i.e. “share your favorite alarms”. Push messages might also bring malicious code. ETC’

The bottom line is that any injection of javascript will give an attacker a lot of control over the device, more often than not it’ll be persistant. HTML5 apps usually use the localStorage that is rarely flushed, and leverage native DBs and the file system. The “page” or webview is rarly refreshed, so even if the injection is not persistant it’ll be alive for a long time.
Things like stealing the user’s contact list and tracking the user location are pretty common. Enabled by default in iPhone PhoneGap for example.

It’s only limited by the native API that is opened to Javascript, generally it’s very open, even more than the PhoneGap default API. I know of at least 1 popular HTML5 app that opens almost all of the Android native API.

You see, Javascript is one tough beast – it can run almost anywhere.
Javascript was designed basically as a none important sidekick to the browser’s HTML, “it should not cause any problems by being poorly written and should fail silently and not interfere with the main thing that is HTML.” Seriously that how it was, we’re lucky it’s not case insensitive. I’m sure that back than some people though it’ll make it simpler and better.
So, Javascript will run in any dom element no matter how naive you may think it is, it will run in unexpected parts of the element without needing the <script> tag, i.e. onerror=”attack()”. It used to even run from CSS and from images, but we’re over that now asfaik in mobile browsers.

As opposed to that, it’ll take a very special case for injection to be able to execute arbitrary native code. You can make a native android app that will run anything – even get root, but I doubt that any legitimate app regularly download strings and run it as commands. (basically on rooted Android you can do exec(“su”) and everything else)

With Javascript the app does not need to be designed in any special way, an unsanitizes string will likely to execute.

These kind of injection are not the sole problem of PhoneGap based applications.
Any app that uses HTML5, even if it’s mostly native, any API that is opened to javascript can be leveraged by an attacker.

Phonegap (Cordova) has a mechanism to white list remote hosts which is really only effective on the iOS. It adds a little bit of security, but many apps anyway uses a wildecard “*” to allow all hosts. The wildcard is used by default in the phonegap cloud (saas solution to build phonegap apps)

As you can see the option for an attacker are enourmoe, all it needs is one vector of injection and there is an open path (no phan) to take over all of the devices of all of the users.

HTML5 apps that runs inside the mobile browser are also a nice target for injection attacks, althouygh it’s lacking most of the native api, there is still access to location in all mobile browsers. It’s less powerful for the attacker since it’ll prompt the user way more vigusly.
The Dolphin Mobile Browser implement the full phonegap native api, for example (which is generally a good thing), but it makes in-the-browser websites and apps more exposed to attacks.

So what to do than?!
– Sanitize sanitize sanitize all user input, server and client!

Say What, Flash is More Secure Than HTML5?!

So my favorite script kiddy and copycat, Feross (copied, note the shameless “I discovered” in his Quora post, LoL)
Found a social engineering flaw in the HTML5 fullscreen mode that can be used for phishing attacks. This time it might be even his own finding… what do you know ;)

This flaw is very much similar to the well known and very old picture-in-picture
Picture-in-Picture Phishing Attacks and Operating System Styles
More info..
IMHO the old version is still way more dangers for phishing.

So How Flash is more secure?

What enables this HTML5 fullscreen flaw to exist in his prime is the fact you have full keyboard access. This way an attacker can more easily steal the user’s credentials.
After all fullscreen was existant in Flash for many years now, yet it was never compromised this way. The main reason is that Flash is more secure is that it does not allow full keyboard interaction in fullscreen.

Good thinking Adobe, taking care our security… oh wait… Flash was added with this feature with version 11.3… after all Flash can’t be left behind…
Working demo…

Damn… but still Flash gives you a decent popup confirmation which HTML5 doesn’t

Yeah, I know Chrome give you a popup too, but you don’t have to click on it to get FULL keyboard access.
I constructed this “amazing” demo here (chrome only), as you can see you get the message but the keyboard is fully functional and accessible through javascript.

So still Flash is more secure than HTML5 – in that respect.

It takes us back to what me and other were preaching about, that with great power comes great responsibility.
HTML5 have its own flaws and the more powerful it’ll become it will get even more.

Stay tuned…

To Fix JavaScript toFixed

The problem with the built in toFixed function in JavaScript, is that it always round the numbers. It’s like calling Math.round()
Call 9.513.toFixed() => 10
Call 9.226.toFixed(2) => 9.23
Why would you want that to auto round. If I wanted to round I would have round.

Not only that, the toFixed is not always rounding as expected.

Anyhow, here is how to do a toFixed accurately:

You can put it in the Number.prototype if you really want to, personally I rather put it in a untils object.

Cool feature of HTML5

Not dealing much with HTML lately, I’ve only noticed this new feature now. The thing is that HTML5 let you change the page’s URL path without refreshing the page content. Like in this example from google 20thingsilearned.com – when you flip the book’s pages the url changes for easy bookmarking and SEO, but the content doesn’t flicker. If that not seems like much to you, than you don’t know what you’re talking about.

All that is needed to achieve the magic is this line of code:

window.history.pushState("", "title", "somePath/");

Try it:

    Click to change the page url

Amazing! There is no need for the ugly hash (#) anymore in order to achieve AJAX/Flash deep linking… oh wait… it doesn’t work in IE9 and FireFox 3.x :( (yet)

Thinking “I know all that browsers can do” this one got me wondering. I’m coming to realize that even though I still believe I generally know most of its capabilities, with HTML 5 there probably lots of things that browsers can do which I’m not yet familiar with. I swear I will skim through the spec when I’ll have the time, there must be many interesting security flaws in there… or is it?!.

More info here & here

Putting Data Into Context

The challenges of presenting large amount of data visually in a way that one will be able to easily digest and understand it are becoming more viable daily. The democratization of data, challenge authors to think about new ways to visualize it.

The above text, is pretty much the summery of this highly inspiring video called Journalism in the Age of Data. As the name suggest this video is mainly about journalism data viz, but, it is also highly inspiring for anyone dealing with data of any kind.

Many RIA applications today struggle with the ability to present large data sets to the user in away which he can digest and understand.
I would say that many of these new apps, especially in the enterprise space and from the last few years, are built upon the Flex framework.

As RIA developers many of us face these challenges in the day to day work. Obviously, the charts that comes bundled with the Flex framework won’t suffice most of the time, and one would need to relay on third party components or role her own. Not so long ago, its seemed that this area is blooming. The amazing open source projects like Flare and BirdEye. The slick commercial components, IBM ILOG Elixir and KapLab – ridiculously priced and has draconian licensing, respectively.

Today, these open source projects seems to be abandoned and the commercial tools prices seem to increase. The field of online data visualization is exploding and yet the Flex tools seems a bit halted.

The somewhat halted SilverLight with its basic charts and decent third party components. And the HTML5 alternatives, like Protovis, which still needs some maturity – doesn’t seem to provide the alternative.

Anyhow, if one wants to create something “out of the box”, than she needs to use something like Flare as the base and invent her own data viz, other than use some slick, out of the box, components.

InsideRIA has an immense list of with most data visualization frameworks and resources


The Video

I’ve extracted some selected examples, for your convenience:

Many Eyes (Java)
Budget Forecasts, Compared With Reality (Flash)
The Jobless Rate for People Like You (Flash)
In graphics: Eurozone in crisis (HTML)
The Stimulus Tracker (Flash)
Crash: Death on Britain’s roads (Flash, HTML)
How Different Groups Spend Their Day
The Crises of Credit
Last.fm Listening History – What have I been listening to? 
Eurovision Song Contest 2008 (Flash)
Google public data explorer (Flash, HTML)
Oakland Crimespotting (Flash)
Tracking Taxi Flow Across the City

Blogs:
http://infosthetics.com/
http://www.visualcomplexity.com/vc/
http://flowingdata.com/
http://blog.blprnt.com/
http://www.good.is/infographics
http://eagereyes.org/
http://www.guardian.co.uk/news/datablog
http://well-formed-data.net (not from the video)

Flash vs HTML5 vs Adobe vs Apple

Disclaimer: I’ve written this post a few days weeks ago when I was a bit pissed, so it has some ranting-ness in it. I do have a soft side for Flash, but, as I said before – technologies never cry, and I will use whatever is the best for the job.

The last buzz about “Flash is dead” really came out of proposition. All of these blind followers, blood-thirsty, warmongers that never seen an HTML tag or know what each these technologies can do, worshiping their new king HTML5, and are just shouting “we conquer video”, “kill kill”…

The fact that the colorful-kindle /slash/ enlarged-and-disabled-iPhone doesn’t have Flash, is important, but the reactions are completely exaggerated. I think Adobe should have stayed nonchalant about it which could might have lowered the flames. Anyhow, it’s easier to say in retrospect.

(Flash) Power to the people:

If you look at the short history. Flash enabled utterly amazing things on the web in times when static-ness and ugliness ruled. The problem is that it was too easy to create. All of a sudden un-capable people could have created “amazing” things. The fact that Flash could be abused so easily is part of what make some people hate it.

You can expect for HTML5 to be abused if it’ll be as accessible as Flash. That means, if tools like the Flash IDE and others will enable publishing to HTML5. Than again you can expect it to abuse either way.

RT @iainlobb “Flash developers of the world: unite and make terrible HTML5 banner ads that grind CPUs and crash, just to show that the grass isn’t greener”

The fact that things can be done differently doesn’t necessary mean it will. Most of what Flash can do, can be done long ago using Javascript and HTML (old buzzwords omitted). Actually Flash and Javascript developers can relatively easy switch, since the languages were almost the same on the older versions of Actionscript. Even the glitches were copied from JS. And anyway the main thing that matter is thinking interactively, like a Flasher do. With HTML5, the capabilities of the two technologies are even closer. But, the challenges of developing complex Javascript application are sill far greater, It’s still  the same old language, more error prone and more difficult to architect. I don’t see how an online game developer, for example, will want to develop her games using HTML5. In fact I’ve yet seen a decent, non experimental, online game written in Javascript.

To think that all of a sudden Flash will disappear, is nonsense.

RT @leebrimelow “You all better head immediately over to the FWA and check out your favorite Flash work. It may all be converted to HTML 5 by the morning.”

Even if we declare Flash as dead today, it’ll be a very lengthy process measured in years at best. And since, yet again, Flash isn’t dead yet. It has all this time to reinvent itself, Adobe should use this time wisely.

If you tell me you don’t use Flash, you’re basically telling me that you have never seen a video or played a game online?!
How about a nice colorful animation, or maybe neatly looking fonts done in sIFR, than you must install Flash and start experiencing the web.

Apple and the sealed garden:

There is something annoying about Apple arrogance, but, I have to say that what almost killed Apple in the past, is what making it so successful right now. More than 20 years ago when apple wanted to control everything on her PC (yeah right it’s called Mac) most users were savvy users who wanted full power. Usability, reliability and all of these great things Apple invented weren’t as important. Today is the grandpa era where consistent quality is a key.

Steve Jobs is so convincing that I almost believed him that he disallow Flash on the iPad to protect grandpa from a crashed browser – but I don’t. No one will deny that Flash has some issues, but it’s an integral part of the current web and wouldn’t be as such if it was just causing the browser to crash. Click-to-active could have been used to solve all of the real and unreal Flash issues.

Robert N. Lee “If somebody wants you to give up what you’ve got now in exchange for the promise of something way, way better later, you’re being screwed and not in a good way. This is pretty basic.”

Flash on the iPhone, for example, would enable full VOIP applications to run from the web-browser (i.e. ribbit). Google voice iPhone application , could have leverage it instead of just allowing cheap callbacks. Allowing this kind of freedom is unthinkable for Apple.

But Apple might be loosing it, again they want too much. Apple moved from making computers for a very small niche market of mainly tree huggers. To a very powerful and successful company reinventing the smart phone market completely. Again it might blow in her face, Google might come and bite you with her don’t be evil bullshit ;)

BTW, grandpa don’t want multitasking either, thumbs-up for that as well, Apple (no pun intended).

Adobe is evil too:

I still remember how many many years ago Adobe asked you to snitch on your friends that uses pirated software, and by doing so, to become Robin Hood. Yeah you heard it, this was their fight on pirated software. It’s OK to fight piracy but, how is that comply with the original story?! After reading the article about the old management I can see where it might came from.

RT @aral: “Remember that Adobe was on the edge of irrelevancy on the web and non-existent in mobile when they bought Macromedia.”

The question, “should we support Adobe and her proprietary Flash instead of the open standards?”, is somewhat misleading. Adobe is a big girl she should take care of her own. The question is – can they really make it? can they really reinvent Flash and the web yet again?

The idea that everything that is open is immediately good, is also misleading. There’re a lot of financial interests in openness. Many companies base their business model over open-source and openness. Preaching for open standards doesn’t immediately make you a saint.

Adobe might be an heavy/old corp, after our hard earn money. But, I can tell you, it does seems like they do have some nice, talented and community aware people when it comes to Flash. And compared to Apple, Adobe is like the Shangri-La of openness.

The last  bash against Flash might help to push Adobe to polish the player, if Adobe can afford putting even more resource on it. Either way it won’t be on the iStuff.

Yeah, but, HTML 5 is a standard and not a proprietary black box like Flash:

We all know users don’t care about the format, they just want the experience. Believe it or not, developers don’t care much either, they just want the power to get the best result, in our case power is IDE and runtime. The pain of delivering a truly cross-browser HTML is not something to be desired. Flash is still the best way to deliver rich interactive ubiquity.

And besides, HTML 5 may be a standard, but you’ll still be running it in a proprietary runtime, the browser.

The browser wasn’t chosen to be the ultimate way to deliver new and cool applications because of it’s wonderful capabilities. It became as such because it’s the lowest common denominator. Maybe it’s time for a better lowest common, Flash was a step in the right direction, maybe we’ll be better with something more powerful like Steam. Actually the browser was also “chosen” because it’s very easy to create content for it.

For the developers, I don’t think it really matter which technology to use. All these idiots developers who couldn’t handle Flash and are now gloating and think they will be able to easily create beautiful interactive content – all will be disappointed. (you know who you are, yeah I meant you personally ;) )

Thing are prone to change relatively quickly in our times. The only fact that I can squeeze out of this, is that Flash is still the prominent force of interactive-ness on the web and will remain as such in the foreseeable future for sure.