All posts tagged ‘mozilla’

File Under: Mobile

First Look: Mozilla’s Boot2Gecko Mobile Platform and Gaia UI

Mozilla launched a new project last year called Boot2Gecko (B2G) with the aim of developing a mobile operating system. The platform’s user interface and application stack will be built entirely with standards-based web technologies and will run on top of Gecko, the HTML rendering engine used in the Firefox web browser. The B2G project has advanced at a rapid pace this year and the platform is beginning to take shape.

The B2G team at Mozilla is preparing to give a demo of the platform’s user experience at the upcoming Mobile World Congress (MWC) event. Mozilla’s Brendan Eich told us via Twitter that the B2G project has already attracted partners, including one that is developing its own custom home screen. This suggests that multiple parties, possibly hardware vendors, are interested in adopting the platform.

According to a roadmap recently published by Mozilla, the B2G project could potentially reach the product stage by the second quarter of 2012. That’s a highly ambitious target, but the project’s impressive rate of development suggests that it can be done. The pervasive use of HTML and JavaScript to build the user interface and application stack is no doubt speeding the project along. Web technologies are very conducive to rapid development.

The B2G platform consists of three main layers. The bottom layer, which is called Gonk, includes the Linux kernel, the hardware abstraction layer, the telephony stack, and other low-level system components. The middle layer is the Gecko rendering engine, which has been improved with new APIs that expose device capabilities. The top layer is Gaia, the B2G user interface, which is built entirely with HTML and JavaScript.

The Linux kernel that is used in Gonk is said to be “reasonably close” to upstream Linux. According to Mozilla’s documentation, Gonk uses some of the underlying bits of the Android open source project, including some minor kernel customizations, in order to make it easier for hardware vendors to get B2G running on Android hardware. B2G is not based on Android, however, and will not run Android applications. It’s currently possible to replace the Android environment on a Samsung Galaxy S II with a B2G build.

Much of the interaction between the Gecko and Gonk layers will be mediated by a B2G process that runs with a high privilege level and acts as a sort of Gecko server. The B2G process will paint to the framebuffer and interact with hardware components like a built-in GPS antenna or camera.

The wireless modem functionality is implemented in a radio interface layer (RIL) daemon, which B2G will interact with through a simple proxy process. Actual web content and multimedia playback will be handled by separate processes that communicate with the B2G process.

Mozilla aims to build the entire B2G user interface and application stack with native HTML and JavaScript. In order to accomplish that, Mozilla launched the WebAPI project, which exposes device functionality to web content through JavaScript APIs. Mozilla has already previously introduced APIs for accessing certain device capabilities, such as the accelerometer and geolocation APIs that are supported in the mobile versions of Firefox.

The WebAPI project goes a step further and adds a great deal of additional functionality for tasks like taking pictures with the built-in camera, dialing the phone, accessing the device’s battery level and status, sending and managing SMS messages, accessing the user’s address book, and making a device vibrate. These capabilities are largely made accessible to web content through a set of JavaScript APIs. This means that the B2G dialer interface, for example, is just a web page that uses a JavaScript function to initiate a call.

Mozilla is working to standardize these APIs through the W3C Device APIs working group. In theory, the same underlying JavaScript APIs that are used to enable access to underlying platform features on B2G could eventually be supported natively in the default web browsers that ship with other platforms.

The standardization effort around device APIs is especially significant. If the APIs gain widespread adoption, it would make it possible for large portions of the B2G user experience and application stack (which are, essentially, just web content) to run in web browsers on other platforms. At that heart of Mozilla’s agenda for B2G is a vision of the future in which browser-based mobile applications, built with standards-based HTML and JavaScript, will be capable of doing everything that can be done today with the native mobile application development frameworks.

Because B2G’s Gaia user interface layer is implemented in HTML and JavaScript, it can technically run in a regular desktop web browser. Of course, the device-related capabilities will only work when the content is run in an environment that has WebAPI support.

We tested the Gaia home screen user interface and several of the platform’s applications in a Firefox nightly build. All we had to do to get it running was download the code from the relevant GitHub repository and then open the homescreen.html file in Firefox.

When the page loads, the user will see the B2G lock screen, which displays the current date and time. The home screen interface can be accessed by dragging the lock screen up. The home screen displays a grid of application launchers and has a notification bar at the top. You can drag a notification slider down from the bar, much like the equivalent user interface element in Android.

B2G lock screen

