Skype has stated they are aware of a serious cross-site scripting vulnerability within the chat feature for Skype on the iPhone. The security hole could allow for malicious JavaScript code to access to your address book and is known to affect versions 3.0.1 and below.

Skype reached out to TechCrunch to say they're hard at work on getting an update pushed to the App Store.

We are working hard to fix this reported issue in our next planned release which we hope to roll out imminently. In the meantime we always recommend people exercise caution in only accepting friend requests from people they know and practice common sense internet security as always.

The funny thing is, Skype has known about the issue for a while now. AppSec Consulting security researcher Phil Purviance helped discover the problem and let Skype know about it almost a month ago. Skype responded saying they would release an update earlier this month, but we're nearing the end of September and there's no update to be found.

Here's hoping Skype gets on this quick and pushes out an update soon, but in the meantime check out the video below detailing how the vulnerability works.

[superevr, TechCrunch]

Update: Sadly, while Web.app got Nitro so Home screen web apps enjoy the faster JavaScript rendering, UIWebView did not. That means web pages contained in apps are still using the slower version. (Likely for security reasons.)

According to a poster Hacker News, the Nitro JavaScript engine brought to iOS 4.3's Safari browser, is now available to embedded UIWebViews and home screen WebClips in iOS 5. Apple originally claimed the Nitro engine, ported from desktop Safari, would make iOS Safari 2x faster, but due to restrictions on code interpretation (Nitro uses JIT, or Just-in-Time compilation), it was only available in the Safari sandbox. This effectively made web pages embed in apps and saved to the home screen feel twice as slow. No longer, according to this thread:

Q: Did they fix the bug from 4.3 where home screen web apps don't use Nitro?

A: This is probably breaking my NDA to say this, but yes, they did. Web.app now has the "dynamic-codesigning" entitlement, which enables Nitro.

In other words, embed webpages and home screen web apps just became first class citizens, and should have the speed to prove it.

[Hacker News via CNET]

As we posted the other day, while Safari in iOS 4.3 got a huge speed boost thanks to the Nitro JavaScript engine, asynchronous mode, and HTML 5 caching, bookmarking a site to the Home Screen (Web Clips) that launch in full-screen mode, or browsing inside an app (UIWebView) didn't. That meant, while web apps on the home screen and web pages embedded in apps were as fast as they were in iOS 4.2, they weren't as fast as Safari in iOS 4.3.

The technical reason for this is because Nitro is using Just-in-Time (JIT) compilation. Daring Fireball says:

A JIT requires the ability to mark memory pages in RAM as executable, but, iOS, as a security measure, does not allow pages in memory to be marked as executable. This is a significant and serious security policy. Most modern operating systems do allow pages in memory to be marked as executable — including Mac OS X, Windows, and (I believe) Android1. iOS 4.3 makes an exception to this policy, but the exception is specifically limited to Mobile Safari.

It’s a trade-off. Most OSes allow marking memory pages as executable for performance reasons. iOS disallows it for security reasons. If you allow for pages of memory to be escalated from writable to executable (even if you require the page be made permanently read-only first), then you are enabling the execution of unsigned native code. It breaks the chain of trust. Allowing remote code to execute locally turns every locally exploitable security flaw into a remotely exploitable one.

So if you load a page in Safari or have a Home Screen bookmark that launches into Safari, you get Nitro because Apple trusts Safari (which given how big an attack target Safari has is... interesting.) If, however, you load a page in an app using UIWebView you get the old JavaScript engine because Apple doesn't trust that app. If you launch a Home Screen bookmark that includes specific code for full screen mode, Safari doesn't pick it up but it opens in Web.app and -- for some reason -- Apple doesn't trust that either (yet?).

WebKit2 -- which iOS 4.3 doesn't seem to be using -- could address this because it uses split processes built into the frameworks but there's no word on when or if Apple will implement it in iOS. (It's reportedly implemented in Mac OS X Lion beta.)

So no conspiracies, just the usual trade offs between security and convenience and the limits of Apple's resources to get everything done all at once. (We won't put the pitchforks and torches away altogether, however, and Web.app gets Nitro, and everything gets WebKit2.)

[Daring Fireball]

