It’s important for users to know what extensions they have enabled since extensions can sometimes influence Chrome’s functionality and performance. Many users have installed extensions from the Chrome Web Store, but some users have extensions that were silently installed without their knowledge.

Until now, it has been possible to silently install extensions into Chrome on Windows using the Windows registry mechanism for extension deployment. This feature was originally intended to allow users to opt-in to adding a useful extension to Chrome as a part of the installation of another application. Unfortunately, this feature has been widely abused by third parties to silently install extensions into Chrome without proper acknowledgment from users.

Two new features in Chrome 25 will help users run only the extensions they want to use:

Extensions installed by third party programs using external extension deployment options will be disabled by default. When a third party program installs an extension, the Chrome menu will be badged, and users can click through the Chrome menu to see a dialog containing an option to enable the extension or to remove it from their computer.

In addition, all extensions previously installed using external deployment options will be automatically disabled. Chrome will show a one-time prompt to allow the re-enabling of any of the extensions.

Windows application developers should ask users to install Chrome extensions from within Chrome. A great way to allow users to install a Chrome extension related to your Windows application is to link users to your website and use inline installation.

If you have questions, please get in touch with us on the Chromium extensions group.

Posted by Peter Ludwig, Product Manager

Built on Web Components, and inspired by Model Driven Views, Dart's Web UI library is now ready for testing. This early release of Web UI supports dynamic templates, live one-way and two-way data binding, and custom DOM elements. Web UI also includes a compiler that makes these features available to all modern browsers today.

Web UI helps you build declarative apps that have cleaner semantics and structure. You can build and use custom elements like <x-survey> that encapsulate their style, behavior, and structure to hide implementation details like deeply nested HTML tags. Just like HTML tags, these new tags (aka custom elements) can be nested, extended, and shared with other developers.

Web UI also automatically keeps the HTML page and data models in sync with one-way and two-way data binding. Simply declare, in the DOM itself, the bindings between Dart objects and page elements and let Web UI take care of the details.

Here is a small snippet from a simple TODO app that shows some of these features, including:

(1) linking to a custom element
(2) declarative event handling
(3) templates and iteration
(4) data binding with a custom element

To see Dart Web UI in action, we've ported the ubiquitous TodoMVC sample app:

Getting started and installing Web UI is easy with pub, the Dart package manager. Simply add the web_ui package to your list of dependencies and run pub install. Once installed, you can even configure Dart Editor to watch for changes and automatically recompile your Web UI apps for quick and easy edit and reload development cycles.

To learn more about Dart's Web UI package, you can read the docs and browse the summary of features. There's more work to do, and we look forward to your comments on our mailing list.

Posted by Siggi Cherem, Software Engineer

Since we launched Chrome, the team has continued to work on ways to make it fast and simple for people to use. To that end, we’re going to begin testing variations of Chrome’s New Tab page (NTP) in which a user’s default search provider will be able to add a search box or otherwise customize the NTP. While you can search straight from the omnibox in Chrome, we’ve found that many people still navigate to their search engine's home page to initiate a search instead. The goal is to save people time by helping them search and navigate the web faster.

We’ll also allow search engines to display the user’s search terms right in the omnibox, which avoids the need for a second search box on the results page. This new capability, along with other ways to improve search suggestions, are exposed in a new Embedded Search API, an extension of the existing SearchBox API. Search engines can implement any part of the specification if they’d like their users to experience a customized variation of the NTP experience.

Starting today, a small set of users on Dev channel on Windows and Chrome OS, who have Google selected as their search provider, will begin seeing variations of the new experience. Mac will be coming soon. We look forward to your feedback and bug reports, which you can file against the InstantExtended feature on crbug.com.

Posted by David Holloway, Software Engineer

Many popular applications today help users consume, share, manage, and edit media content, as evidenced by the rise of web apps like Google Play Music and YouTube. For Chrome packaged app developers, the new Media Galleries API introduces a simple way for apps to access media stored on a user’s device (with the user’s permission, of course).

To use the API, you first have to determine what kind of permission your app needs to access user’s media:

• read-only: allows media content to be read, but not modified 
• read-write: allows media content to be read and modified 
• add-files: allows media to be added to the galleries but prevents modifying existing media files. 

Currently, only read-only access is supported. Support for read-write and add-files will be introduced in a future release.

To retrieve media content, use getMediaFilesystems(). If this is the first time your app is accessing the user’s media libraries, the system will prompt the user to grant access:



You can also make your app explicitly ask the user to designate specific galleries. This is useful if, for example, your app is only interested in pictures. Once access is granted, your app can then retrieve a list of LocalFileSystem structures. At that point, you can use the W3C FileSystem API to access the media gallery content.



NOTE: The file system APIs will only return files that the Chrome platform natively supports, and only the asynchronous version of the FileSystem API is currently supported.

We’re eager to see what great applications you will build with the Media Galleries API and the Chrome Packaged Apps platform. To get started, clone our samples repository and look at the Media Galleries sample application. Have questions or comments? Subscribe to chromium-apps and follow us on our Google+ page!

Posted by Joe Marini, Developer Advocate

