Last year we proposed the Web Intents API to help web applications integrate with one another with minimal effort. We've now enabled an experimental version of the API in the most recent stable version of Chrome, to gather feedback from the web community and shape the future of the Web Intents API.



This prototype version of Web Intents makes it easier for developers to try out the API and experience its benefits first hand:

• Developers who build client apps will be able to easily include functionality from other web services (e.g., photo editing). 
• Developers creating those services will no longer need to invest time and resources to negotiate and build hardcoded integrations - they can just focus on offering a great quality product with the integration facilitated by the API. 

In addition, this implementation of Web Intents can help the design discussions in the W3C web intents open standards list. After all, it's impossible to build a complex API—especially one that requires an ecosystem of apps—without feedback from web developers using it in the wild.

We expect that Web Intents will evolve significantly, potentially in backwards-incompatible ways, as feedback from real world usage trickles in. Because of its experimental status, the current live version is prefixed and only allows applications to register as services in their Chrome Web Store app manifest.



Once the API is stable, we plan to remove this restriction.

To learn more on how to use the experimental Web Intents API check out the Web Developers' Guide to Web Intents in Chrome. If you choose to experiment with Web Intents, be sure to follow our discussion group, where we'll announce any impending breaking changes in Chrome's implementation.

Posted by James Hawkins, Software Engineer

As of current dev and beta channel releases, V8 uses a new algorithm based on counters to decide which functions to optimize. This greatly increases performance for small JavaScript programs. For example, on the SunSpider benchmark, which focuses on extremely short-running tests, V8's speed improved by about 25%.

When executing JavaScript, V8 at first compiles it to machine code with a very fast compiler that doesn't optimize the code it produces. V8 has a second, optimizing compiler that generates much faster machine code, but takes much more time to do so, so it has to be used selectively. That's why V8 must try to predict which functions will benefit most from optimization, and carefully decide when to optimize them.

In the past, V8 stopped once every millisecond to look at currently running functions, and eventually optimized them. For long-running programs, this worked great, but short-running programs often finished before they could benefit much from the optimizing compiler -- a single millisecond can be a long time to wait before optimizing! In addition, V8 often made different optimization decisions each time a JavaScript program ran, sometimes overlooking small but performance-critical functions.

The new version of V8 makes earlier and more repeatable optimization decisions by analyzing the running program in more detail. It uses counters to keep track of how often JavaScript functions are called and loops are executed in a program, approximating the time spent inside each function. That way V8 is able to quickly gather fine-grained information about performance bottlenecks in a JavaScript program, and to make sure that the optimizing compiler's efforts are spent on those functions that deserve it most.

The new algorithm is contained in the current beta channel releases -- go give it a spin now!

Posted by Jakob Kummerow, Software Engineer

Like with other multithreaded applications, debugging Web Workers may be a tricky task and having good instruments makes this process much easier. Chrome Developer Tools provides full debugging support for scripts running in both dedicated and shared workers.

You can now use the powerful Scripts, Timeline, Profiles and Console panels to develop Web Workers:



All dedicated workers running in the inspected page are listed in the Scripts panel, under the Workers section. Clicking on a worker URL will open a new Developer Tools window attached to the worker. If you need to debug a dedicated worker’s initialization, there is also an option to pause workers on start. This will suspend the execution in all starting dedicated workers at the very first statement.



Shared workers are more independent than dedicated ones as they can be used concurrently by several pages. All running shared workers can be discovered through the chrome://inspect page. Each shared worker listed there has inspect and terminate links next to its URL. These links allow you to launch a Developer Tools window attached to that worker or terminate the worker respectively.

When you need to debug a shared worker initialization, it is enough to terminate the current instance of the worker leaving the Developer Tools window open and reload one of the worker clients. The worker will restart and Developer Tools window will automatically re-attach to the new instance.

To learn more on Developer Tools check out our documentation or ask us a question on Google+ and our discussion group.

Posted by Yury Semikhatsky, Software Engineer

Web browsers are big, complicated pieces of software that are extremely difficult to secure. In the case of Chrome, it’s an even more interesting challenge as we contend with a codebase that evolves at a blisteringly fast pace. All of this means that we need to move very quickly to keep up, and one of the ways we do so is with a scaled out fuzzing infrastructure.

Chrome’s fuzzing infrastructure (affectionately named "ClusterFuzz") is built on top of a cluster of several hundred virtual machines running approximately six-thousand simultaneous Chrome instances. ClusterFuzz automatically grabs the most current Chrome LKGR (Last Known Good Revision), and hammers away at it to the tune of around fifty-million test cases a day. That capacity has roughly quadrupled since the system’s inception, and we plan to quadruple it again over the next few weeks.

With that kind of volume, we’d be overloaded if we just automated the test case generation and crash detection. That’s why we’ve automated the entire fuzzing pipeline, including the following processes:

• Managing test cases and infrastructure - To run at maximum capacity we need to generate a constant stream of test cases, distribute them across thousands of Chrome instances running on hundreds of virtual machines, and track the results.
• Analyzing crashes - The only crashes we care about for security purposes are the exploitable ones. So we use Address Sanitizer to instrument our Chrome binaries and provide detailed reports on potentially exploitable crashes.
• Minimizing test cases - Fuzzer test cases are often very large files—usually as much as several hundred kilobytes each. So we take the generated test cases and distill them down to the few, essential pieces that actually trigger the crash.
• Identifying regressions - The first step in getting a crash fixed is figuring out where it is and who should fix it. So this phase tracks the crash down to the range of changes that introduced it.
• Verifying fixes - In order to verify when a crash is actually fixed, which we run the open crash cases against each new LKGR build.

