Tag Archives: safari

development, gaming, google, open source, professional, qt, software development

Google Native Client: browser apps unleashed, or misconceived and likely to fail?

6 Comments

Last week Google integrated Native Client into the beta of Chrome 14. Native client lets you compile C/C++ code to run in the browser. It depends on a new plug-in API called Pepper. These are open source projects sponsored by Google and implemented in the Chrome browser, and therefore also likely to turn up in Chrome OS which is an operating system in which all apps run in the browser.

Native Client is cool. For example, NaCLBox lets you run old DOS games in the browser by porting DOSBox to Native Client.

image

Another project is Qt for Google Native Client, a project currently in development. Qt is an excellent and popular GUI and application framework which would speed development of Native Client apps as well as enabling many existing applications to be ported.

It is also worth mentioning that Native Client provides another way to run .NET code in the browser, via Mono with NaCl support.

Why Native Client? Google’s vision, or at least the part of it that focuses on Chrome OS rather than Android, is that everything runs on the Internet and in the browser, making the local operating system unimportant and easily replaced. Native Client removes any performance compromises in managed languages such as JavaScript, ActionScript or Java, as well as easing migration for businesses with existing C/C++ code.

Writing native code for the browser is nothing new. Both Microsoft’s ActiveX and the NPAPI plug-in API used by non-Microsoft browsers let you extend the browser with native code. However Native Client is seamless for the user; you do not have to install any additional plug-in. The main limitation is that Native Client applets do not have access to the local operating system, for security reasons.

It is also worth noting that Native Client apps are not altogether cross-platform. They must be recompiled for different CPU instruction sets, with the current implementation supporting x86 and ARM though you have to compile two binaries. Google says it will support LLVM output to enable cross-platform binaries though this will impact performance.

But is Native Client secure? That is an open question. Google was aware of the security challenge from the beginning of the project. Unlike the plug-in mechanisms which rely mainly on trust in developer competence and signed code to verify the origin of the plug-in or ActiveX control, Native Client inspects the actual code for unsafe instructions before allowing it to run. There is also an “outer sandbox” which intercepts system calls.

However, adding any new way for code to run makes the browser less secure. Google ran a Native Client Security Contest to help identify vulnerabilities, and the contestants did not have any problem finding security flaws. Of course all of these discovered flaws will have been fixed, but there may be others and likely will be.

And is Native Client necessary? The latest JIT-compiled JavaScript engines are fast enough to enable most types of application to run at a satisfactory speed. This is not just about performance though; it is about reusing existing skills, libraries and applications. There is no doubt that Native Client is nice to have; whether its benefits outweigh the risks is harder to judge.

The last question, which may prove the most significant, is political. Google has forged ahead on its own with Native Client, saying as vendors always do that it hopes it will become a web standard. In the early days of the project, it looked like a Native Client plug-in might enable the feature in other browsers, but abandoning NPAPI for Pepper makes this difficult. Will other browser vendors support Native Client?

Here is a comment from Google’s Ian NI-Lewis that I find remarkable:

As you probably know, the rule in Web standards is "implementation wins." So we’re concentrating on getting a good quality implementation out the door. We’re doing that in Chrome. That doesn’t mean that NaCl is intended to be "Chrome only," just that we have to start somewhere.

So Native Client is non-standard, and therefore less interesting than HTML 5 until either Google has a Microsoft-Office-like de facto monopoly of web browsers, or it persuades Mozilla, Microsoft and Apple to support it.

That said, you can think of Chrome as an installable runtime in the same way as the Java Virtual Machine or Adobe Flash, just a potentially more intrusive one. Here is our app, you have to install the free Chrome browser to use it. If this happens to any great extent, I can foresee other browser makers hastening to support it.

apple, google, internet, mobile, web authoring

Mozilla CEO fearful of closed mobile platforms. So what next for Mozilla and Firefox?

3 Comments

What next for Mozilla? Tristan Nitot, president of Mozilla Europe, posts about some of the issues facing the open source browser project and Foundation. His list is not meant to be a list of problems for Mozilla exactly, but it does read a bit like that, especially the third point:

Google marketing budgets for Chrome are much larger than Mozilla’s annual revenue.

though he does not mention how much of Mozilla’s income actually comes from Google. The Foundation’s last published figures are from 2009, and show that most of Mozilla’s income is from deals with search providers, and while it is not specified, both common sense and evidence from previous years tells us that most of that is from Google.

Chrome is a mighty competitor on the PC, but here at least Mozilla has a large and established base of users. That is not so on mobile, and this is even more challenging, as Nitot notes:

In the mobile space, not all platforms enable the user to choose what Web browser to use. This trend may also be coming to the PC world with Chrome OS, which only runs Chrome.