Sandboxing is a layer of security that Chrome places between attackers and their computer, aiming to isolate an attacker who has successfully exploited a vulnerability. When contained in a sandbox jail, an attacker will typically look for porous or fragile bits in the walls to throw rocks at. That is, he’ll try to gain additional privileges by taking advantage of other vulnerabilities. Our job is to make the virtual walls of the sandbox as strong and impenetrable as possible.

One juicy target for attackers is the operating system’s kernel: a large and complex code base. The latest stable version of Chrome introduces a new layer of sandboxing of Chrome renderers for the 64-bit versions of Chrome OS and Linux, based on a new kernel feature called seccomp-bpf. With seccomp-bpf we’ll install a small filter in the kernel that will quickly reject many of the rocks thrown by an attacker. A simple example: if we know that Chrome renderers don’t need a system call such as vmsplice, or a facility such as “inotify”, we can just deny them completely. We use a broker process model to keep the list of allowed system calls small.

Installing this filter in the kernel improves the security of our users. But it is just the beginning: using this new facility, we’ll continue to make the sandbox safer.

This new sandbox layer is automatically baked into the latest version of Chrome OS. On Linux, you can check by going to chrome://sandbox and look for “Seccomp-BPF sandbox Yes”. If this is not available, ask your Linux distribution to include and enable seccomp-bpf in its kernel, as Ubuntu has done since version 12.04.


As always, you can report bugs and issues here, by clicking on “New issue”.

Posted by Julien Tinnes, Software Engineer

Whether your web app involves scrolling down a long list of news headlines or a game with flying birds and crumbling structures, you want your web app to look as smooth as native apps. It used to be tricky to chase down the cause of animation jitter and lag in user actions with Chrome Developer Tools. This is why we’ve added the Frame Mode to our Timeline panel to help you pinpoint offending long frames and understand what’s causing them to run slowly.

So, what’s a frame? A frame includes all the tasks that the browser needs to perform in order to update the screen upon a user action or a tick of the animation timer. A complex, but not uncommon, sequence might be:

1. run JavaScript animations and other event handlers 
2. update CSS animations 
3. recalculate styles and lay out the elements in the DOM 
4. re-paint the updated layers of the page 
5. compose them and present to the user 

Delivering a butter-smooth animation means completing all of the above in less than 16.6ms (common 60Hz refresh rate). If you are not done by then, you’ll miss the frame and the animation will appear janky.

To see how using Timeline can help you, run your favorite browser-based game, then open Developer Tools and record the Timeline while the game is running some animation. The Timeline Frame mode will now show you colored bars, each representing a frame. The colors correspond to different types of timeline events:

• network activity and HTML parsing (blue) 
• running JavaScript (yellow) 
• performing style recalculation and layout (violet) 
• painting and compositing (green) 

You can zoom in by selecting several frames or by clicking on a particular frame of interest. Looking at a specific frame in detailed view will show you the frame duration, and you can find more detailed statistics by hovering on it.



Even if your web app doesn’t have animation in it, the notion of a frame is still useful because the browser performs a repeated sequence of actions while processing input events such as keypress, mouse actions, scrolling etc. Leaving enough time to process such events inside a frame makes your app more responsive and interactive, resulting in a better overall experience for users.

In large web applications with huge DOM trees, layout typically takes time and resources. Doing it in a loop makes things much worse. So we’ve added a warning mark on layouts that were forced, by requesting positional properties (e.g. offsetWidth and offsetHeight) of DOM elements from JavaScript. If you hover over the layout event, you can see two stacks -- one that invalidated the DOM and another that caused layout synchronously. You can also see the area that had to be re-laid highlighted on the screen.



Finally, don’t forget that the best practice for dealing with animations is to use the requestAnimationFrame API, which guarantees that Chromium will call back your animation code in sync with the display refresh.

You can learn more about optimizing rendering performance of a page in Tom Wiltzius’ article on html5rocks.com. Follow Google Chrome Developers on Google+ or @ChromiumDev on Twitter for more news on Chrome Developer Tools.

Posted by Andrey Kosyakov, Software Engineer

Even though Chrome extensions and legacy packaged apps are similar at a technical level, users have very different expectations for how extensions and apps should look and behave. Users expect extensions to interact with the whole browser, whereas they expect apps to act solely in their containing tab or window.

Until now, all Chrome legacy packaged apps could request the same permissions and use the same APIs as extensions to interact with Chrome. In order to make the capabilities of legacy packaged apps more closely align with user expectations, we’ve decided to limit the extensions permissions that legacy packaged apps can request.

Beginning this week, you won’t be able to publish legacy packaged apps in the Chrome Web Store that request any of the following permissions:
(a) any host permissions, including "< all urls >" 
(b) the top-level "content_scripts" key 
(c) the "debugger", "devtools", "pageCapture", "plugin", "proxy", "tabs'", "history", "webNavigation" permissions 
(d) the top-level "npapi" key 

Existing legacy packaged apps in the Chrome Web Store will not be affected, and those existing apps can continue to be updated without being subject to these new restrictions. 

If you have questions, please get in touch with us on the Chromium extensions or Chromium apps groups.

Posted by Peter Ludwig, Product Manager