The pros and cons of Mozilla’s super-open Boot to Gecko mobile OS

Mozilla, the folks behind the Firefox web browser, launched a project last year to create a totally open mobile operating system, and now that dream is nearly a reality. Boot to Gecko (B2G) is built entirely with standards-compliant web technologies like HTML and JavaScript. It gets its name from the Gecko rendering engine in Firefox, which is also the platform that will run B2G. Android has a number of things in common with B2G, for instance it is open source, and uses some of the same underlying technology. Designing the entirety of a mobile operating system on web standards is a risky proposition, but B2G does have some advantages over Android.

Clearly in the “win” column for Mozilla is the multi-layered architecture of B2G. The lowest level is called Gonk, and includes the Linux kernel, hardware interface, and other low-level features. Next up is the Gecko rendering engine, and on top of that is Gaia. Mozilla has built Gaia to be the user interface layer, and it’s all HTML and JavaScript. This system is modular, and an OEM or developer is free to swap components out.

OEMs have definitely shown an interest in doing their own interface work with Android. Motorola, HTC, Samsung, and others have spent big on developing custom UIs for Google’s platform. B2G would make it fast and easy to build HTML and JavaScript canvases to replace the Gaia interface. Mozilla claims that it has an OEM partner that has already designed its own top interface layer, and will demo that at Mobile World Congress this month.

A drawback to the use of web standards is that it is still very hard to make a mobile web rendering engine feel native. On Android, web apps have always felt much less responsive than native ones, and that’s with the mobile-friendly WebKit engine. It’s hard to see how an entire UI run on Gecko could be fluid. Gecko in the mobile Firefox browser has always been a sluggish experience. Perhaps new APIs in B2G will make up for that by the time the product is ready for prime time.

The middle layer, the Linux kernel, is also a good call on Mozilla’s part. The Foundation has chosen to stick closely to the upstream Linux kernel, along with some framework elements from the AndroidOpen Source Project (AOSP). Not only is this a time-saver, but it makes it much easier to load B2G on existing Android hardware. There is already an early build of B2G that runs on the Galaxy S II.

B2G uses an open governance model, and all the source code is available. For open source advocates, this is a major selling-point of the platform. Android has taken heat at various times for being too closed. While Google releases most of the code to AOSP, the Google apps like Gmail, Market, and Maps are closed. The search giant uses these apps to exert some control over the direction Android takes, but B2G would have no such restrictions.

Apps are the lynch pin of any mobile platform, and the way Mozilla intends to go about that could be considered both a pro, and a con. The B2G developers have been working with the W3C to standardize around set of JavaScript APIs for rich web apps. Mozilla hopes to push web apps that feel native and work on all mobile browsers. It could be a long road to reach that level of performance, though. It might be a pipe dream, but if it works, such a system would be great for all smartphone users.

Mozilla is getting a start just as Android and iOS seem to be solidifying their lead. The modular, standards-based nature of B2G could attract some open source purists. Additionally, it’s hard not to admire Mozilla’s dedication to open web apps that everyone can use. Actually getting these technologies to feel native could be trouble, though. Gecko is also an unproven engine on mobile. Mozilla is set to reveal more details on B2G at Mobile World Congress this month, and we wouldn’t be surprised if it endeavors to answer some of these questions.

Read more at Ars Technica or Mozilla

Source

Open WebOS 1.0 announced

HP has officially announced that WebOS will be open sourced by September 2012. This is a marvelous thing for the WebOS community, and Palm fans everywhere. It’s step one in bringing WebOS back from the dead; hopefully a revitalizing shot in the arm of development, applications, and new hardware (we hope). HP is also looking at all existing WebOS hardware to figure out how to best move this out, so don’t throw away your Palm Pre or Pixi just yet.

As important as the announcement for WebOS itself is the announcement that Enyo, HP’s JavaScript framework for WebOS is getting a major overhaul into 2.0 and being open sourced as well; it is available as of today. This is key because unlike other mobile operating system frameworks, Enyo is not based on Webkit. As a browser-independent tool, it allows programmers to write code for WebOS applications that will function in Internet Explorer, Firefox, Chrome, and Safari. HP says that such a move to push WebOS beyond hardware will build an ecosystem, and everyone agrees that this would be a good thing.

As far as major changes to WebOS itself, the biggest is probably the switch over to the standard Linux kernel from the old custom kernel originally built by Palm. This will help enormously in empowering devs to write for a huge swath of existing hardware. Imagine a world where not only are devs putting Android on WebOS devices, but a world where the opposite is happening. Licensing is being moved to the Apache 2.0 set as soon as possible as well, to clear out any legal roadblocks.

Looking forward, WebOS may not be anymore prevalent in the mobile landscape as Linux is in the desktop space. But options are good, and this was a smart, excellent move by HP to open source WebOS and give tools like Enyo to the development community. WebOS deserved more than a flash in the pan, and perhaps it’ll get the limelight in some form down the road now that it’s on the way to resurrection.

Time will tell.

Read more at the HP Palm Blog

Source

SE Android released: Build your own NSA-approved Android device today

On January 6, the US National Security Agency (NSA) released the first public release of the Security Enhanced (SE) Android Project, a program designed to find and plug security holes and risks in the Android flavor of Linux. SE Android is based on the NSA’s SELinux, first released in 2000.

SELinux started as a string of security patches to the Linux kernel along with a few utilities to help with access control and damage confinement. One of the key differences between the base Linux kernel and SELinux is the switch to Mandatory Access Control (MAC), a change from the Discretionary Access Control (DAC), which allows users to elevate their permissions to run certain commands as if they were the root user of the system. MAC can be configured system-wide and only allows users minimum access required to do their jobs. This level of security keeps programs and daemons from causing more harm than they would normally be able to if they become compromised. Individual applications can also be “sandboxed,” which means they are kept away from other applications running, isolating them in case one becomes compromised.

As of the 2.6.0-test3 kernel, SELinux was compiled into the base Linux kernel, and no longer requires separate patches or updates. This merging occurred in August of 2003, and SELinux has also seen contributions from Network Associates, Secure Computing Corporation, Trusted Computer Solutions and Tresys.

SE Android was first publicly described at Linux Security Summit 2011. In essence, the NSA is attempting to bring the same access control and damage mitigation measures found in SELinux to the Android Open Source Project. In the Security Summit presentation, a number of known security vulnerabilities were demonstrated and tested against a version of Android running SE Android controls. All exploits failed unless specifically tailored to the particular system, and even in those cases the exploit’s effectiveness was much reduced.

Going forward, the SE Android Project team is looking to incorporate SE Android into Application Layer Security, so it is able to thwart unauthorized access and compromised programs at the application layer instead of only battling at the kernel level.

There’s a lot to do to get SE Android built into the current Android tree, but it certainly seems like the right way to go. With the explosion of applications in the Android market, and some question of why certain applications need access to user information such as the user’s contact list or the ability to access the internet or telephone application when it’s not a facet of the application itself, SE Android controls would be a welcome addition to security-minded Android users. Government entities may find a security-hardened mobile phone operating system enticing to use, as well.

The need for security on the internet and in the mobile space has never been more important. SE Android is looking to bridge the current gap between Android and a secure experience for always-connected communication devices. SE Android won’t make malware a thing of the past on its own, but it will certainly be a welcome edition in the fight against malicious hackers.

Read more about SE Android

Source