Verzeichnis
Suchen im gesamten Verzeichnis und blättern in Suchliste
Chromium Blog
Cross posted to the Google Code Blog
An attractive feature of Web programming is a rapid development cycle. Reloading the application after the source code has changed takes a fraction of a second. We want to offer you that same experience when using Dart, and today we’re making Mac and Linux binaries available that integrate the Dart VM into Chromium.
This technology preview allows you to run your Dart programs directly on the Dart VM in Chromium and avoid a separate compilation step. Over time, these programs will take advantage of the VM’s faster performance and lower startup latency.
Dart has been designed from the start to work with the entire modern web, and we’re simultaneously continuing to improve our fast Dart-to-JavaScript compiler. Both the Dart VM and modern JavaScript engines are first-class targets for Dart.
This release of Chromium with Dart VM integration is a technology preview, and should not be used for day-to-day browsing. After more testing and developer feedback, we plan to eventually include the Dart VM in Chrome.
Today’s release of the Chromium + Dart VM integration is another step forward for the open source "batteries included" Dart platform. Our goal is to help you build complex, high performance apps for the modern web, and we encourage you to try Dart and let us know what you think.
An attractive feature of Web programming is a rapid development cycle. Reloading the application after the source code has changed takes a fraction of a second. We want to offer you that same experience when using Dart, and today we’re making Mac and Linux binaries available that integrate the Dart VM into Chromium.
This technology preview allows you to run your Dart programs directly on the Dart VM in Chromium and avoid a separate compilation step. Over time, these programs will take advantage of the VM’s faster performance and lower startup latency.
Dart has been designed from the start to work with the entire modern web, and we’re simultaneously continuing to improve our fast Dart-to-JavaScript compiler. Both the Dart VM and modern JavaScript engines are first-class targets for Dart.
This release of Chromium with Dart VM integration is a technology preview, and should not be used for day-to-day browsing. After more testing and developer feedback, we plan to eventually include the Dart VM in Chrome.
Today’s release of the Chromium + Dart VM integration is another step forward for the open source "batteries included" Dart platform. Our goal is to help you build complex, high performance apps for the modern web, and we encourage you to try Dart and let us know what you think.
In theory there’s no difference between theory and practice. In practice, there is. That’s why we prefer to try new ideas out in the real world and see which features actually helped users get where they want to go. In Chrome we call these tests Field Trials, and they’ve been part of every install steadily making Chrome better since day one. For example, Field Trials helped us improve our Omnibox pre-rendering by about 70 percent - making about 1 in 3 Omnibox navigations faster by a second or more.
If you’re contributing to Chrome, you should consider using Field Trials to help tune your features. Recently we’ve added infrastructure to help make designing and deploying these tests easier than ever. Field Trials will now have a regular update cycle similar to the one that delivers the newest version of Chrome to users, making it easier to rapidly release and retire new variations. We’ve also centralized the logic of which variations are active so that its easy for developers on M21 or higher to reset their variation state, using the --reset-variation-state command line flag. To learn more about variations of Chrome, check out Field Trials at the Chromium project.
If you’re contributing to Chrome, you should consider using Field Trials to help tune your features. Recently we’ve added infrastructure to help make designing and deploying these tests easier than ever. Field Trials will now have a regular update cycle similar to the one that delivers the newest version of Chrome to users, making it easier to rapidly release and retire new variations. We’ve also centralized the logic of which variations are active so that its easy for developers on M21 or higher to reset their variation state, using the --reset-variation-state command line flag. To learn more about variations of Chrome, check out Field Trials at the Chromium project.
Just over two months ago, Chrome sponsored the Pwnium browser hacking competition. We had two fantastic submissions, and successfully blocked both exploits within 24 hours of their unveiling. Today, we’d like to offer an inside look into the exploit submitted by Pinkie Pie.
So, how does one get full remote code execution in Chrome? In the case of Pinkie Pie’s exploit, it took a chain of six different bugs in order to successfully break out of the Chrome sandbox.
Pinkie’s first bug (117620) used Chrome’s prerendering feature to load a Native Client module on a web page. Prerendering is a performance optimization that lets a site provide hints for Chrome to fetch and render a page before the user navigates to it, making page loads seem instantaneous. To avoid sound and other nuisances from preloaded pages, the prerenderer blocks plug-ins from running until the user chooses to navigate to the page. Pinkie discovered that navigating to a pre-rendered page would inadvertently run all plug-ins—even Native Client plug-ins, which are otherwise permitted only for installed extensions and apps.
Of course, getting a Native Client plug-in to execute doesn’t buy much, because the Native Client process’ sandbox is even more restrictive than Chrome’s sandbox for HTML content. What Native Client does provide, however, is a low-level interface to the GPU command buffers, which are used to communicate accelerated graphics operations to the GPU process. This allowed Pinkie to craft a special command buffer to exploit the following integer underflow bug (117656) in the GPU command decoding:
The issue here is that if size_of_buffer is smaller than sizeof(uint32), the result would be a huge value, which was then used as input to the following function:
This calculation then overflowed and made the result of this function zero, instead of a value at least equal to sizeof(uint32). Using this, Pinkie was able to write eight bytes of his choice past the end of his buffer. The buffer in this case is one of the GPU transfer buffers, which are mapped in both processes’ address spaces and used to transfer data between the Native Client and GPU processes. The Windows allocator places the buffers at relatively predictable locations; and the Native Client process can directly control their size as well as certain object allocation ordering. So, this afforded quite a bit of control over exactly where an overwrite would occur in the GPU process.
The next thing Pinkie needed was a target that met two criteria: it had to be positioned within range of his overwrite, and the first eight bytes needed to be something worth changing. For this, he used the GPU buckets, which are another IPC primitive exposed from the GPU process to the Native Client process. The buckets are implemented as a tree structure, with the first eight bytes containing pointers to other nodes in the tree. By overwriting the first eight bytes of a bucket, Pinkie was able to point it to a fake tree structure he created in one of his transfer buffers. Using that fake tree, Pinkie could read and write arbitrary addresses in the GPU process. Combined with some predictable addresses in Windows, this allowed him to build a ROP chain and execute arbitrary code inside the GPU process.
The GPU process is still sandboxed well below a normal user, but it’s not as strongly sandboxed as the Native Client process or the HTML renderer. It has some rights, such as the ability to enumerate and connect to the named pipes used by Chrome’s IPC layer. Normally this wouldn’t be an issue, but Pinkie found that there’s a brief window after Chrome spawns a new renderer where the GPU process could see the renderer’s IPC channel and connect to it first, allowing the GPU process to impersonate the renderer (bug 117627).
Even though Chrome’s renderers execute inside a stricter sandbox than the GPU process, there is a special class of renderers that have IPC interfaces with elevated permissions. These renderers are not supposed to be navigable by web content, and are used for things like extensions and settings pages. However, Pinkie found another bug (117417) that allowed an unprivileged renderer to trigger a navigation to one of these privileged renderers, and used it to launch the extension manager. So, all he had to do was jump on the extension manager’s IPC channel before it had a chance to connect.
Once he was impersonating the extensions manager, Pinkie used two more bugs to finally break out of the sandbox. The first bug (117715) allowed him to specify a load path for an extension from the extension manager’s renderer, something only the browser should be allowed to do. The second bug (117736) was a failure to prompt for confirmation prior to installing an unpacked NPAPI plug-in extension. With these two bugs Pinkie was able to install and run his own NPAPI plug-in that executed outside the sandbox at full user privilege.
So, that’s the long and impressive path Pinkie Pie took to crack Chrome. All the referenced bugs were fixed some time ago, but some are still restricted to ensure our users and Chromium embedders have a chance to update. However, we’ve included links so when we do make the bugs public, anyone can investigate in more detail.
In an upcoming post, we’ll explain the details of Sergey Glazunov’s exploit, which relied on roughly 10 distinct bugs. While these issues are already fixed in Chrome, some of them impact a much broader array of products from a range of companies. So, we won’t be posting that part until we’re comfortable that all affected products have had an adequate time to push fixes to their users.
So, how does one get full remote code execution in Chrome? In the case of Pinkie Pie’s exploit, it took a chain of six different bugs in order to successfully break out of the Chrome sandbox.
Pinkie’s first bug (117620) used Chrome’s prerendering feature to load a Native Client module on a web page. Prerendering is a performance optimization that lets a site provide hints for Chrome to fetch and render a page before the user navigates to it, making page loads seem instantaneous. To avoid sound and other nuisances from preloaded pages, the prerenderer blocks plug-ins from running until the user chooses to navigate to the page. Pinkie discovered that navigating to a pre-rendered page would inadvertently run all plug-ins—even Native Client plug-ins, which are otherwise permitted only for installed extensions and apps.
Of course, getting a Native Client plug-in to execute doesn’t buy much, because the Native Client process’ sandbox is even more restrictive than Chrome’s sandbox for HTML content. What Native Client does provide, however, is a low-level interface to the GPU command buffers, which are used to communicate accelerated graphics operations to the GPU process. This allowed Pinkie to craft a special command buffer to exploit the following integer underflow bug (117656) in the GPU command decoding:
static uint32 ComputeMaxResults(size_t size_of_buffer) { return (size_of_buffer - sizeof(uint32)) / sizeof(T); }
The issue here is that if size_of_buffer is smaller than sizeof(uint32), the result would be a huge value, which was then used as input to the following function:
static size_t ComputeSize(size_t num_results) { return sizeof(T) * num_results + sizeof(uint32); }
This calculation then overflowed and made the result of this function zero, instead of a value at least equal to sizeof(uint32). Using this, Pinkie was able to write eight bytes of his choice past the end of his buffer. The buffer in this case is one of the GPU transfer buffers, which are mapped in both processes’ address spaces and used to transfer data between the Native Client and GPU processes. The Windows allocator places the buffers at relatively predictable locations; and the Native Client process can directly control their size as well as certain object allocation ordering. So, this afforded quite a bit of control over exactly where an overwrite would occur in the GPU process.
The next thing Pinkie needed was a target that met two criteria: it had to be positioned within range of his overwrite, and the first eight bytes needed to be something worth changing. For this, he used the GPU buckets, which are another IPC primitive exposed from the GPU process to the Native Client process. The buckets are implemented as a tree structure, with the first eight bytes containing pointers to other nodes in the tree. By overwriting the first eight bytes of a bucket, Pinkie was able to point it to a fake tree structure he created in one of his transfer buffers. Using that fake tree, Pinkie could read and write arbitrary addresses in the GPU process. Combined with some predictable addresses in Windows, this allowed him to build a ROP chain and execute arbitrary code inside the GPU process.
The GPU process is still sandboxed well below a normal user, but it’s not as strongly sandboxed as the Native Client process or the HTML renderer. It has some rights, such as the ability to enumerate and connect to the named pipes used by Chrome’s IPC layer. Normally this wouldn’t be an issue, but Pinkie found that there’s a brief window after Chrome spawns a new renderer where the GPU process could see the renderer’s IPC channel and connect to it first, allowing the GPU process to impersonate the renderer (bug 117627).
Even though Chrome’s renderers execute inside a stricter sandbox than the GPU process, there is a special class of renderers that have IPC interfaces with elevated permissions. These renderers are not supposed to be navigable by web content, and are used for things like extensions and settings pages. However, Pinkie found another bug (117417) that allowed an unprivileged renderer to trigger a navigation to one of these privileged renderers, and used it to launch the extension manager. So, all he had to do was jump on the extension manager’s IPC channel before it had a chance to connect.
Once he was impersonating the extensions manager, Pinkie used two more bugs to finally break out of the sandbox. The first bug (117715) allowed him to specify a load path for an extension from the extension manager’s renderer, something only the browser should be allowed to do. The second bug (117736) was a failure to prompt for confirmation prior to installing an unpacked NPAPI plug-in extension. With these two bugs Pinkie was able to install and run his own NPAPI plug-in that executed outside the sandbox at full user privilege.
So, that’s the long and impressive path Pinkie Pie took to crack Chrome. All the referenced bugs were fixed some time ago, but some are still restricted to ensure our users and Chromium embedders have a chance to update. However, we’ve included links so when we do make the bugs public, anyone can investigate in more detail.
In an upcoming post, we’ll explain the details of Sergey Glazunov’s exploit, which relied on roughly 10 distinct bugs. While these issues are already fixed in Chrome, some of them impact a much broader array of products from a range of companies. So, we won’t be posting that part until we’re comfortable that all affected products have had an adequate time to push fixes to their users.
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:
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.
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.
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.
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!
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!
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.
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.
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:
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.
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.
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:
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!
- 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
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!
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:
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.
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.
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.
Over the past several months, the number of daily app and extensions downloads from the Chrome Web Store has more than doubled. We are now seeing millions of downloads per day. Some apps and extensions have grown even faster thanks to inline installation, a feature we launched a few months ago.
With inline installation, you can allow Chrome users who visit your web site to install your apps and extensions directly without requiring them to visit the Chrome Web Store. This creates a smoother experience for your users as it eliminates an extra step where potential users could drop off.
Here are a few examples of the impact of inline installation:
With inline installation, you can allow Chrome users who visit your web site to install your apps and extensions directly without requiring them to visit the Chrome Web Store. This creates a smoother experience for your users as it eliminates an extra step where potential users could drop off.
Here are a few examples of the impact of inline installation:
- Chrome extensions Evernote Clearly and Evernote Web Clipper derive 15% and 25% of their Chrome installations (respectively) from their inline installation implementation
- Rovio implemented inline installation for their Angry Birds Chrome game and saw their install rate jump by almost 10%)
- Equire, a CRM extension that integrates with Gmail, saw a 66% increase in Chrome user retention after they implemented inline installation.
Example: Installing Evernote Web Clipper from Evernote’s Site
- Provide a link to your Chrome Web Store item.
- Write some script to check for whatever client-side capabilities your app requires (support for WebGL, the Web Audio API, etc). Modernizr is a great library to use for this.
- Call a JavaScript function to initiate the install process.
The full details and documentation for using inline installation can be found here. If you have any questions, you can reach us on our developer forum.
Last week, the Chrome team participated in the Game Developers Conference in San Francisco. We all enjoyed talking to attendees about how game developers can benefit from the latest browser technologies such as Native Client and HTML5.
For those of you who were not able to attend, we recorded videos of our talks. Check them out and let us know what you think.
During GDC, several developers presented some new and upcoming games for the Chrome Web Store. From AirMech to the highly anticipated From Dust, these games provided a sneak peek to the future of browser-based games.
Besides being able to use the latest technology the web has to offer, creating a game for Chrome means you can distribute and monetize your game successfully. This is evidenced by our 4 brand new case studies with Kabam, Hlafbrick, Game Salad, and Limex Games.
To learn how you too can develop games for Chrome, start by visiting our game developer site.
For those of you who were not able to attend, we recorded videos of our talks. Check them out and let us know what you think.
During GDC, several developers presented some new and upcoming games for the Chrome Web Store. From AirMech to the highly anticipated From Dust, these games provided a sneak peek to the future of browser-based games.
Besides being able to use the latest technology the web has to offer, creating a game for Chrome means you can distribute and monetize your game successfully. This is evidenced by our 4 brand new case studies with Kabam, Hlafbrick, Game Salad, and Limex Games.
To learn how you too can develop games for Chrome, start by visiting our game developer site.
Today we are releasing version 7 of the V8 Benchmark Suite. This new version adds Oliver Hunt’s 2D Navier-Stokes fluid dynamic simulation, which stresses intense double array computations. These complex double array computations are today common in games, graphic and scientific applications.
The new test shows the recent improvements V8 has made in handling advanced physics computations: the current Chrome 18 (today in beta) delivers a 5% score improvement compared to the current Chrome 17. Chrome 19 (today in canary), where the full set of improvements is being released, delivers a whopping 25% score improvement compared to Chrome 17.
With these additions, the V8 Benchmark Suite is now a more comprehensive collection of eight tests, including OS kernel simulation, crypto and string operations, memory management stress-tests, and as of today, double array computations.
We plan to keep updating the suite by adding more tests. These updates are a reflection of Chrome’s commitment to keep pushing the boundaries of speed, optimizing the engine for today’s more demanding web apps.
The new test shows the recent improvements V8 has made in handling advanced physics computations: the current Chrome 18 (today in beta) delivers a 5% score improvement compared to the current Chrome 17. Chrome 19 (today in canary), where the full set of improvements is being released, delivers a whopping 25% score improvement compared to Chrome 17.
With these additions, the V8 Benchmark Suite is now a more comprehensive collection of eight tests, including OS kernel simulation, crypto and string operations, memory management stress-tests, and as of today, double array computations.
We plan to keep updating the suite by adding more tests. These updates are a reflection of Chrome’s commitment to keep pushing the boundaries of speed, optimizing the engine for today’s more demanding web apps.
A few weeks ago one of my developer friends was gushing about the capabilities of his favorite native platform. After every point I felt obliged to point out that the web platform either already had or was actively developing precisely the same capabilities—and then some. He was incredulous. "Prove it," he said.
So I pulled together a few of my favorite examples from the cutting edge of the web platform and recorded three screencasts to help my friend—and others—meet the web platform again for the first time.
The first video, Building on Foundations, goes over how the web platform has been fixing various historical shortcomings and building upon its core strengths, like complicated graphical effects, composability, and advanced text layout.
The next video, Learning from Other Platforms, reviews how the web platform offers new capabilities inspired by successes on other platforms with things like push notifications, payment APIs, and web intents.
The last video, On the Cutting Edge, demonstrates some of the new tricks the web platform is learning, like webcam access, powerful audio APIs, and complicated 3D graphics.
If you're interested in learning more about the technology behind any of the demos, check out the Meet the Web Platform companion guide.
I hope these videos capture your imagination and begin to show what is possible on the web platform. The web platform is evolving at an enormous pace, and I just can't wait to see where it goes next!
So I pulled together a few of my favorite examples from the cutting edge of the web platform and recorded three screencasts to help my friend—and others—meet the web platform again for the first time.
The first video, Building on Foundations, goes over how the web platform has been fixing various historical shortcomings and building upon its core strengths, like complicated graphical effects, composability, and advanced text layout.
The next video, Learning from Other Platforms, reviews how the web platform offers new capabilities inspired by successes on other platforms with things like push notifications, payment APIs, and web intents.
The last video, On the Cutting Edge, demonstrates some of the new tricks the web platform is learning, like webcam access, powerful audio APIs, and complicated 3D graphics.
If you're interested in learning more about the technology behind any of the demos, check out the Meet the Web Platform companion guide.
I hope these videos capture your imagination and begin to show what is possible on the web platform. The web platform is evolving at an enormous pace, and I just can't wait to see where it goes next!
Hundreds of millions play games on the web everyday - including most of us on the Chrome team. Between building new virtual cities and slaying dragons, we’re also working on making the web a better platform for game developers. With GDC about to start, we wanted to give you a quick update on these efforts.
First, we’re collaborating with all browser vendors to give you access to exciting new HTML5 APIs such as Gamepad, Mouse Lock and Fullscreen. These can help you create more immersive experiences for your users.
Second, Native Client continues to gain momentum. Today, the BlitzTech Gaming engine and the Havok Physics Engine announced support for Native Client, enriching an ecosystem that includes Unity, Moai, Bullet and other leading middleware providers. Already many game developers have been using NaCl to bring their games to Chrome’s hundreds of millions of users including brand new titles from Ubisoft, Carbon Games, Spacetime Studios, FuzzyCube Software, Klei Entertainment and Fire Hose Games.
Third, we’re working closely with other teams at Google to improve and simplify distribution and monetization for game developers. All games in the Chrome Web Store now have access to an improved In-App Payments solution that includes support for more currencies and an optimized payment flow. This includes all Google+ games that will soon be listed in the store.
To learn more on how you can also benefit from the emergence of the browser as a game platform, visit us at developers.google.com/games. And if you are attending GDC this week, come and say hi.
First, we’re collaborating with all browser vendors to give you access to exciting new HTML5 APIs such as Gamepad, Mouse Lock and Fullscreen. These can help you create more immersive experiences for your users.
Second, Native Client continues to gain momentum. Today, the BlitzTech Gaming engine and the Havok Physics Engine announced support for Native Client, enriching an ecosystem that includes Unity, Moai, Bullet and other leading middleware providers. Already many game developers have been using NaCl to bring their games to Chrome’s hundreds of millions of users including brand new titles from Ubisoft, Carbon Games, Spacetime Studios, FuzzyCube Software, Klei Entertainment and Fire Hose Games.
Third, we’re working closely with other teams at Google to improve and simplify distribution and monetization for game developers. All games in the Chrome Web Store now have access to an improved In-App Payments solution that includes support for more currencies and an optimized payment flow. This includes all Google+ games that will soon be listed in the store.
To learn more on how you can also benefit from the emergence of the browser as a game platform, visit us at developers.google.com/games. And if you are attending GDC this week, come and say hi.
Security is one of our core values, alongside speed, stability and simplicity. From day one, we’ve designed Chrome’s extension system with security in mind. Since we launched the extension system, the state of the art in web security has advanced with technologies like Content-Security-Policy (CSP). Extension developers have been able to opt into these features, and now we’re enabling these security features by default.
Unfortunately, securing extensions with CSP by default is incompatible with the legacy extension system. We’re passionate about extension compatibility, so we’re going to make this change gradually to minimize pain for users and developers.
Users can continue to install extensions that are available in the store regardless of whether they are secured with CSP or not. This means they will not lose any of the functionality they've added to Chrome.
Developers will be able to choose when to enable the new behavior. To ease the transition, we've introduced a new manifest version attribute in the extension manifest in Chrome 18 (currently in beta). When a developer updates his or her extension to use manifest_version 2, Chrome will enforce the following CSP policy by default:
script-src 'self'; object-src 'self'
This policy imposes the following restrictions on extensions:
These defenses are extremely effective: adopting one of the recommended CSPs would prevent 96% (49 out of 51) of the core extension vulnerabilities we found.
For most extensions, updating them to manifest_version 2 will require the developer to move inline scripts out-of-line and to move scripts loaded from the network into the extension package. Developers are not required to update their extensions to manifest_version 2 immediately, but, over time, more of the extension ecosystem will encourage developers to update their extensions. For example, at some point, we’ll likely start requiring new extensions uploaded to the web store to use manifest_version 2. You can find a complete list of changes and more details about CSP in the extension documentation.
We expect these changes will make the security of Chrome’s extension system even better. If you have any feedback, please feel encouraged to email the extension developers mailing list.
Unfortunately, securing extensions with CSP by default is incompatible with the legacy extension system. We’re passionate about extension compatibility, so we’re going to make this change gradually to minimize pain for users and developers.
Users can continue to install extensions that are available in the store regardless of whether they are secured with CSP or not. This means they will not lose any of the functionality they've added to Chrome.
Developers will be able to choose when to enable the new behavior. To ease the transition, we've introduced a new manifest version attribute in the extension manifest in Chrome 18 (currently in beta). When a developer updates his or her extension to use manifest_version 2, Chrome will enforce the following CSP policy by default:
script-src 'self'; object-src 'self'
This policy imposes the following restrictions on extensions:
- Extensions can no longer use inline scripts, such as . Instead, extensions must use out-of-line scripts loaded from within their package, such as .
- Extensions can no longer use eval(). Note: If you’re using eval to parse JSON today, we suggest using JSON.parse instead.
- Extensions can load plug-ins, such as SWF files, only from within their package or from a whitelist of HTTPS hosts.
These defenses are extremely effective: adopting one of the recommended CSPs would prevent 96% (49 out of 51) of the core extension vulnerabilities we found.
For most extensions, updating them to manifest_version 2 will require the developer to move inline scripts out-of-line and to move scripts loaded from the network into the extension package. Developers are not required to update their extensions to manifest_version 2 immediately, but, over time, more of the extension ecosystem will encourage developers to update their extensions. For example, at some point, we’ll likely start requiring new extensions uploaded to the web store to use manifest_version 2. You can find a complete list of changes and more details about CSP in the extension documentation.
We expect these changes will make the security of Chrome’s extension system even better. If you have any feedback, please feel encouraged to email the extension developers mailing list.
This year at the CanSecWest security conference, we will once again sponsor rewards for Google Chrome exploits. This complements and extends our Chromium Security Rewards program by recognizing that developing a fully functional exploit is significantly more work than finding and reporting a potential security bug.
The aim of our sponsorship is simple: we have a big learning opportunity when we receive full end-to-end exploits. Not only can we fix the bugs, but by studying the vulnerability and exploit techniques we can enhance our mitigations, automated testing, and sandboxing. This enables us to better protect our users.
While we’re proud of Chrome’s leading track record in past competitions, the fact is that not receiving exploits means that it’s harder to learn and improve. To maximize our chances of receiving exploits this year, we’ve upped the ante. We will directly sponsor up to $1 million worth of rewards in the following categories:
$60,000 - "Full Chrome exploit": Chrome / Win7 local OS user account persistence using only bugs in Chrome itself.
$40,000 - "Partial Chrome exploit": Chrome / Win7 local OS user account persistence using at least one bug in Chrome itself, plus other bugs. For example, a WebKit bug combined with a Windows sandbox bug.
$20,000 - "Consolation reward, Flash / Windows / other": Chrome / Win7 local OS user account persistence that does not use bugs in Chrome. For example, bugs in one or more of Flash, Windows or a driver. These exploits are not specific to Chrome and will be a threat to users of any web browser. Although not specifically Chrome’s issue, we’ve decided to offer consolation prizes because these findings still help us toward our mission of making the entire web safer.
All winners will also receive a Chromebook.
We will issue multiple rewards per category, up to the $1 million limit, on a first-come-first served basis. There is no splitting of winnings or "winner takes all." We require each set of exploit bugs to be reliable, fully functional end to end, disjoint, of critical impact, present in the latest versions and genuinely "0-day," i.e. not known to us or previously shared with third parties. Contestant’s exploits must be submitted to and judged by Google before being submitted anywhere else.
Originally, our plan was to sponsor as part of this year’s Pwn2Own competition. Unfortunately, we decided to withdraw our sponsorship when we discovered that contestants are permitted to enter Pwn2Own without having to reveal full exploits (or even all of the bugs used!) to vendors. Full exploits have been handed over in previous years, but it’s an explicit non-requirement in this year’s contest, and that’s worrisome. We will therefore be running this alternative Chrome-specific reward program. It is designed to be attractive -- not least because it stays aligned with user safety by requiring the full exploit to be submitted to us. We guarantee to send non-Chrome bugs to the appropriate vendor immediately.
Drop by our table at CanSecWest to participate and check the latest news.
The aim of our sponsorship is simple: we have a big learning opportunity when we receive full end-to-end exploits. Not only can we fix the bugs, but by studying the vulnerability and exploit techniques we can enhance our mitigations, automated testing, and sandboxing. This enables us to better protect our users.
While we’re proud of Chrome’s leading track record in past competitions, the fact is that not receiving exploits means that it’s harder to learn and improve. To maximize our chances of receiving exploits this year, we’ve upped the ante. We will directly sponsor up to $1 million worth of rewards in the following categories:
$60,000 - "Full Chrome exploit": Chrome / Win7 local OS user account persistence using only bugs in Chrome itself.
$40,000 - "Partial Chrome exploit": Chrome / Win7 local OS user account persistence using at least one bug in Chrome itself, plus other bugs. For example, a WebKit bug combined with a Windows sandbox bug.
$20,000 - "Consolation reward, Flash / Windows / other": Chrome / Win7 local OS user account persistence that does not use bugs in Chrome. For example, bugs in one or more of Flash, Windows or a driver. These exploits are not specific to Chrome and will be a threat to users of any web browser. Although not specifically Chrome’s issue, we’ve decided to offer consolation prizes because these findings still help us toward our mission of making the entire web safer.
All winners will also receive a Chromebook.
We will issue multiple rewards per category, up to the $1 million limit, on a first-come-first served basis. There is no splitting of winnings or "winner takes all." We require each set of exploit bugs to be reliable, fully functional end to end, disjoint, of critical impact, present in the latest versions and genuinely "0-day," i.e. not known to us or previously shared with third parties. Contestant’s exploits must be submitted to and judged by Google before being submitted anywhere else.
Originally, our plan was to sponsor as part of this year’s Pwn2Own competition. Unfortunately, we decided to withdraw our sponsorship when we discovered that contestants are permitted to enter Pwn2Own without having to reveal full exploits (or even all of the bugs used!) to vendors. Full exploits have been handed over in previous years, but it’s an explicit non-requirement in this year’s contest, and that’s worrisome. We will therefore be running this alternative Chrome-specific reward program. It is designed to be attractive -- not least because it stays aligned with user safety by requiring the full exploit to be submitted to us. We guarantee to send non-Chrome bugs to the appropriate vendor immediately.
Drop by our table at CanSecWest to participate and check the latest news.
When we launched the Chrome Web Store a year ago, our app taxonomy system reflected the apps that were available in the store at the time. However, since then, the store’s app inventory has grown and changed in composition. So, yesterday we made important changes in the Chrome Web Store’s app category system to allow more great apps of all kinds to stand out.
Until now, you could list your app into two categories. With the new category structure, we will show your app only in the primary category that you select for your app in the developer dashboard. We've found that secondary app categories contributed to a confusing experience for Chrome users and developers so from now on, we're going to start ignoring the secondary category.
We also updated the list of top level app categories and created multiple sub categories in each of them.
More specifically, given the growing use of Chrome and Chromebooks in large and small businesses, we created a new category called "Business Tools" that can help enterprise focused developers target these users. Also, "Shopping" has been reclassified as a subcategory, within the "Lifestyle" category.
The new structure of the store will improve discoverability for apps. For example, users searching for a photo album app can now easily drill down to the "Photos" subcategory level and track down the app they are looking for. At the same time, apps assigned to a subcategory show up in the category page as well giving them wider exposure; an app in "Photos" will appear on both the "Photos" page and the "Entertainment" page.
The categories will continue to evolve over time. To that effect, in the Developer Dashboard you will see a few more subcategory options than the ones that are live in the Chrome Web Store today. We plan to expose these subcategories to users once we confirm we have enough interesting apps in each one of them. In the meantime, items assigned to these subcategories will show up at a related subcategory. For example all items on "Online Documents & File Storage" will show up for now in "Office Tools".
This transition required our team to take a stab at automatically assigning all apps to one of our new categories / subcategories. Please take a look at the developer dashboard and make sure the placement of your app accurately reflects your business goals and the experience you offer.
Learn more about these category changes on our developer site. If you have any questions about these changes, please don't hesitate to post to our developer forum.
Until now, you could list your app into two categories. With the new category structure, we will show your app only in the primary category that you select for your app in the developer dashboard. We've found that secondary app categories contributed to a confusing experience for Chrome users and developers so from now on, we're going to start ignoring the secondary category.
We also updated the list of top level app categories and created multiple sub categories in each of them.
More specifically, given the growing use of Chrome and Chromebooks in large and small businesses, we created a new category called "Business Tools" that can help enterprise focused developers target these users. Also, "Shopping" has been reclassified as a subcategory, within the "Lifestyle" category.
The new structure of the store will improve discoverability for apps. For example, users searching for a photo album app can now easily drill down to the "Photos" subcategory level and track down the app they are looking for. At the same time, apps assigned to a subcategory show up in the category page as well giving them wider exposure; an app in "Photos" will appear on both the "Photos" page and the "Entertainment" page.
The categories will continue to evolve over time. To that effect, in the Developer Dashboard you will see a few more subcategory options than the ones that are live in the Chrome Web Store today. We plan to expose these subcategories to users once we confirm we have enough interesting apps in each one of them. In the meantime, items assigned to these subcategories will show up at a related subcategory. For example all items on "Online Documents & File Storage" will show up for now in "Office Tools".
This transition required our team to take a stab at automatically assigning all apps to one of our new categories / subcategories. Please take a look at the developer dashboard and make sure the placement of your app accurately reflects your business goals and the experience you offer.
Learn more about these category changes on our developer site. If you have any questions about these changes, please don't hesitate to post to our developer forum.
All good things come in threes. So, this week, the Chrome Developer Relations team is releasing three new resources for developers.
First, we are making available a brand new Field Guide to Web Applications, to help developers create great web apps. This guide walks you through topics like app design fundamentals, tips for creating great experiences and a few case studies that put the best practices to use. Whether you're building your first web app or are just looking for ways to improve your existing apps, we hope you'll find the field guide useful.
Second, our popular HTML5 site, HTML5Rocks.com, was also remodeled to better organize the site's content. You’ll now find new "persona pages" with catered content in 3 different verticals (Games, Business, Mobile). In addition, we consolidated many of the different components, and deeply integrated the HTML5 technology classes to bring a better identity to the site.
Finally, we've also joined Google+ with a new page specifically for Chrome Developers. Whether you’re building modern web apps, using Dart or WebRTC, we’ll be there to help you! Keep your eyes open for our weekly hangouts and add us to your circles.
First, we are making available a brand new Field Guide to Web Applications, to help developers create great web apps. This guide walks you through topics like app design fundamentals, tips for creating great experiences and a few case studies that put the best practices to use. Whether you're building your first web app or are just looking for ways to improve your existing apps, we hope you'll find the field guide useful.
Second, our popular HTML5 site, HTML5Rocks.com, was also remodeled to better organize the site's content. You’ll now find new "persona pages" with catered content in 3 different verticals (Games, Business, Mobile). In addition, we consolidated many of the different components, and deeply integrated the HTML5 technology classes to bring a better identity to the site.
Finally, we've also joined Google+ with a new page specifically for Chrome Developers. Whether you’re building modern web apps, using Dart or WebRTC, we’ll be there to help you! Keep your eyes open for our weekly hangouts and add us to your circles.
The ECMA committee is working hard on designing the next version of JavaScript, also known as "Harmony". It is due by the end of next year and it is going to be the most comprehensive upgrade in the history of this language.
Chrome and V8 are committed to pushing JavaScript forward and have already started implementing the new features. You can try some of them today in the latest dev channel release. Here’s a summary:
To enable Harmony features in the latest dev channel release of Chrome, go to chrome://flags and toggle on "Experimental JavaScript features". We encourage you to try them out and give us feedback!
Chrome and V8 are committed to pushing JavaScript forward and have already started implementing the new features. You can try some of them today in the latest dev channel release. Here’s a summary:
- Lexical scoping. Now "let" is the new "var" – traditional "var" declarations are complemented with "let" and "const". Both are properly block-scoped bindings, eliminating a common source of errors and weird behaviour. Function declarations are now officially allowed in local scope as well, and also obey lexical scoping. (Note: Lexical scoping is only available in ES strict mode.)
- Collections. Efficient maps and sets will make your life easier. Any value can be used as a key or element, including objects. No surprises, no more need to abuse objects as dictionaries. (Caveat: Iteration over collections is not yet specified.)
- Weak maps. A special kind of map for which the garbage collector determines when a key is no longer reachable, so that the key-value pair can be removed from the map automatically. This goes a long way towards avoiding memory leaks in long-lived tables and relieves the developer from worrying about stale entries.
- Proxies. A proxy simulates a JavaScript object or function, and can customize just about any aspect of their behaviour that you can imagine. This is a real power feature, that takes reflection to a new level and can be used to implement various advanced abstractions and interfaces.
To enable Harmony features in the latest dev channel release of Chrome, go to chrome://flags and toggle on "Experimental JavaScript features". We encourage you to try them out and give us feedback!
Today’s Beta release brings 2D Canvas improvements and a software rasterizer to Chrome.
For most Windows and Mac users, we’ve enabled GPU-accelerated rendering of 2D Canvas content, so that canvas-based games and animations run faster and feel smoother. You can go to
At the same time, we recognize that many people with older GPUs and graphics drivers have not been able to experience the rich content provided by technologies such as WebGL. Chrome is now able to display 3D content via SwiftShader, a software rasterizer we licensed from TransGaming, Inc. Although SwiftShader won’t perform as well as a real GPU, it will be an improvement for many of our users on older operating systems such as Windows XP.
SwiftShader automatically kicks in for those users who cannot run content on the GPU. If you want to take a peek at what the performance is like with SwiftShader, you can use the
As always, we appreciate your willingness to try out our creaky Beta software and look forward to your feedback and bug reports.
For most Windows and Mac users, we’ve enabled GPU-accelerated rendering of 2D Canvas content, so that canvas-based games and animations run faster and feel smoother. You can go to
chrome://gpu to see which features are being accelerated. This is a tricky area to optimize, due to the wide variety of hardware and operating system configurations found in the wild. We’ve made a series of small improvements to the way this acceleration works in the latest release, and we're seeking feedback on it from our Beta users. If you notice performance problems with 2D Canvas graphics content, particularly if you’re a web developer using 2D Canvas on your site, please file a bug.At the same time, we recognize that many people with older GPUs and graphics drivers have not been able to experience the rich content provided by technologies such as WebGL. Chrome is now able to display 3D content via SwiftShader, a software rasterizer we licensed from TransGaming, Inc. Although SwiftShader won’t perform as well as a real GPU, it will be an improvement for many of our users on older operating systems such as Windows XP.
SwiftShader automatically kicks in for those users who cannot run content on the GPU. If you want to take a peek at what the performance is like with SwiftShader, you can use the
--blacklist-accelerated-compositing and --blacklist-webgl flags, wait a few minutes for the automatic download to complete, and then load the relevant web page.As always, we appreciate your willingness to try out our creaky Beta software and look forward to your feedback and bug reports.
It’s hard for us to believe, but it’s been just over two years since we first announced the Chromium Security Rewards Program.
We’ve been delighted with the program’s success; we’ve issued well over $300,000 of rewards across hundreds of qualifying bugs, all of which we promptly fixed. It also helped inspire a wave of similar efforts from companies across the web, including Google’s own vulnerability reward program for web properties, which has also been a big hit.
We’ve been fascinated by the variety and ingenuity of bugs submitted by dozens of researchers. We’ve received bugs in roughly every component, ranging from system software (Windows kernel / Mac OS X graphics libraries / GNU libc) to Chromium / WebKit code and to popular open source libraries (libxml, ffmpeg). Chromium is a more stable and robust browser thanks to the efforts of the wider security community.
Today we’re expanding the scope of the Chromium program to formally include more items that deserve recognition:
Related to this third core principle, we’re particularly excited by all the work that has been done on shared components. For example, a more robust WebKit not only helps users of two major desktop browsers, but also a variety of tablet and mobile browsers.
We’ve been delighted with the program’s success; we’ve issued well over $300,000 of rewards across hundreds of qualifying bugs, all of which we promptly fixed. It also helped inspire a wave of similar efforts from companies across the web, including Google’s own vulnerability reward program for web properties, which has also been a big hit.
We’ve been fascinated by the variety and ingenuity of bugs submitted by dozens of researchers. We’ve received bugs in roughly every component, ranging from system software (Windows kernel / Mac OS X graphics libraries / GNU libc) to Chromium / WebKit code and to popular open source libraries (libxml, ffmpeg). Chromium is a more stable and robust browser thanks to the efforts of the wider security community.
Today we’re expanding the scope of the Chromium program to formally include more items that deserve recognition:
- High-severity Chromium OS security bugs are now in scope. Chromium OS includes much more than just the Chromium browser, so we’re rewarding security bugs across the whole system, as long as they are high severity and present when "developer mode" is switched off. Examples of issues that may generate a reward could include (but are not limited to):
- Renderer sandbox escapes via Linux kernel bugs.
- Memory corruptions or cross-origin issues inside the Pepper Flash plug-in.
- Serious cross-origin or memory corruption issues in default-installed apps, extensions or plug-ins.
- Violations of the verified boot path.
- Web- or network-reachable vulnerabilities in system libraries, daemons or drivers.
- We may elect to issue "bonuses" ranging from $500 to $1000 if a bug reporter takes on fixing the bug they have found themselves. For eligibility, this process involves working with the Chromium community to produce a peer reviewed patch. These bonuses are granted on top of the base reward, which typically runs between $500 and $3133.70.
- The base reward for a well-reported and significant cross-origin bug (for example a so-called UXSS or "Universal XSS") is now $2000.
Related to this third core principle, we’re particularly excited by all the work that has been done on shared components. For example, a more robust WebKit not only helps users of two major desktop browsers, but also a variety of tablet and mobile browsers.
Today, we introduced Chrome for Android Beta, which brings Chrome’s capabilities to phones and tablets running Android 4.0, Ice Cream Sandwich. This is made possible by a range of innovative features and by building a mobile browser from the ground up that makes full use of the underlying architecture built into Android 4.0.
Chrome for Android brings support for many of the latest HTML5 features to the Android platform. With hardware-accelerated canvas, overflow scroll support, strong HTML5 video support, and new capabilities such as Indexed DB, WebWorkers and Web Sockets, Chrome for Android is a solid platform for developing web content on mobile devices.
In addition to support for the latest web technologies, we hope to make interactive web content super easy to develop. Chrome for Android introduces remote debugging through Chrome Developer Tools to make it simple for developers to debug web sites running live on their mobile devices.
Much of the code for Chrome for Android is already shared with Chromium and over the coming weeks, the Chromium team will be upstreaming many new components developed for Chrome for Android to Chromium, WebKit and other projects.
We’ve got a lot more planned to make Chrome as feature-rich on mobile devices as it is on the desktop. We encourage you to follow any of the ongoing development via the issue tracker or join in on chromium-dev@chromium.org.
Chrome for Android brings support for many of the latest HTML5 features to the Android platform. With hardware-accelerated canvas, overflow scroll support, strong HTML5 video support, and new capabilities such as Indexed DB, WebWorkers and Web Sockets, Chrome for Android is a solid platform for developing web content on mobile devices.
In addition to support for the latest web technologies, we hope to make interactive web content super easy to develop. Chrome for Android introduces remote debugging through Chrome Developer Tools to make it simple for developers to debug web sites running live on their mobile devices.
Much of the code for Chrome for Android is already shared with Chromium and over the coming weeks, the Chromium team will be upstreaming many new components developed for Chrome for Android to Chromium, WebKit and other projects.
We’ve got a lot more planned to make Chrome as feature-rich on mobile devices as it is on the desktop. We encourage you to follow any of the ongoing development via the issue tracker or join in on chromium-dev@chromium.org.
While the web is a virtual treasure trove of great content, it’s also used by bad guys to steal personal information. One of Chrome’s most advanced security features, Safe Browsing, helps protect against the three most common threats on the web: phishing, drive-by malware, and harmful downloads. We recently announced some new enhancements to Safe Browsing, so we thought we’d offer an inside look into how it works.
Safe Browsing downloads a continuously-updated list of known phishing and malware websites, generated by an automated analysis of our entire web index. Each page you visit, and each resource (such as pictures and scripts) on the page, are checked against these lists. This is done in a way that does not reveal the websites you visit, and is described in more detail in our video on Safe Browsing. If Chrome detects that you’ve visited a page on the list, it warns you with a large red page that helps you get back to safety.
Of course, this only helps for dangerous content that Google already knows about. To provide better protection, Safe Browsing has two additional mechanisms that can detect phishing attacks and harmful downloads the system has never encountered before.
Phishing attacks are often only active for a few short hours, so it’s especially important to detect new attacks as they happen. Chrome now analyzes properties of each page you visit to determine the likelihood of it being a phishing page. This is done locally on your computer, and doesn’t share the websites you visit with Google. Only if the page looks sufficiently suspicious will Chrome send the URL of that page back to Google for further analysis, and show a warning as appropriate.
Malicious downloads are especially tricky to detect since they’re often posted on rapidly changing URLs and are even "re-packed" to fool anti-virus programs. Chrome helps counter this behavior by checking executable downloads against a list of known good files and publishers. If a file isn’t from a known source, Chrome sends the URL and IP of the host and other meta data, such as the file’s hash and binary size, to Google. The file is automatically classified using machine learning analysis and the reputation and trustworthiness of files previously seen from the same publisher and website. Google then sends the results back to Chrome, which warns you if you’re at risk.
It’s important to note that any time Safe Browsing sends data back to Google, such as information about a suspected phishing page or malicious file, the information is only used to flag malicious activity and is never used anywhere else at Google. After two weeks, any associated information, such as your IP address, is stripped, and only the URL itself is retained. If you’d rather not send any information to Safe Browsing, you can also turn these features off.
This multi-pronged protection combines to make you much safer against the most prevalent attacks on the web while carefully guarding your privacy. We’ve always believed in making the web a safer place for everyone, so we also make the Safe Browsing API available for free to other browsers and websites.
Safe surfing!
Cross posted to: dartlang.org and the Google Code Blog
It took approximately 2000 years for the original Rosetta Stone to be discovered, which helped translate the Egyptian Hieroglyphs. We couldn’t wait that long to bridge the Dart and JavaScript worlds, so today we are releasing the JavaScript to Dart Synonym app.
Like most web developers, we are familiar, comfortable, and productive with JavaScript. We were curious about Dart, and thanks to a recent Dart hackathon, we had the chance to play with the language and libraries. The problem was, as JavaScript developers, we didn’t know how to map common JavaScript idioms to Dart. Hence the idea for this synonym app was born.
We started with the basics that every JavaScript and jQuery developer knows: variables, arrays, functions, classes, DOM manipulation, and many more. Then, with the help of the Dart team, we recorded the corresponding Dart versions of each idiom. To practice what we learned, we wrote this app with Dart.
We hope our app that maps between JavaScript and Dart eases your introduction to Dart and gives you a sense of where the project is going. We know the team is eager to hear your feedback. Don’t hesitate to join the conversation or file a new issue for either Dart or the Synonym app. And remember, Dart isn’t set in stone, so your feedback counts.
It took approximately 2000 years for the original Rosetta Stone to be discovered, which helped translate the Egyptian Hieroglyphs. We couldn’t wait that long to bridge the Dart and JavaScript worlds, so today we are releasing the JavaScript to Dart Synonym app.
Like most web developers, we are familiar, comfortable, and productive with JavaScript. We were curious about Dart, and thanks to a recent Dart hackathon, we had the chance to play with the language and libraries. The problem was, as JavaScript developers, we didn’t know how to map common JavaScript idioms to Dart. Hence the idea for this synonym app was born.
We started with the basics that every JavaScript and jQuery developer knows: variables, arrays, functions, classes, DOM manipulation, and many more. Then, with the help of the Dart team, we recorded the corresponding Dart versions of each idiom. To practice what we learned, we wrote this app with Dart.
We hope our app that maps between JavaScript and Dart eases your introduction to Dart and gives you a sense of where the project is going. We know the team is eager to hear your feedback. Don’t hesitate to join the conversation or file a new issue for either Dart or the Synonym app. And remember, Dart isn’t set in stone, so your feedback counts.
Android und iOS beherrschen die Smartphone - Welt Laut IDC wurden im ersten Quartal 2012 weltweit 152 Millionen Smartphones verkauft. Mehr als die Hälfte davon sind mit Android ausgerüstet, ein knappes Viertel iPhones mit iOS.
(heise)
Elton John Sänger Elton John wurde mit einer schweren Atemwegs erkrankung ins Krankenhaus eingeliefert – der Popstar musste sogar einige Konzerte absagen. Er entschuldigte sich bei den Fans.
(bunte)
SpaceX: Dragon dockt an die ISS an Die Nasa hat das Andocken der privaten Raumfähre Dragon an die ISS erlaubt. Das Manöver hat am frühen Freitag morgen begonnen und soll am Nachmittag abgeschlossen sein.
(golem IT)
Ubuntu 12.04 LTS (Precise Pangolin) zum installieren bereit.