If you look at the source code of the homescreen.html page, you will see that the contents of the interface, including the lock screen, are created with HTML div tags with some JavaScript code to handle interaction and populate the values. It’s quite simple and predictable web content.

The B2G home screen

Individual applications run inside of a frame in the homescreen interface. We tested several applications, including a dialer, a web browser, and a map application. Like the home screen, these are all implemented in HTML and CSS. The web browser is basically a web page with an HTML input element for the URL bar and an embedded iframe element where the page content loads.

B2G sample map application

B2G's Web browser. It's practically begging for a Yo Dawg joke

The B2G dialer

The current implementation of the Gaia environment is still simplistic and incomplete, but it offers a compelling demonstration of how conventional web content can be used to create a smartphone user experience. It’s possible to do anything in the B2G user interface that can be done with HTML and CSS, so the possibilities for styling and theming are prodigiously extensive. Such intrinsic flexibility could help make B2G appealing to hardware vendors because it would make it easier for them to create custom user interfaces that differentiate their products.

Mozilla hasn’t created an HTML-based widget toolkit for application development. The applications currently included in Gaia are just straight markup with CSS for design. It’s theoretically possible to use existing HTML widget toolkits in B2G, however, such as jQuery Mobile and Sencha Touch.

The B2G project is off to an impressive start. The underlying concept of bringing native application capabilities to the standards-based web technology stack is also tremendously compelling. It hints at the possibility that the open web could someday provide a unified application platform for mobile devices.

It’s also worth noting that the project is entirely open. As Eich pointed out to us yesterday in response to our coverage of Open webOS, the B2G project has had open governance and public source code since its first day. B2G also benefits from Mozilla’s engineering talent and potential partners. The B2G platform has an opportunity to bring positive disruption to the mobile landscape and be a serious contender.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

File Under: Browsers

Why Google Continues to Fund Firefox

Just before the holiday weekend Mozilla announced that it had renewed its long-standing search revenue agreement with Google, which will reportedly net Mozilla $300 million a year (as part of a three-year contract). The renewed contract comprises the bulk of Mozilla’s funding and is unquestionably a good deal for Mozilla. What’s less immediately clear is why Google — which now has its own Chrome browser — would want to continue the deal.

Indeed, why fund the competition? M.G. Siegler speculates (based on AllThingsD’s report that there was a bidding war over Mozilla) that Google is willing to spend that kind of money just to keep Microsoft from starting a partnership with Mozilla.

That’s one theory. But it may well be that the truth is much more mundane. It may be that Mozilla is just one of a number of payouts that Google makes to help drive ad sales.

In fact, as Mozilla’s Asa Dotzler points out, Google pays out roughly 24 percent of its ad revenues to drive more traffic to its ads:

Not all traffic to Google ads is “organic” though. To help drive ad sales, Google pays for traffic to their ads. They paid out $2.21 billion, or 24% of their ad revenues in “Traffic Acquisition Costs”. That money goes to revenue shares with their AdSense partners and to “distribution partners” — presumably browser makers, PC OEMs, and mobile OEMs and operators.

As Dotzler goes on to point out Google pays out similar money to Opera and Apple, which both use Google as the default search engine in their respective browsers — again, driving eyeballs to Google ads. Dotzler’s point being that the Google-Mozilla deal is not a charitable arrangement, but a business deal built around driving eyeballs to Google ads. Firefox currently holds roughly 25 percent of the global browser market, which is certainly a healthy number of eyeballs..

Of course it’s possible that other factors may also influence Google’s decisions. Google Chrome developer Peter Kasting says that Google’s motivation for building Chrome is to “make the web advance as much and as quickly as possible.” That means, according to Kasting, that “it’s completely irrelevant to this goal whether Chrome actually gains tons of users or whether instead the web advances because the other browser vendors step up their game and produce far better browsers.” In other words, funding Firefox helps to further the same goal that drove the company to build Chrome in the first place — advancing the web.

That would be somewhat easier to swallow if other parts of the Google machine didn’t build so many experiments that only work in Chrome.

Regardless of Google’s motivation for building Chrome, or for funding Mozilla, both moves have proved great news for users. And in the end the precise motivation behind the Google-Mozilla deal are something only tech writers really care about. Users care about speed and there’s no question that Chrome has helped spawned a renaissance among web browsers and helped put speed back on top of every browser makers’ to-do list (the drive to adopt HTML5 has also done wonders to improve the average user’s experience on the web).

For most users the Mozilla-Google deal just means that there will continue to be a number of browsers to choose from and a number of browsers to help keep pushing the web, and each other, forward.