He also refers to a recent interview in which CEO Ben Kovacs talks about why there is no Firefox for Apple iOS:

The biggest challenge is to get access to the lowest level of the device, these open platforms are not quite open, which is why we are worried about it, you don’t have the true open web.

He adds:

It frightens me, it frightens me from a user point of view, I am not allowed to choose.

It is hard to see how Safari will not always be the browser for iOS, and while Mozilla has better chances on Android, it is hard to see how Google’s stock browser will not always dominate there.

At a browser engine level, Mozilla has lost out to WebKit, which is used by Apple Safari, Google Chrome, RIM Playbook and HP WebOS. Microsoft’s Windows Phone 7 uses Internet Explorer.

What can Mozilla do? Well, it seems that Mozilla executives have in mind to go beyond the browser into the world of apps. Kovacs hints at this in the interview above. In another post, the Chair of the Foundation Mitchell Baker says:

… the browser is no longer the only way people access the Internet. People also use more focused “apps” to do discrete tasks, and often feel a strong sense of attachment to the apps and the app model. This is an exciting addition. Mozilla should embrace some aspects of the current app model in addition to the browser model.

Therefore we find Firefox Home in Apple’s App Store:

image

That said, it is not clear to me what sort of major contribution Mozilla can make in the app world, and the transition from browser company to app company would be a difficult one to pull off.

I cannot escape the thought that Mozilla’s time is passing. Its success was built not only on an excellent browser, but also on widespread dissatisfaction with Microsoft’s Internet Explorer and the stifling effect it was having on the progress of web standards. Firefox was a better browser, and gained disruptive momentum. In Germany Firefox currently has a 55% market share, according to Statcounter.

However, while Firefox is still a great desktop browser, Google and WebKit between them are now strongly advancing web standards, and even Microsoft is now talking up HTML 5. Mozilla has largely achieved its goal, leaving it now with an uncertain purpose.

It is good for web standards to have a powerful independent non-profit foundation, rather than having commercial giants like Google and Apple dominate, but in the end this has to be paid for either by a business model, or by sponsors. In this latter respect, IBM’s withdrawal of funding for Firebug author John Barton is not a good sign.

In retrospect, Mozilla was too slow to embrace mobile; but most of the developments which are now impacting the Foundation are outside its control. On a day when Apple has announced breathtaking profits, it is worth noting Kovacs remarks about the chilling effects of closed platforms on Mozilla’s work.

google, Web

Google Plus demands your location on iPhone, iPad and mobile devices – but you still have control

3 Comments

Last week I signed up for Google + (you can find me here), and one of first things I tried was to sign in on an Apple iPad.

I was annoyed to see the following message:

image

Google demanded the right to use my location with Google Plus, otherwise it would not let me sign in. But what if you want to use Google Plus without sharing your location with the world? Since Google Plus works fine on desktop PCs without location information, why should you not use it on an iPad in the same way?

This led me to investigate the W3C Geolocation API. In fact, I wrote my own web page to test how it works. I went over to Bing Maps, signed up for a developer account, and wrote a small amount of JavaScript to test it. You can try it here if you have a reasonably modern browser. I have not bothered to test for older browsers that do not support geolocation.

You will notice a couple of things about this test page. One is that it will ask your consent before attempting to retrieve your location. Another is that on a home broadband connection, it is rather inaccurate. According to Internet Explorer 9 I am in Berkhamsted – do not try and visit me there though, I am nowhere near.

image

However, if you try this on an iPad or other mobile device, you will likely get much better results. If I use the iPad, even on home wifi, it shows my house dead centre of the map.

That is only if you give consent though. Since Google + is a web application, this consent is determined by Safari, irrespective of what terms and conditions you agreed with Google. If it bothers you, you can even go to settings – location services and disable them for Safari completely:

image

That said, Google could add some code that tried to retrieve your location and would not let you use Google+ if access is denied – but it has not done so. In fact, so far the only time I have seen Safari prompt for consent in Google+ is when making a post:

image

If you agree, this allows Google+ to geotag your post.

I am sure there are other ways Google plans to use your location in Google+. For the moment though, if you would rather maintain location privacy Google+ still allows you do to do so.

apple, mobile, professional, software development, web authoring

Fast JavaScript engine in Apple iOS 4.3 is in standalone Safari only, but why?

3 Comments

Now that Apple iOS 4.3 is generally available for iPhone and iPad, users have noticed something that seems curious. The fast new “Nitro” JavaScript engine only works in the standalone Safari browser, not when a web app is pinned to the home screen, or when a web view is embedded into an app.

This link at mobilexweb.com shows the evidence. Here is the SunSpider test standalone, showing a time of 4098ms, and pinned to the home screen as an app, where it shows 10391.9ms:

image image

The consequence: apps created using WebKit as a runtime, for example using PhoneGap, will not get the benefit of Nitro.