CNET UK was able to take the iPad 2 running iOS 4.3 out for a test drive and the results are hypercar impressive -- 2097ms. iOS 4.3 and its new Safari Nitro engine gets a lot of the credit -- it blows iPhone 4 and the original iPad past the likes of the Nexus S and Galaxy Tab as well (they've been unable to test a Xoom as of yet), but that Apple A5 is enough to power iPad 2 to very top.

Why does this matter? Increasingly popular sites like Facebook are using more and more JavaScript to provide more and more functionality. Parsing and presenting that as fast as possible is key to having a good web experience. Who wants to wait to see their wall?

Certainly Android will get an even better version of Chrome in the future, and iOS 5 might just bring us WebKit2 like Mac OS X Lion is currently providing in beta form. For pure web performance junkies, 2011 is looking to be a very good year.

[CNET, thanks Jason!]

During Apple's iPad 2 announcement yesterday Scott Forstall announced that Mobile Safari was getting a 2x performance boost, in part by porting over Mac OX's Nitro JavaScript engine.

As you surf the web, your fingers will love the responsiveness of the new Nitro JavaScript engine powering Safari. It runs JavaScript up to twice as fast as in iOS 4.2.2 Which means you get more speed behind each page load. And sites with lots of interactive features can appear on your screen even faster.

Users should see noticeable speed improvements under iOS 4.3 when visiting highly-interactive and complex websites across iOS devices, and when paired with the A5 chip and (presumably) more RAM on the iPad 2 it should really scream. Mac OS X Lion has recently been given a WebKit2 boost as well but there's no word yet on whether that will be carried over to iOS or when.

Are you looking forward to the Safari performance boosts coming in iOS 4.3? Let us know in the comments below!

[Apple]

Which has the fastest browser, Apple's iOS 4 or Google's Android 2.2? We're used to browser battles here on TiPb, but how about a browser battle battle? See, both Ars Technica and Engadget ran some tests, pitting iPhone 4 on iOS 4 against the Nexus One running Android 2.2 Froyo and the results... varied dramatically to say the least.

Ars SunSpider and V8 benchmarks showed the Nexus One blowing iPhone 4 out of the water with almost double the JavaScript performance. Engadget's real-world test loading real-world webpages, however, had iPhone 4 with a slight lead when Flash was enabled on the Nexus One, and slightly behind when Flash was disabled.

Both iOS and Android use WebKit-based browsers, with Apple running the Nitro JavaScript Engine and Google running their V8. Likewise iPhone 4 has Apple's own A4 processor while Nexus One boasts a 1Ghz Snapdragon.

Some might not think iterative increases in rendering speeds matter, but as we race towards the agile future of web apps, every little bit becomes important. Just like on the desktop, we expect every new release from either party (and others) to keep pushing the envelop. We should get iOS 4.1 in September and Android 3.0 later this year as well, both likely faster than what we have today.

So kudos to Google. Hopefully Apple responds in like fashion and the browser battles (and browser battle battles) continue!

[Ars Technica, Engagdget, Android Central]

Done21.com has discovered something interesting in the online iPad user-guide: a new JavaScript framework they've dubbed AdLib (after its filename) that allows for very native app look and feel in the decidedly web-based app.

AppleInsider notes that it appears to be related to the PastryKit framework used for the iPhone user-guide (which stands to reason), and the TuneKit framework used for iTunes LP and iTunes Extra. And that the name may tie-in to the iAd rumors, and to internal efforts on Apple's part to raise the bar of web apps and diminish the need for plugins like Flash and Java.

Could we find out more at Apple's iPhone 4.0 event tomorrow? We certainly hope so. As much as some decry the closed nature of the App Store, developing for Safari is wide open and a new class of better, faster, stronger web apps is ultimately good for everyone.

Video after the break!

YouTube link

If you're browsing the web on a PC, you can just hit CTRL-F or CMD-F and quickly find any text on a webpage. It's great for finding things fast, especially on long reams of text, and Safari does a nice job of it -- just not Mobile Safari on the iPhone, not yet.

Editor emeritus Mike Overbo brought something very similar to us two years ago (along with a ton of others -- check that link!) when iPhone 1.x made bookmarklets all the rage. Since then, Apple has added a lot of functionality, but still hasn't deigned to gift us with Find... on page. Rafael Cimatti (via App Advice) is keeping the handy Javascript bookmarklet alive via Cydia (though it works on any iPhone). It can't fully replace a built in command, with next, back, etc. options, etc. but if it isn't 100% right, it is 100% "right now".

Here's the bookmarklet: Find...

Either bookmark it on your desktop browser (drag it to the bookmark bar on desktop Safari) and sync it over, or on your iPhone copy the code after the break, bookmark a random page, edit it, change the name, and paste in the code (check the App Advice link above for step by step instructions).

And next time you're on a page, hit the bookmark, type in your text, and find away!

Have an iPhone Pro Tip of you own to share? Send it in!

[via Daveizzle]

javascript:void%28s%3Dprompt%28%27Find%20text%3A%27%2C%27%27%29%29%3Bs%3D%27%28%27+s+%27%29%27%3Bx%3Dnew%20RegExp%28s%2C%27gi%27%29%3Brn%3DMath.floor%28Math.random%28%29*100%29%3Brid%3D%27z%27%20+%20rn%3Bb%20%3D%20document.body.innerHTML%3Bb%3Db.replace%28x%2C%27%3Cspan%20name%3D%27%20+%20rid%20+%20%27%20id%3D%27%20+%20rid%20+%20%27%20style%3D%5C%27color%3A%23000%3Bbackground-color%3Ayellow%3B%20font-weight%3Abold%3B%5C%27%3E%241%3C/span%3E%27%29%3Bvoid%28document.body.innerHTML%3Db%29%3Balert%28%27Found%20%27%20+%20document.getElementsByName%28rid%29.length%20+%20%27%20matches.%27%29%3Bwindow.scrollTo%280%2Cdocument.getElementsByName%28rid%29%5B0%5D.offsetTop%29%3B

Once again validating Dieter's iPhone 3GS vs. Palm Pre web rendering smackdown, MacRumors reports on Medialets' latest Sunspider Javascript tests pitting the iPhone 3GS against the iPhone 3G (both on 3.0 and 2.2.1), Palm Pre, and Google Android G1.

As MacRumors points out, not only is iPhone 3GS' clear, current speed advantage impressive, but the 3x improvement iPhone 3.0 gives the iPhone 3G is most impressive as well.

Bill Gates' "power of software" indeed...

We mentioned yesterday that iPhone OS 3.0's Mobile Safari Browser was being reported as faster than the current iPhone OS 2.2.1 version. Now Ars Technica has run the numbers and the results are pretty impressive. Check out their full report for all the details, but this sums it up nicely:

According to our sources, the 3.0 beta still has some stability and speed issues, so that makes these results that much more impressive. While the overall average gives the iPhone 3.0 beta a 300 percent speed advantage, some of the individual tests show 6x, 8x, or even 11x improvements—the bitwise "AND" function even runs 16x faster than in the current version of Mobile Safari.

Should make the release version of the new, Nitro-powered Mobile Safari 3.0 fairly impressive, come summer! Bring on them multi-app Facebook pages, the iPhone will be ready! (Joking... a bit.)

We so fondly remember Palm's Roger McNamee stating the Pre would be a million times faster on the web than the iPhone (now retracted), and even our sister-site PreCentral.net jumped on that band wagon, saying the Pre looked to be 4x faster than the iPhone.

Of course, we mentioned that on Sprint, lacking simultaneous voice and data, even a million times zero is still zero. Less flippantly, however, when Safari 4 Beta shipped for the desktop with its new ultra-fast Nitro (formerly SquirrelFish) rendering engine, we figured it would only be a matter of time before that scaled down to the iPhone's version of Safari (based on the same WebKit foundations as desktop Safari, as is the Palm Pre browser and Android Chrome Lite).

Now Daring Fireball and Wayne Pan posit that turbo boost might have already happened in iPhone OS 3.0:

Wayne Pan has braved the NDA waters and published JavaScript benchmarks for iPhone OS 3.0, and they are impressive — with results ranging between 3× and 10× faster than iPhone OS 2.2. And I’ll confirm that MobileSafari on iPhone OS 3.0 passes my simple “could be Nitro” recursion depth test.

From what we've seen of 3.0, it seems that way to us as well. Along with HTML5, CSS, 2D and 3D animation, anti-phishing, AutoFill, etc., it will be interesting to see what Apple and the WebKit team can pull of by the time iPhone 3.0 launches this summer...

WebKit, the open source foundation behind Apple's Safari for Mac and MobileSafari on the iPhone (not to mention Google Chrome, Nokia, and Adobe) introduced the SquirrelFish JavaScript engine a while back, and billed it as the fastest on the planet. Then came Mozilla's (Firefox) TraceMonkey. Then came Google's V8. But you just can't keep a good SquirrelFish down -- not when it's willing to go... Extreme!

Surfin' Safari, the WebKit blog, made the announcement this week. But what does it mean for iPhone users? Muchfasterwebsiterendering.

As WebApp's (browser-based productivity tools like Google Docs and MobileMe, or Web 2.0 social sites like Facebook and Twitter) grow not only in popularity but in function, they become heavier to load and slower to run, largely because of all the JavaScript being processed in the background. This is especially true for a mobile device like the iPhone. The ability to tear through those pages -- without crashing! -- becomes incredibly important in the growing "cloud" based computing world.

In other words, this will make future versions of MobileSafari screaming fast.

Can we have it now please?

(For those interested in how SFX compares with TraceMonkey and V8, check out the stats!)

Dieter just told us about Crackberry Kevin's uber-frustrating experiences trying to pit the iPhone 3G and Blackberry Bold head to head in the browser war to end all browser wars. But -- silver lining -- for iPhone users, not only did we snag bragging rights, but a handy tip as well!

Unlike the Blackberry Bold, the iPhone defaults to having Javascript enabled. As anyone who's waited -- and waited -- for an overstuffed Facebook profile to load already knows, Javascript can be heavy lifting for a browser. For WebApps, it's a necessary sacrifice, but if all you want is casual browsing, you can turn Javascript off and send MobileSafari into turbo mode.

Here's how:

From the iPhone home screen, tap Settings. Scroll down and tap the Safari button. Under Security, slide Javascript to Off.

There you go, you've just switched to light, clean HTML and CSS mode (still technically "just the internet" -- unless you're in the UK...). In Crackberry.com's tests, it made a big difference on some sites. Let us know how it works for you!

(Thanks to Crackberry Kevin!)

After all the persistent questions about whether or not the BlackBerry Bold's improved browser could compete with the iPhone, our friend CrackBerry Kevin decided to try to provide the definitive, final smackdown.

Go on and read the entire saga, but take heed, it's not a pretty sight. Under ideal conditions, the Bold comes this close to competing with the iPhone on speed. Those idea conditions: 3G, Javascript off, strong signal, fresh reset, and WiFi off. Wait -- WiFi off? That's right, Kevin has two BlackBerry Bolds and both of them are five different kinds of screwed up -- they fail with Javascript off, they fail with WiFi entirely. Now -- not everybody is reporting the same hassles, but it's starting to look like it's a pretty serious problem.

The Javascript issue is very interesting, by the by. The iPhone defaults to leaving it on. One could argue that Javascript support helps make the iPhone able to browse the "Real Internet," but one would be wrong about what makes up the "Real Internet". The Bold, however, defaults to leaving Javascript off, and given Kevin's results, it looks like a good thing they did.

What does this mean for iPhone users -- besides bragging rights? Well, actually, bragging rights are enough for us. But there's another tip you're definitely going to be interested in, iPhone faithful. Can you guess it? Rene will let you know what it is very shortly.

If the next great future of computing in the Cloud, as many pundits -- not to mention Google -- think, then the next great race is delivering that future via Rich Internet Applications. Right now, there are two major ways of doing this. The first involves using a proprietary, locked in technology (admittedly with increasing "openness") like Adobe's Air/Flex/Flash trifecta, or Microsoft's .Net/Silverlight double team. The second is with truly open standards such as HTML, CSS, and AJAX (Asynchronous Javascript and XML) like Google, Yahoo, and many others use.

With the iPhone Apple has squarely planted itself in the second category. They even promoted them as a pseudo-SDK for a time! (And maybe gave up too soon?)

Flash-free, Silverlight-less, but full of interactivity and cloud-based applications, Apple just unleashed .Mac upgrade MobileMe complete with "desktop class" mail, calendar, contacts, and photo gallery web apps.

And according to this year's WWDC buzz, they used SproutCore's Javascript frameworks to do it? Why?

SproutCore not only makes it easy to build real applications for the web using menus, toolbars, drag and drop support, and foreign language localization, but it also provides a full Model View Controller application stack like Rails (and Cocoa), with bindings, key value observing, and view controls. It also exposes the latent features of JavaScript, including late binding, closures, and lambda functions. Developers will also appreciate tools for code documentation generation, fixtures, and unit testing. A key component of its clean MVC philosophy that roots SproutCore into Cocoa goodness is bindings, which allows developers to write JavaScript that automatically runs any time a property value changes. With bindings, very complex applications with highly consistent behavior can be created with very little “glue” code.

Check out the read link for more on Apple's use of SproutCore, and how it might just be part of a growing trend for open standards-based web interactivity.

Read