Category Archives: HTML 5

The Promise of Mobile HTML5

Posted on by
4

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

Posted on by
3

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?!

Posted on by
3

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…

Changed My Blog Tagline

Posted on by
Reply

Ever since I opened my blog at March 2006 the tagline I’ve chosen was “Flash And Everything Else”. Even though Adobe Flash wasn’t always the main thing I was doing, it always had a warm spot at my heart and I always kept on updating with everything related to it.

Flash could have lived for another few good years but Adobe decided to kill it prematurely, oh well it still have some few valid uses I guess – have fun. I haven’t touched it for the past 3/4 year.

Like many Flashers the transition to other client side technologies is natural, especially since many of us used it before.

What I do right now is mainly mobile, web, and mobile-web, but using something like “HTML5 And Everything Else” doesn’t sound good. All other similar variations failed as well. I’ve chosen “Tech And Everything Else” so I guess I’ll have to be more general and write about tech in general. I have some things to say – stay tuned.

Adobe Flash – Brave Fold

Posted on by
3

In poker, a brave fold would be a case where you have a strong hand and you are already committed to the pot (you’ve already put in some substantial amount of money), even so, you sense that your opponent might have a stronger hand and you fold – losing your strong hand and the pot. Staying in the game would have required you to danger even more money, maybe too much.

Adobe was in similar situation, it has a very strong hand – Adobe Flash, and has already committed a lot of money on this loss leader. But staying in the game would have required them to put even much more money/resources on it. They would have to be fully committed, they would have to be “all-in”, borrowing from poker again. They could have end up winning the hand but if they will lose they can be out of the game completely.

We should have all known that the iOS will never run Flash. It’s almost like Steve Jobs last words were “exterminate the Flash” – similar to the hate Genghis Khan had for the Tatars when he ordered  “the extermination of the Tata Mongols”

In retrospect, seems like wasting all that resources on porting Flash for the mobile was good only for Adobe and us in the Flash crowed to be able to give Steve and the other mongers the finger, telling them – see, Flash runs well on the mobile! It was supposed to be obvious that Flash will never rich similar ubiquity on the mobile as on the desktop. Than again, everything is easier in retrospect.

There are many reasons why Flash succeeded where 1,000 other plugins failed. And it’s also amazing how a relatively small corporate like Adobe managed to be in front of much bigger competitors, Microsoft with it’s buckets of money and Sun with it’s Java Java Proxy Proxy, to name only two.

I’m just sick of layman’s that are quoting laymen’s that are quoting a reporter that quotes another reporter that quote “someone who knows” that quote anther one that “really knows” – it’s like that game, what’s is name?! The other day I’ve heard from someone who should have known better that – “lake of multithreading killed Flash” – you’ve probably heard that BS before, yep it’s total BS. Add that to the many other miss-consumptions people make regarding this issue and it piles to a big pile of sh<bip>it. I wonder how many of these laymen’s knows the hassle of cross browser HTML development?!

So, congrats on the brave fold Adobe, with the right hand I solute you. On the other hand I’d say f*ck you big proprietary beast, how dare you stab so many people in the back.

Cool feature of HTML5

Posted on by
4

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

Flash Private Browsing Fixed – Not Good Enough

Posted on by
3

I was going to congrat Adobe for their fix to the private browsing in Flash, this was my original text:

I’m glad to say that Adobe has fixed the minor issue they had with the new Flash Player 10.1 private browsing. I’ve written before on how a developer can tell the user’s browsing mode.

The Flash Player that is installed with CS5 is 10.1.52.14 which still suffer from this bug. If you surf the web using private browsing mode you should update the Flash Player to the latest, currently, 10.1.53.38 (RC4). Actually you should update it anyway.

But, when I went to see what have they changed in order to fix it. I saw that both modes, now, have the same limit of 100KB, but it’s still differ. While trying to save more than 100KB in normal browsing mode the status is “pending” while in private browsing mode it immediately fails.

