spacer

The Future of JavaScript – take a peek today!

Friday, February 10, 2012

Labels: javascript

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:

  • 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. 
 ...and there is a lot more to come, as the V8 team will continue working on bringing new Harmony features to you.

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!

Posted by Andreas Rossberg and Michael Starzinger, Software Engineers

GPU accelerating 2D Canvas and enabling 3D content for older GPUs

Thursday, February 09, 2012

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 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.

Expanding the Chromium Security Rewards Program

Thursday, February 09, 2012

Labels: security

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:

  • 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.
Chromium OS security bugs should be reported in the Chromium OS bug tracker, whilst security bugs affecting the desktop Chromium browser should be reported in the Chromium bug tracker.
  • 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. 
Perhaps most importantly, this program reflects several of our core security principles: engaging the community, building defense in depth, and particularly making the web safer for everyone.

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.

Posted by Chris Evans, Google Chrome Security

A deeper look at Chrome for Android

Tuesday, February 07, 2012

Labels: mobile

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.

Posted by Arnaud Weber, Engineering Manager, Chrome

All About Safe Browsing

Tuesday, January 31, 2012

Labels: New Features, security


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.

spacer

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.

spacer

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!

Posted by Niels Provos, Software Engineer, and Ian Fette, Product Manager

Translating JavaScript to Dart

Monday, January 30, 2012

Labels: dart

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.

spacer

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.

Posted by Aaron Wheeler and Marcin Wichary

Making the web speedier and safer with SPDY

Thursday, January 26, 2012

Labels: spdy

In the two years since we announced SPDY, we’ve been working with the web community on evolving the spec and getting SPDY deployed on the Web.

Chrome, Android Honeycomb devices, and Google's servers have been speaking SPDY for some time, bringing important benefits to users. For example, thanks to SPDY, a significant percentage of Chrome users saw a decrease in search latency when we launched SSL-search. Given that Google search results are some of the most highly optimized pages on the internet, this was a surprising and welcome result.

We’ve also seen widespread community uptake and participation. Recently, Firefox has added SPDY support, which means that soon half of the browsers in use will support SPDY. On the server front, nginx has announced plans to implement SPDY, and we're actively working on a full featured mod-spdy for Apache. In addition, Strangeloop, Amazon, and Cotendo have all announced that they’ve been using SPDY.

Given SPDY's rapid adoption rate, we’re working hard on acceptance tests to help validate new implementations. Our best practices document can also help website operators make their sites as speedy as possible.

With the help of Mozilla and other contributors, we’re pushing hard to finalize and implement SPDY draft-3 in early 2012, as standardization discussions for SPDY will start at the next meeting of the IETF.

We look forward to working even closer with the community to improve SPDY and make the Web faster!

To learn more about SPDY, see the link to a Tech Talk here, with slides here.

Posted by Roberto Peon and Will Chan, Software Engineers

Older Posts

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.