File Under: Browsers, Web Services

Google, Mozilla Team Up to Create a Smarter, Action-Based Web

Google has announced a new set of APIs for its Chrome web browser, which are designed to connect applications and sites across the web. Web Intents, as Google is calling its new meta-website API, allows websites to pass data between each other — for example, to edit a photograph or share a URL with friends.

Developers at Mozilla have been working on a similar framework for Firefox, and now Google says it will work with Mozilla to develop a single API that works in both web browsers.

The Web Intents API was originally conceived by Paul Kinlan last year. Kinlan, who is a Chrome Developer Advocate at Google, borrowed the idea from the Android platform, which uses Android Intents to pass data between Android Apps.

So just what are Web Intents? Well, the easiest way to understand them is by example. Take the sometimes overwhelming proliferation of buttons on web pages that allow you to do something with the current page, whether it’s Like, Tweet, +1, Read Later, Add to Instapaper and so on. Rather than adding a dozen little badges to your site, Web Intents creates a bridge that connects your site to any website your visitor wants to use. Web Intents define an API for your site to use and another API for the receiving site to use. Plug them together and transferring data becomes a quick and easy process, both for users and developers.

That’s a huge step up from the situation today. Perhaps the biggest win is that Web Intents put your visitors in control — they can select which actions they’d like to perform and which external sites they’d like to handle those actions. Some might share your page on Facebook, others on Twitter, still others might save it to their Instapaper account and so on, all from the same three lines of code you added to your site.

That’s not, however, all that Web Intents can do. The broader goal of Web Intents is to provide a generic means of communication between websites for tasks as varied as editing photos, listening to music or shortening URLs.

The second half of the video below demonstrates Mozilla’s take on how Web Intents ("Web Activities" in Mozilla’s parlance) might work.

For some sample code and working examples, head over to the new WebIntents.org site and check out the examples (the image example is particularly good at showing off the potential power of Web Intents).

For some more background on Web Intents, check out Paul Kinlan’s blog, particularly his overview post on the brief history of Web Intents. Tantek Çelik, the creator of microformats, also has a nice post on what he calls Web Actions (same thing, better name). Çelik breaks down the idea behind Web Intents and how they benefit not just developers, but users as well.

As Çelik writes, "web actions have the potential to change our very notions of what a web application is from a single site to loosely coupled interactions across multiple, distributed sites…. In that regard, web actions have the potential to become a building block for distributed web applications."

Image: Aidan Jones/CC/Flickr

See Also:

Mozilla Eyes Mobile OS Landscape With New Boot to Gecko Project

Mozilla has announced a new experimental project called Boot to Gecko (B2G) with the aim of developing an operating system that emphasizes standards-based Web technologies. The initial focus will be on delivering a software environment for handheld devices such as smartphones.

The current mobile landscape is heavily fragmented by the lack of interoperability between each of the siloed platforms. Mozilla says that B2G is motivated by a desire to demonstrate that the standards-based open Web has the potential to be a competitive alternative to the existing single-vendor application development stacks offered by the dominant mobile operating systems.

The project is still at the earliest stages of planning. Mozilla has some ideas about how it wants to proceed, but seemingly few concrete decisions have been made about where to start and what existing technologies to use. The project was announced now despite the lack of clarity so that contributors will be able to participate in the planning process.

Mozilla also intends to publish the source code as it is developed rather than waiting until it can release a mature product. These characteristics could make the development process a lot more open and inclusive than the practices that Google uses for its Android operating system.

Mozilla’s current tentative plan is to adopt a slim layer of existing code from the lower levels of the Android operating system for hardware enablement purposes and then build a completely custom user interface and application stack around Gecko, the Firefox HTML rendering engine. Android was chosen because it will theoretically offer compatibility with existing hardware, but Mozilla ultimately intends to use “as little of Android as possible.” It will not use Android’s Java-based environment and it will not support programming in native code.

A foundational goal of the B2G project is to explore and remedy areas where current Web standards are insufficient for building modern mobile applications. Instead of haphazardly grafting vendor-specific markup or extensions into the application runtime, Mozilla will seek to propose new standards to address the challenges that emerge during development. It wants the applications developed for B2G to eventually be able to run normally in any conventional standards-compliant Web browser (yes, that presumably rules out XUL).

Building an operating system seems like an excessive approach to fulfilling the stated goals of the B2G project. It would be simpler and much more straightforward to focus on building a standalone Web application runtime—like an open alternative to Adobe AIR—rather than building a complete operating system from the bottom up.

