Chrome 14 Blocks Insecure Script, Supports Mac OS X Lion

Google has recently launched the latest version of its remarkable browser, Chrome 14 which improves secure HTTP support in several ways, updates the V8 JavaScript engine to version 3.4.3.0, and tightens security when installing Web apps from the Chrome Web Store. In the battle for web browser supremacy, two key aspects have become increasingly important in the past couple of years: performance and security. With performance reaching a bit of a plateau, security features have become a popular sounding point. 

There’s been no shortage of work on this front lately, from redesigned address bars in Firefox and Opera that highlight secure connections to beefed-up malware protection mechanisms in Internet Explorer and Chrome. One new addition you’ll see in Chrome 14 addresses an issue which plagues many SSL-secured pages across the web. It’s fairly common for “secure” pages to pull certain elements from insecure hosts — including bits like JavaScript which could potentially expose data users think is protected by the SSL connection. Chrome 14 will, by default, block all JavaScript which tries to run via an insecure connection on an SSL-wrapped page. Users can still override the block, but Google wants to head these scripts off at the pass because of the risk they present.

Google is taking HTTPS issues quite seriously and has taken steps to address mixed secure site scripting conditions in Chrome 14 dev. Just after announcing that Gmail will always load in HTTPS, the company has ensured that mixed secure site scripting conditions are blocked by default in Chrome 14 dev. The first is a command line flag that actually landed in Chrome 13 dev called –no-running-insecure-content for advanced users who want to help clean up sites with mixed secure scripts. Another flag is available that will block the display of insecure content, –no-displaying-insecure-content, but Google stated in the above-linked blog post that it will not block displaying insecure content by default since it’s not as dangerous a use-case.

When a website is secured via HTTPS, the web site designer must also ensure that all of the scripts used by the page will be delivered in the same secure manner as the main page itself. The same requirements also apply to the plugins and external CSS stylesheets used by the page, as these have the same considerations as javascript. When this is not the case (sometimes called a ‘mixed script’ situation), visitors to the site run the risk that attackers can interfere with the website and change the script so as to serve their own purposes. Traditionally, browsers have run the mixed script, genuine or not, and notified you after-the-fact by a broken lock icon, a dialog box, or a red https:// in the location bar (in the case of Google Chrome). The problem with this approach is that by the time the script has run, it is already too late, because the script has had access to all of the data on the page. Google Chrome now protects you by refusing up-front to run any script on a secure page unless it is also being delivered over HTTPS.

You can bypass this feature by clicking "Load anyway" in the infobar displayed at the top of the page, but Chrome doesn’t remember your preference. Unfortunately, you can’t whitelist a domain or a subdomain, so you’ll have to click "Load anyway" and wait until the page is reloaded. There’s a command-line flag that lets you disable this feature: –allow-running-insecure-content, but Google says that it should only be used by "users and admins who have internal applications without immediate fixes for these errors".

Plus, Google has updated the alpha "Dev" build of Google Chrome to 14.0.835.2. This minor update is notable largely for the amendment of one of its multi-touch features to avoid a conflict with Mac OS X Lion, which released last week. The latest build basically alters the browser’s own multi-touch gesture for moving backwards and forwards through the browser’s history to two-finger swipe gestures from its original three-finger swipe. This latter gesture is used by Lion to move between desktops and full-screen apps.

The latest build basically alters the browser’s own multi-touch gesture for moving backwards and forwards through the browser’s history to two-finger swipe gestures from its original three-finger swipe. This latter gesture is used by Lion to move between desktops and full-screen apps.

本文轉載brothersoft,編輯僅做翻譯。詳細請查看原網站文章。

Comments are closed.