Category Archives: Javascript

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…

To Fix JavaScript toFixed

Posted on by
Reply

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

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

Putting Data Into Context

Posted on by
Reply

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

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.

HTML 5 vs Flash vs SilverLight

Posted on by
11

This is by no mean a full technical comparison between these technologies, just a chat between 2 geeks. One is a skeptic backend dude ;) and the other one is yours truly, a GUI guy.

It started with an email from Eli (the backend dude)  titled “the Next big thing”?

Eli:  http://www.chromeexperiments.com/ , RIP Flash. Long live HTML 5 + JavaScript.

Guy: This is old…  Let me know when Chrome will reach 99% of desktop computers.

Eli:  HTML 5 is old? LOL.  FYI, despite the fact that the spec is far from being finalized, browsers with sparks of HTML 5 support count among them ie8, ff3, opera and safari.

Guy:  Old news, that is.  HTML 5 is only started to get supported.   HTML 5 + Javascript has a small subset of what Flash 10 can offer.  By the time HTML 5 will be a standard Flash 12 will reach 90%

Eli:  Yeah, yeah, I’ve heard the same thing about java applets about a decade ago… ;)   Seems like the simplicity of markup languages makes them the long distance runners

Guy:  Exactly, Flash has succeeded where Java failed. Flash has a lot of issues, but currently (and in the few coming years for sure) it’s the most powerful and available runtime.  HTML + Javascript is far from simple and cause huge problems for complex applications.

Eli:  Flash is mostly used to fill gaps in HTML, not to solve the huge problems in the complex applications the web is made of, isn’t it?

Guy:  This is what Adobe aim to solve with Flash, to be the ultimate platform for creating and running RIA (Rich Internet Applications). Still, a lot of RIAs are written in AJAX (Javascript+HTML), which, with the aid of solid and powerful frameworks like jQuery become reasonable in some cases. Lately Google, which already have a lot of RIA tools, is trying to change the game with its Chrome browser and OS. The Chrome browser is equipped with a much faster JavaScript engine that enables what we can see in chromeexperiments.com. Microsoft is also trying to be a player in this space with its new SilverLight runtime.

Eli:  Yet, the idea of basing the web on some proprietary browser plug in is doubtable. Epic fall of java applets and endless annoying ActiveX bullshit are just a couple of examples. IMHO, the shortcoming of this approach is missing the idea that The Web is more than “screenfuls of text and graphics” ©. Layout engines, however, are here for more than a decade and markup languages – for ages, proving themselves in taking the web into the places no one was thinking then about.

P.S. The only thing Adobe aims is profit.

P.P.S. I love holy wars.

Guy:  The proprietary thing is indeed an issue, it prevents Flash from being accepted in some areas of the web and by some users. E.g. the Wikipedia video project uses HTML 5 video, they can’t use anything that is closed. What prevents Flash from being open-sourced is that it contain 3rd party patent not owned by Adobe. Adobe is already trying to appeal to the open source crowed with the opening of some of its IP http://opensource.adobe.com. IMHO they might completely open the Flash runtime if and when it’ll be pushed to the wall by Microsoft and its new SilveLight (talking about proprietary ;) .

Java and Active-X are completely different stories, each had its own reason to fail. Partially and shortly, it is too difficult to create a Java applet and its far from appealing to a designer. Active-x has no sandbox, hence it has a lot of security issues, and also runs only in IE.

HTML was created to display text and images with basic layout, Javascript was added to enable simple interactivity, no one dreamt it can be used the way it’s done today. Only with the maturity of the browsers and with specialization of web developers, these king of RIAs could have been created. Yet it still pushes the tech to it limits.

The HTML 5 standard will be adopted relatively fast, but we’re still talking in years. Even with the Chrome JS engine (V8), Javascript can’t match the power of languages like Actionscript 3.0 and C#. Javascript 2 is somewhere in the very distant future. HTML 5 biggest improvement is the support for media (video/audio). But, it still can’t compete with Flash and SilverLight media abilities, in terms of playback and deployment.

HTML 5 is nice but the main holy war is between the reigning RIA world champion which is Adobe Flash and the challenger which is Microsoft SilverLight. There is much to be loved about this holy war, since it pushes the technologies forward and the biggest winners are us, the developers and the users.

(I’m talking about hard-core RIA, not some lightbox image gallery which is still preferably done in HTML)

P.S.  Adobe isn’t a saint, but, everyone want to make some profit, even google, even us as I recall ;) If you gain it morally and also use it to make something like the web better, than it’s fine with me. 

P.S.S aforementioned.

Malicious camera spying using ClickJacking

Posted on by
104

Update: Adobe has fixed this issue by framebusting the Settings Manager pages. Now, 99.9% of the users are protected from this specific exploit. Congrats on the fast response. —-

Turn every browser into a surveillance zombie. The wet dream of every private eye and peeping tom. Imagine this scenario, you play a short game on the web and by doing that you unknowingly grant someone full access to your webcam and microphone.

I’ve made a live demo of it in here, this demo won’t listen or record any of your input.

If you don’t want to try it or don’t have a webcam connected, then check out the video.

[kml_flashembed movie="http://www.youtube.com/v/gxyLbpldmuU" width="450" height="376" /]

When I’ve first heard about ClickJacking and how Adobe is concerned about it, I thought that the Flash Player Security Dialog must have been compromised. But the Security Dialog does a good job disabling itself when you try to mess with it’s visibility through DHTML. Unless there’s some 0-day issue with the Dialog it’s probably relatively safe.

The problem here is the Flash Player Setting Manager, this inheritance from Macromedia might be the Flash Player security Achilles heel.

I’ve written a quick and dirty Javascript game that exploit just that, and demonstrate how an attacker can get a hold of the user’s camera and microphone. This can be used, for example, with platform like ustream, justin and alike or to stream to a private server to create a malicious surveillance platform.

I’ve made it as a JS game to make it easier to understand, but, bear in mind that every Flash, Java, SilverLight, DHTML game or application can be used to achieve the same thing.

Some of the clicks are real game clicks other are jacked clicks. Every time the click is needed to be jacked the content simply move behind the iframe using z-index

I had doubts about publishing this, but, if I could have understand it so are the bad guys, so it’s better to know about it.

In this case Adobe could have just framebust the pages that holds the Settings Manager. There are two issues with frambusting in this case, it won’t solve all cases (legacy browsers for ex) and will force Adobe to rely on javascript.

Play it here, watch it here

Thanx for not killing the Flash clipboard

Posted on by
Reply

Recently, a questionable Flash feature of writing to the user’s clipboard has been exploited. Adobe will finally fix this feature and it’ll require user interaction (mouse/keyboard click) in the upcoming Flash 10.

IMHO the people in charge of the Flash Player security have chosen the best option, retaining the functionality of the feature and still keeping the users secured.

Of course, a user can be led to click on the malicious Flash movie, or focus to the movie can be set and any keyboard press will lead to a pollution of the clipboard.

A more strict security measure could have been chosen, a dialog box asking the user to permit clipboard writing, could have been implemented. The Flash Player already uses a similar dialog when interacting with the user’s camera and mic. An updated Internet Explorer uses a dialog when interacting with the clipboard, allowing both read and write.

javascript:clipboardData.setData(“text”, “I’m in the clipboard”); (IE only)

 IE_clipboard

But, using the later option will make this feature too annoying for the user, and mostly useless.

Thanx for not killing this feature but still making it secure enough.

Regarding Flash movies that’ll still try to exploit this feature. It’s up to AD distributors and website owners to do their part and not distribute or host malicious files.