In addition to manageability, this level of scale and automation provides a very important additional benefit. By aggressively tracking the Chrome LKGR builds, ClusterFuzz is evolving into a real-time security regression detection capability. To appreciate just what that means, consider that ClusterFuzz has detected 95 unique vulnerabilities since we brought it fully online at the end of last year. In that time, 44 of those vulnerabilities were identified and fixed before they ever had a chance to make it out to a stable release. As we further refine our process and increase our scale, we expect potential security regressions in stable releases to become increasingly less common.

Just like Chrome itself, our fuzzing work is constantly evolving and pushing the state of the art in both scale and techniques. In keeping with Chrome’s security principles, we’re helping to make the web safer by upstreaming the security fixes into projects we rely upon, like WebKit and FFmpeg. As we expand and improve ClusterFuzz, users of those upstream projects will continue to benefit.

Posted by Abhishek Arya and Cris Neckar, Chrome Security Team

The Dart team invites you to the first global Dart hackathon, a collaboration between the Dart team and the developer community. Sign up and have fun hacking on Dart to build modern client and server side web apps and libraries. Current hackathon locations include:

• North America:
• Silicon Valley, California, USA
• South America:
• São Paulo, Brazil
• Europe and Middle East:
• London, England
• Prague, Czech Republic
• Tel Aviv, Israel
• Asia:
• Bacolod City, Philippines
• Chandigarh, India
• Goa, India
• Karnataka, India
• Manipal, India
• New Delhi, India
• Seoul, Korea
• Tokyo, Japan

Hackathon dates vary by location. Check out the full list for the schedule. The Dart project is still in technology preview, which means you’ll be hacking on early access code, but that’s all part of the fun. We’re eager to see what you build, and we hope you can make it. Register today!



Posted by Seth Ladd, Developer Advocate

Last January, Chrome was the first major browser to preview WebRTC, HTML5's new real time audio and video stack. Since then, we've been hard at work keeping up with the evolving specification, fixing bugs and listening to the web community’s feedback.

The main parts of the WebRTC specification are now stable and are coming soon to all 200M+ Chrome users. With this blog post, we want to help developers plan for what will be introduced in this first stable release later this year.

What's in:

JSEP
JSEP (Javascript Session Establishment Protocol) is an API for signaling that allows for much more powerful apps and flexibility in choice of signaling protocols. To abstract the complexity, we provide and maintain a Javascript lib that makes browser to browser calls a few lines of Javascript.

Topologies
Our implementation will support multiple independent PeerConnections, each capable of sending and receiving multiple independent media sources.

ICE / STUN / TURN
ICE and STUN are standardized methods for establishing a peer-to-peer connection on the Internet, even if the two end points are behind private network addresses (NAT). Chrome’s current stack deviates from the official current standards. We are working to fix this.

We will also support TURN servers to allow connections through tougher firewalls, where relaying and encapsulation are needed. Exactly what type of TURN will be supported is TBD.

DTLS-SRTP 
Encryption will be mandatory for all usage of WebRTC in Chrome. For our first stable release, we will implement DTLS-SRTP.

VP8, iSAC, iLBC, G.711
The video codec support by Chrome will be VP8. We've made several major improvements inside and around VP8 to ensure it can deliver a great real time experience. On the audio side, we will initially support iSAC, iLBC, G.711, and DTMF, with iSAC being the default. It is a royalty free wideband codec optimized for speech, open sourced at webrtc.org.

What’s next?

More functionality and features will appear in future versions of Chrome. We’ll work on prioritizing them once we get the basics right:

• Data API. Implementation will start once the network stack is ready. 
• Screen sharing. 
• PeerConnection proxying. The ability to relay a stream to a third party will not make our first version. 
• Recording. MediaRecorder specification work has not been completed yet.

Comments, questions, kudos or tomatoes? Let us know on our discussion list.

Posted by Serge Lachapelle, Product Manager

The latest Stable channel release of Chrome brings improvements to both Canvas2D’s speed and WebGL’s reach.

We’ve enabled GPU-accelerated Canvas2D on capable Windows and Mac computers, which should make web applications like games perform even better than a pure software implementation. GPU-accelerated Canvas2D has previously been enabled in the Beta channel for quite some time, so hopefully developers have had a chance to try it out. We’re continuing to make improvements and tweaks to our Canvas2D implementation, so please file a bug in our public issue tracker if you encounter problems.

WebGL enables compelling 3D content on the web, so we want to ensure that as many users as possible have access to this technology. That’s why we’ve enabled SwiftShader, a software rasterizer licensed from our friends at TransGaming, for users with older configurations. Keep in mind that a software-backed WebGL implementation is never going to perform as well as one running on a real GPU, but now more users will have access to basic 3D content on the web. See our previous blog post for more details on SwiftShader and how to try it out.

Posted by John "More CPU in Your GPU" Bauman and Brian "FPS" Salomon