It would be easy to conclude that Apple is deliberately hobbling these apps in order to protect native apps, which can only be installed via Apple’s App Store and are subject to its 30% cut. However that might not be the case. It could be a bug – according to Hacker News it has been reported as such:

To add another note to this, its a bug that Apple seems to know about. I can’t link to it because its marked CONFIDENTIAL across the top of the dev forums, but in short its known about and being investigated.

or it could be a security feature. Using a just-in-time compiler exposes the operating system more than just interpreting the code; perhaps Safari has more protection when running standalone.

Either way, with the increasing interest in WebKit as a de facto cross-platform application runtime for mobile, this particular limitation is unfortunate.

Update: There are also reports of the HTML 5 offline cache not working other than in full Safari:

I’ve tested this by switching apple-mobile-web-app-capable from ‘yes’ to ‘no’ and offline cache works as expected. But whenever it’s switched back to ‘yes’, it’s not working anymore. This occurs when the app is standalone at home screen. As a website, viewed with Safari cache is working as expected.

internet, microsoft, web authoring

Google Chrome usage growing fast; Apple ahead on mobile web

1 Comment

Looking at my browser stats for February one thing stands out: Google Chrome. The top five browsers are these:

  1. Internet Explorer 40.5%
  2. Firefox 34.1%
  3. Chrome 10.5%
  4. Safari 4.3%
  5. Opera 2.9%

Chrome usage has more than doubled in six months, on this site.

I don’t pretend this is representative of the web as a whole, though I suspect it is a good leading indicator because of the relatively technical readership. Note that although I post a lot about Microsoft, IE usage here is below that on the web as a whole. Here are the figures from NetMarketShare for February:

  1. Internet Explorer 61.58%
  2. Firefox 24.23%
  3. Chrome 5.61%
  4. Safari 4.45%
  5. Opera 2.35%

and from  statcounter:

  1. Internet Explorer 54.81%
  2. Firefox 31.29%
  3. Chrome 6.88%
  4. Safari 4.16%
  5. Opera 1.94%

There are sizeable variations (so distrust both), but similar trends: gradual decline for IE, Firefox growing slightly, Chrome growing dramatically. Safari I suspect tracks Mac usage closely, a little below because some Mac users use Firefox. Mobile is interesting too, here’s StatCounter:

  1. Opera 24.26
  2. iPhone 22.5
  3. Nokia 16.8
  4. Blackberry 11.29
  5. Android 6.27
  6. iTouch 10.87

Note that iPhone/iTouch would be top if combined. Note also the complete absence of IE: either Windows Mobile users don’t browse the web, or they use Opera to do so.

I’m most interested in how Chrome usage is gathering pace. There are implications for web applications, since Chrome has an exceptionally fast JavaScript engine. Firefox is fast too, but on my latest quick Sunspider test, Firefox 3.6 scored 998.2ms vs Chrome 4.0’s 588.4ms (lower is better). IE 8.0 is miserably slow on this of course; just for the record, 5075.2ms.

Why are people switching to Chrome? I’d suggest the following. First, it is quick and easy to install, and installs into the user’s home directory on Windows so does not require local administrative rights. Second, it starts in a blink, contributing to a positive impression. Third, Google is now promoting it vigorously – I frequently see it advertised. Finally, users just like it; it works as advertised, and generally does so quickly.

adobe, apple, internet, web authoring, windows

Adobe Flash getting faster on the Mac

1 Comment

According to Adobe CTO Kevin Lynch:

Flash Player on Windows has historically been faster than the Mac, and it is for the most part the same code running in Flash for each operating system. We have and continue to invest significant effort to make Mac OS optimizations to close this gap, and Apple has been helpful in working with us on this. Vector graphics rendering in Flash Player 10 now runs almost exactly the same in terms of CPU usage across Mac and Windows, which is due to this work. In Flash Player 10.1 we are moving to CoreAnimation, which will further reduce CPU usage and we believe will get us to the point where Mac will be faster than Windows for graphics rendering.

Video rendering is an area we are focusing more attention on — for example, today a 480p video on a 1.8 Ghz Mac Mini in Safari uses about 34% of CPU on Mac versus 16% on Windows (running in BootCamp on same hardware). With Flash Player 10.1, we are optimizing video rendering further on the Mac and expect to reduce CPU usage by half, bringing Mac and Windows closer to parity for video.

Also, there are variations depending on the browser as well as the OS — for example, on Windows, IE8 is able to run Flash about 20% faster than Firefox.

Many of us are not aware of these kinds of differences, because we live in one browser on one operating system, but the non-uniform performance of Flash helps to explain divergent opinions of its merits.

I would be interested to see a similar comparison for Linux, which I suspect would show significantly worse performance than on Windows or Mac.