Making this demo functional again required changing 1 line of code. Using any Flash Player, from 10.1_beta2 till latest 10.1.53.38(RC4) should show you if you’re in private mode or not.

[kml_flashembed movie="http://blog.guya.net/wp-content/uploads/2010/05/KissAndTell.swf" width="400" height="35" /]

So, please, again, normal and private browsing modes should behave exactly the same from a developer standpoint. Making local storage limit the same 100KB was a step in the right direction, but, it’s not enough. Let any Flash content ask for more storage even if it’s in private mode and allow the user to accept it, just remember to delete the user’s choice along with the local storage.

BTW, it might be possible to trick the browsers to tell you the user’s browsing mode, using HTML5 localStorage for example, and without using Flash.

The updated source code is below:

package {
	import flash.display.Sprite;
	import flash.display.StageAlign;
	import flash.display.StageScaleMode;
	import flash.events.NetStatusEvent;
	import flash.net.SharedObject;
	import flash.net.SharedObjectFlushStatus;
	import flash.text.TextField;
	import flash.text.TextFieldAutoSize;
	import flash.text.TextFormat;
	import flash.utils.getTimer;
	import flash.utils.setTimeout;

	/**
	 * This class will tell the current browsing mode of the user
	 * Tested with Flash Player 10.1 beta 2 - 10.1.53.38 (RC4)
	 * for more info go to:
	 * http://blog.guya.net
	 */

	[SWF(backgroundColor="#FFFFFF", width="400", height="35")]
	public class KissAndTell extends Sprite
	{
		private var _tf:TextField;

		public function KissAndTell()
		{
			initStage();
			createTF();
			setTimeout(saveData, 300);
		}

		private function initStage():void
		{
			stage.scaleMode = StageScaleMode.NO_SCALE;
			stage.align = StageAlign.TOP_LEFT;
		}

		//try to save 140kb into the local storage
		private function saveData():void
		{
			var kissSO:SharedObject = SharedObject.getLocal("kissAndTell");
			kissSO.data.value = getDataString(140);

			var status:String;

			try
			{
				status = kissSO.flush();
				kissSO.addEventListener(NetStatusEvent.NET_STATUS, netStatusHandler);
			}
			catch(ex:Error)
			{
				trace("Save failed - private browsing mode");
				setPrivateText();
			}

			if(status && status == SharedObjectFlushStatus.PENDING)
			{
				trace("Pending status - normal browsing mode");
			}

			/***  Changed in the newer versions of the Flash Player 10.1 beta ***/
			//If we can save more than 100kb then we're in Private Mode
			else if(status && status == SharedObjectFlushStatus.FLUSHED)
			{
				setPrivateText();
            }
		}

		//Listening to this event just to prevent exception on debug players
		private function netStatusHandler(event:NetStatusEvent):void
		{
			trace("event.info.code: " + event.info.code);
		}

		private function setPrivateText():void
		{
			_tf.text = "Private Browsing Mode";
			_tf.backgroundColor = 0xAA2222;
		}

		private function createTF():void
		{
			_tf = new TextField();
			_tf.autoSize = TextFieldAutoSize.LEFT;
			_tf.defaultTextFormat = new TextFormat("Arial, Verdana", 20, 0xFFFFFF, true, null, null, null, null, null, 10, 10);
			_tf.text = "Normal Browsing Mode"
			_tf.backgroundColor = 0x22AA22;
			_tf.background = true;
			addChild(_tf);
		}

		private function getDataString(kb:int):String
		{
			var t:int = getTimer();
			var word:String = "GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_GUYA.NET_";
			var count:int;
			var a:Array = new Array();
			var lenNeeded:int = kb * 1024;
			while(count * word.length < lenNeeded)
			{
				a.push(word);
				count++;
			}

			var ret:String = a.join("");
			trace("time for generating " + kb + "kb: " + String(getTimer() - t) + " ml");
			return ret;
		}

	}
}

Flash vs HTML5 vs Adobe vs Apple

Posted on by
7

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.