There are a lot of fundamental issues that make developing software with Web technologies less practical than using conventional user interface toolkits. HTML’s document-centric approach to layout and the lack of standardized mechanisms for binding programmatic data models to user interface views pose many challenges. It’s not really clear if Mozilla is interested in addressing those issues or will continue to leave that as an exercise for third-party JavaScript toolkits.

It seems like the areas where Mozilla is interested in pursuing new standards are basic platform integration and access to hardware. It wants to have uniform and predictable ways for Web applications to access a platform’s contact and messaging capabilities, geolocation functionality, cameras, and dialer.

Of course, Mozilla is also interested in tackling some the issues relating to security and privilege management that are implied by giving Web applications such deep access to underlying platform components. Those areas are, perhaps, where building the whole operating system becomes advantageous.

There are a number of existing products and open source software projects like Titanium, PhoneGap, Webian, Chrome OS, and webOS that cover some of the same ground. None, however, really have the same scope and focus as B2G. It’s possible that there are some opportunities for collaboration.

A code repository is hosted on GitHub, but doesn’t have anything yet besides a README file. For some additional information about the project (there aren’t many details yet) you can refer to the B2G wiki page.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

File Under: Identity, Web Standards

New Privacy Icons Aim to Save You From Yourself

A few of the proposed privacy icons

Mozilla has taken the lead among browser vendors to make a site’s privacy settings more explicitly visible. It’s doing so by proposing visual cues in the browser that indicate what level of privacy you’re currently browsing at, and what pieces of your personal data the site you’re currently visiting is sharing with the rest of the web.

Earlier this year, Mozilla’s head user experience designer Aza Raskin proposed creating a set of icons to denote the privacy policy of a website. Now, after getting feedback from a wide range of interested groups — from the Electronic Frontier Foundation to the Federal Trade Commission — Raskin has drawn up a new and improved icon set.

The idea behind Raskin’s proposal is that the browser is the most logical place to display identity and privacy information to the user as they click around on the social web. The end goal is to produce a set for warnings similar to the way that Firefox (and other browsers) currently handle phishing attack warnings, using visual icons and simple language to explain what you’re getting into when you load a page with a different level of privacy or security.

For the active social web user, keeping track of which bits of your data are public and which are private on different sites is a chore. Some websites share your photos, status updates, your list of friends, who you’re following and other data default. Some share nothing. The rest are somewhere in the middle.

Part of the problem is the privacy policies themselves. They are complex, mind-numbingly long legal documents. We routinely ignore them, breezing past them by clicking “I agree.” Once clicked, your rights are compromised, and you may not be able to fully restore them.

A set of icons in the browser, to quickly and easily allow users to know what will happen to their data, means that users don’t need a law degree to know what’s happening to their images, status updates and other data.

The big difference between privacy icons and the phishing warnings your browser already offers, is that these icons are targeted at the websites themselves. The biggest counter-argument to Raskin’s proposal is that there’s nothing stopping a site from displaying these icons and then doing the opposite.

Raskin’s solution is to make the privacy icons supersede the written privacy policy. “When you add a Privacy Icon to your privacy policy,” writes Raskin, “it says the equivalent of ‘No matter what the rest of this privacy policy says, the following is true and preempts anything else in this document…’”

In other words, sites using the icons maliciously would face legal consequences. Of course differences in international laws mean enforcing such violations would be complex.

Still, as Raskin points out, privacy policies are fast becoming a selling point for many sites. Nearly every site we’ve tested lately has some sort of large, obvious banner that proudly proclaims the site will never share your data. Those are the kinds of sites, says Raskin, that would adopt privacy icons.

But it’s still unlikely any site would ever adopt the negative icons. If you’re sharing everything users give you with anyone who pays for it, you probably don’t want to advertise that. So the privacy icons actually become most useful when they aren’t present. Of course, as Raskin writes, “people don’t generally don’t notice an absence; just a presence.”

The solution to that problem is to make the privacy icons machine readable. The workflow would be something like this: You visit a website and decide to sign up. When Firefox encounters the sign-up form, it looks for the privacy icon. If it finds it, Firefox displays it. If Firefox doesn’t see an icon it warns you that your information may be shared using the negative icon. Either way, you know where you stand.

For now the privacy icons, good idea though they may be, are a long way from reality. Raskin calls the current mockups an “alpha” release and since Raskin is leaving Mozilla, the future of the project is unclear. If you’d like to get involved, head over the Mozilla Drumbeat Privacy Icons project page.

See Also: