Well this is an interesting feature. Mozilla, like all browser vendors, has been constantly enhancing their web development tools. They are quite impressive, allowing anyone to debug any page, including WebGL shader replacement, audio network manipulation, and injecting Javascript, HTML, and CSS at run time. Firefox OS and Firefox for Android developers were even able to remotely connect to a desktop Firefox browser as if it were an IDE (which it really is these days). Today, Mozilla announced (via their Hacks blog) early support for remote debugging Safari on iOS and Google Chrome on Android.

The currently supported tools are: "Inspector", which allows searching, modifying, and injecting HTML and CSS; "Debugger", which debugs and injects Javascript; and "Console", which displays console output from the open tab and executes individual Javascript statements (which can be multi-line with shift + enter). You cannot, for instance, modify individual draw calls on a running 3D game, like you can with the same tools when manipulating a Firefox tab, but this is still pretty impressive for cross-vendor.

Remote Debugging for Safari on iOS and Chrome on Android is available in early development on Firefox Nightly with an optional extension.

Google has announced that the latest beta for Chrome, their web browser, will compile Javascript in a background thread. In the current release version, scripts are converted to instructions, executed, monitored for performance, and swapped with a more optimized set of instructions that accomplishes the same tasks. Converting script into optimized instructions takes time. Doing it on a background thread frees up that computation time for something else.

This stutter was 628 milliseconds, or about 38 consecutive frames at 60 FPS.

Image Credit: Chromium Project Blog

Web browsers are designed under the assumption that a single thread of instructions will weave through every task, one by one, until everything is done. At some point, since the early 1990s, computers have been give multiple cores (and some of those designs can have multiple threads shoved through at once). The problem is now that, since "Task A" was designed to occur before "Task B", doing them separately... can break stuff good.

Background Javascript optimization will be most effective for mobile SoCs. These processors tend to have a lot of fairly slow cores; the exact opposite of what a web browser wants. Also, video games have many tasks which occur every frame. Freeing up time on the main thread gives these apps more time to be more complex - and with less stutter (if optimizing blocks execution... which it is trying to optimize). This might also allow browsers more time to try more aggressive optimization strategies.

In case you are wondering, Mozilla started to move compilation to a background thread as of Firefox 21. Firefox 29 will move the entire just-in-time (JIT) compilation process off the main thread. This is currently in their "Aurora" release channel. To the rest of the world: it's an alpha.

Later this week, Google is updating its Glass, well, glasses to add new features. Among the new features, Google is including a full web browser and a couple of new voice controls.

The full web browser will output to the Glass display and can be accessed by hitting the appropriate button. Users will be able to access the web using the Wi-Fi chip, and it will be controlled by the touchpad and motion controls. For example, users can scroll pages by moving a single finger forward on the touchpad. Zooming is handled by using a two finger guesture on the touchpad. Finally, while zoomed in, users can move their head around to pan around the page.

The motion control bit is actually an intuitive idea, though I expect bystanders will find those browsing the web on their Glass a bit odd as they hold two fingers to their glasses and move their head about. (Hopefully people do not try browsing reddit while walking, however.)

The upcoming Google Glass update also adds a few more voice controls to the mix. Using voice commands beginning with "ok glass," users will be able to reply to text messages, answer calls, and send photos to other people on their contact list.

Finally, Google has lifted the contact list restriction from a list of ten friends. Users can now access their entire Gmail contact list.

I'm glad that Google is continuing to improve the Glass software. According to The Verge, this new update will be rolled out over the next few days to the Explorer Edition units currently in the hands of developers. I'm looking forward to the final consumer release.

If you consider your browser security based solely on whether it will allow you to manually download a malicious executable: IE10 is the best browser ever!

Rod Trent over at Windows IT Pro seems to believe this when NSS labs released their report, "Socially Engineered Malware Blocking". In this report, Internet Explorer blocked the user from downloading nearly all known malware (clarification: all known malware within the test). Google Chrome came in second place with a little less than 17% fail rate and the other browsers were quite far behind with approximately a 90% failure rate.

Based on that one metric alone, Rod Trent used a cutesy chess image to proclaim IE the... king... of the hill. Not only that, he suggests Safari, Opera, and Firefox consider "shuttering their doors." After about a decade of Internet Explorer suffering from countless different and unique vectors of exploitation, now is the time to proclaim a victor for attacks which require explicit user action?

Buckle in, readers, it's a rant.

Firstly, this reminds me a little bit of Microsoft Security Essentials. Personally, I use it, because it provides enough protection for me. Unlike its competitors, MSE has next to no false positives because almost ignores zero-day exploits. The AV package drew criticism from lab tests which test zero-day exploits. Microsoft Security Essentials was ranked second-worst by this metric.

But while we are on the topic of false positives, how do you weigh those in your grading of a browser? According to the report, and common sense, achieving pure success in this metric is dead simple if you permit your browser to simply block every download, good or bad.

If a 100% false positive acceptance rate is acceptable, it is trivial to protect users from all malicious download. With just a few lines of code, Firefox, Safari, and Opera could displace Internet Explorer and Chrome as the leaders of protection against socially engineered malware. However, describing every download as "malicious" would break the internet. Finding a balance between accuracy and safety is the challenge for browsers at the front of protection technology.

A browser that is capable of blocking malware without blocking legitimate content would certainly be applause-worthy. I guess time will tell whether Internet Explorer 10 is able to walk the balance, or whether it will just be a nuisance like the first implementations of UAC.

Now to be fair, Internet Explorer 10 and later have been doing things right. I am glad to see Microsoft support standards and push for an open web after so many years. This feature helps protect users from their own complacency.

Still, be careful when you call checkmate: some places may forfeit your credibility.

The Khronos Group recently announced that the WebGL 1.0.1 specification is compliant across mobile and desktop systems on a number of platforms. Chrome 25 and Firefox 19 support WebGL 1.0.1 on Windows, Mac, and Linux operating systems. Further, mobile devices with Tegra SoCs can tap into WebGL using a WebGL-enhanced Android browser.

Additionally, the WebGL 1.0.2 specification and its extensions have been submitted for ratification, and is expected to be formally released in April. According to the press release, the following features are being rolled into the WebGL 1.0.2 specification:

"adds many clarifications for specification behavioral precision

mandates support for certain combinations of framebuffer formats, to ease developer adoption;

clarifies interactions with the encompassing HTML5 platform, including the browser compositor and high-DPI displays;

dramatically increases the number of conformance tests to roughly 21,000 to improve both the breadth and depth of test coverage - thanks principally to work by Gregg Tavares at Google and the OpenGL ES working group."

The WebGL working group has also submitted several optional extensions for ratifications along with the 1.0.2 spec. On the developer side of things is a JavaScript debugger for WebGL API calls and shaders, and functionality to communicate when a mobile device is powered off while WebGL is running. The other extension deals with adding additional 3D features from OpenGL ES 2.0 including anisotropic filtering (AF), vertex array objects, and standard derivative functions.

Khronos President and NVIDIA Vice President of Mobile Content Neil Trevett stated that "The close cooperation between browser and silicon vendors to ensure the GPU is being reliably and securely exposed to the Web is ongoing proof that Khronos is a highly productive forum to evolve this vital Web standard." Meanwhile, WebGL Working group chair Ken Russell indicated that WebGL 1.0.2 is "a major milestone in bringing the power of the GPU to the Web.”

Although there are security concerns to consider, WebGL does open up some interesting opportunities for new web services. The full press release can be found here.

Chrome for Android will allegedly be getting a speed boost thanks to a new SPDY-assisted proxy service. If a recent patch is any indication, future versions of Chrome may adopt a proxy service similar to Opera Turbo, Amazon Silk, or BlackBerry Proxy. Google would take advantage of its SPDY protocol to compress and multiplex web sites. We requests would be sent through Google, where Google would take the HTTP/HTTPS pages, compress and otherwise optimize them, and send them to your Android smartphone.

While on Wi-Fi or a wired connection, the performance merits of such proxy services are minimal at best (and at worst can actually slow down page loads). With that said, over a mobile network--especially if you are living in an area with (at best) 3G speeds, the new SPDY proxy service could make a huge difference in page load times. If my experiences using Opera and its Turbo proxy service over a 3G connection for the past month is any indication of the potential benefits of such a setup, some pages will load much faster, a few sites will actually load slower than browsing without the proxy, and the majority of websites will fall somewhere in between those two extremes, providing a slightly faster web browsing experience. Google may be taking things a step further by introducing its SPDY protocol to speed up the HTTP requests, which is an interesting tactic beyond the basic compression and/or caching that the existing alternatives employ.

Details on the hinted-at Google-run SPDY proxy service are scarce, but I hope that it holds true. There are some privacy considerations, but if you are just reading articles and have resigned yourself to the fact that Chrome/Google tracks you anyway (heh) it is a nice optional feature to have!

Net Market Share has released statistics on the state of browser market share as of last month (February 2013). The numbers indicate that Internet Explorer is still the dominant browser on the desktop, with Firefox and Chrome coming in second and third place respecitvely. Interesting, the situation is reversed on the mobile front, with Internet Explorer being greatly surpased by Apple’s Safari in the top spot.

On the desktop browser front, Internet Explorer experienced year over year growth to 55.52% in February 2013. Firefox market share remained fairly stable YoY, ending up with 20.12%. Further, Chrome saw a slight YoY decline to 16.27%. Additionally, Safari and Opera sustained 5.42% and 1.82% market share in February 2013. Both browsers’ slice of the market remained fairly stable throughout the year. It will be interesting to see if Opera’s switch to WebKit will net the browser additional market share (RIP Presto).

Ars Technica further compiled charts on the specific browser versions used. While the majority of IE users are running version 8 and 9 (with IE 6 sadly being the thrid most popular version), Chrome and Firefox users are spread out fairly evenly between the different versions. That may have more to do with Chrome and Firefox’s accelerated versioning/updating though.

For mobile, Apple’s Safari browser leads the pack with 55.41% as of February 2013, which is surprisingly a YoY decline. Meanwhile, the stock Android web browser gained ground throughout the year, ending up with a market share of 22.85%. Opera Mini came in third place with 12.72% market share. Other interesting numbers include Chrome with 1.96%, Internet Explorer (mobile) with 1.58%, and BlackBerry with 0.96%. Further, Symbian has 1.37% market share, which puts it above BlackBerry and just under Internet Explorer. Not bad for a dying mobile OS!

I was fairly surprised by the Internet Explorer numbers, but when taking into account work machines and Windows’ dominance (and users that generally use the default browser--power users excluded of course) I suppose it makes sense. I do wish that the IE6 numbers would fall a bit more though, even it if it just users moving to a newer version of IE.

Mozilla recently rolled out Firefox 19 to its stable browser channel, bringing several new features and bug fixes to the masses. The most prominent new feature is a new built-in PDF reader that is now enabled by default. Using the PDF.js javascript libraries, the reader converts PDF files into HTML5 web pages. It is nice to see Mozilla incorporating the reader in the browser by default, eliminating the need for users to use Adobe Reader or other browser plug-ins (like this one we covered previously).

Additionally, Mozilla has fixed several bugs and improved performance. The browser will now start-up more quickly than previous versions, and a WebGL drawing operation error has been corrected, for example. Further, Firefox 19 now recognizes more CSS features including @page and support for fixed-width text transformations. A new debugger has also been added to Firefox 19, which should help add-on developers test their code. Also in interesting news, mobile users running Firefox for Android will also be pleased to know that Mozilla has relaxed the CPU clockspeed requirement to a mere 600 MHz–allowing the mobile browser to run on even more Android devices.

Mozilla executives working for the foundation behind the Firefox web browser today announced that they would be giving in to the H.264 codec as the open WebM VP8 codec has lost the war. The H.264 and VP8 (part of WebM) codecs are used to encode and decode video files, and are especially important on mobile devices as Flash support is less ubiquitous (or totally absent if you're using Apple products). In the absense of flash, the web turned to the HTML5 standard which provides <code><video></code> tags that allow direct embedding of videos into websites. Also important is that H.264 has wide support for being hardware accelerated on many mobile devices, enabling smart phones to smoothly playback high quality files that the low power CPU portion of ARM SoCs would otherwise struggle with. This situation is also available to desktop users, but is less of an issue as processing power is not as scarce and can, ah, accommodate Adobe's Flash plugin (heh).

The downside, and where all the controversy arises from, is that the H.264 codec is not free and requires manufacturers or sites that stream H.264 videos for a fee to license it as well as users, though the actual cost for licensing is generally rolled into the cost of the OS, device, or other piece of purchased software. Further, because the HTML5 standard does not specifically define a set video codec, there is room for fragmentation. Adobe, Mozilla, and Google eventually would jump behind what is now known as the WebM standard, which is an open (and free) video codec (VP8) that would not require expensive licensing restrictions. On the other hand, Apple backed the H.264 standard. Mozilla would roll WebM into their browser but not H.264, meaning that users could view HTML5 videos using Firefox but not HTML5 videos encoded with the H.264 codec. Google, Apple, and Microsoft would support the H.264 codec for HTML5 videos, despite Google developing WebM (and the included VP8 video codec) and giving word of mouth support for WebM. This meant that Chrome users could view both WebM and H.264 based HTML5 video.

According to the article, Google promised to drop support for H.264 and move solely to the WebM VP8 codec to entice websites to move to the open codec. Unfortunately, the company never came through with that promise, and has continued to offer dual support while Mozilla was left holding the open source support banner and causing their users to suffer as a result. The article references a study by MeFeedia that suggests that as of December 2011, H.264 based HTML5 video accounts for 80% of the market, implying that WebM has already lost the war. Brendan Eich, Mozilla's Chief Technology Officer noted that WebM needed support from a larger entity than Mozilla, and it needed that support in the beginning. Especially with Apple heralding H.264, for mobile site publishers, WebM really needed heavy backing to compete with Apple's market share and influential support of H.264 to have a chance. He further stated that:

"it might not have worked then, even with Google on-side. Now, with just Mozilla going it alone, all we do is kill our mobile initiatives in order to appear pure...That does not serve our mission or users."

Mozilla is now looking to support H.264, if a bit grudgingly. At this point, not supporting H.264 is only hurting their users and market share and not furthering their push for WebM. After all, if users are forced to look at other browsers just to play videos, it will not be WebM that is the only open source software forgotten (rather, the entire Mozilla web browser will wain).

Granted, Google is not the only company to blame for VP8 not catching on, Adobe also failed to properly push the codec. Also, Google is allegedly continuing to develop VP8 and WebM. Right now; however, losing Mozilla's support seems to be the final nail in the WebM coffin and the recognition that H.264 is the dominant format. More information is available here.