[go: up one dir, main page]

On May 30, Google announced the next iteration of Project Strobe, a root-and-branch review of third-party developer access to user data. This announcement included the following two updates to our User Data Policy:

  • We’re requiring extensions to only request access to the least amount of data. While this has previously been encouraged of developers, now we’re making this a requirement for all extensions.
  • We’re requiring more extensions to post privacy policies, including extensions that handle personal communications and user-provided content. Our policies have previously required any extension that handles personal and sensitive user data to post a privacy policy and handle that data securely. Now, we’re expanding this category to include extensions that handle user-provided content and personal communications. Of course, extensions must continue to be transparent in how they handle user data, disclosing the collection, use and sharing of that data. 
The policies for these two changes are now published to the updated User Data Policy. They will go into effect on October 15, 2019.

To ensure compliance with this policy update, we suggest developers check their extensions per the guidelines below. After October 15, 2019, items that violate these updates to the User Data policy will be removed or rejected from the Web Store and will need to become compliant to be reinstated. We will continue to take action on violations of the User Data Policy in its current form.

  • Inventory your extensions' current permissions and, where possible, switch to alternatives that are more narrowly scoped. Additionally, include a list of permissions used and the reasons you require them in your Chrome Web Store listing or in an "about page" in your extension. If you expand the features of your extension and require a new permission, you may only request the new permission in the updated version of the extension.
  • If your extension handles Personal or Sensitive User Data, which now also includes, user-provided content and personal communications, your Product must both post a privacy policy and handle the user data securely, including transmitting it via modern cryptography. To add a privacy policy, use the developer dashboard to link to your privacy policy with your developer account. All your published extensions share the same privacy policy.

You can find more information in the updated User Data FAQ. Thank you for joining us in building a better web with transparency, choice and control for both users and developers.


Posted by Alexandre Blondin and Swagateeka Panigrahy, Chrome Product & Policy
Labels: , , , ,

Chrome was built with security in mind from the very beginning. Today we’re launching two new features to help protect users from deceptive websites. The Suspicious Site Reporter Extension will improve security for Chrome users by giving power users an easy way to report suspicious sites to Google Safe Browsing. We’re also launching a new warning to protect users from sites with deceptive URLs.
We designed Chrome to be secure by default, and easy to use by everyone. Google Safe Browsing has helped protect Chrome users from phishing attacks for over 10 years, and now helps protect more than 4 billion devices every day across multiple browsers and apps by showing warnings to people before they visit dangerous sites or download dangerous files. We’re constantly improving Safe Browsing, and now you can help.
Safe Browsing works by automatically analyzing the websites that we know about through Google Search’s web crawlers, and creating lists of sites that are dangerous or deceptive. With the Suspicious Site Reporter extension, you can help Safe Browsing protect web users by reporting suspicious sites. You can install the extension to start seeing an icon when you’re on a potentially suspicious site, and more information about why the site might be suspicious. By clicking the icon, you’re now able to report unsafe sites to Safe Browsing for further evaluation. If the site is added to Safe Browsing’s lists, you’ll not only protect Chrome users, but users of other browsers and across the entire web.
Help us protect web users by reporting dangerous or deceptive sites to Google Safe Browsing through the Suspicious Site Reporter extension.

One way that deceptive sites might try to trick you is by using a confusing URL. For example, it’s easy to confuse “go0gle.com” with “google.com”. In Chrome 75, we’re launching a new warning to direct users away from sites that have confusing URLs.
Starting in the current version of Chrome (75), you’ll see a warning when the page URL might be confused for URLs of sites you’ve visited recently.
This new warning works by comparing the URL of the page you’re currently on to URLs of pages you’ve recently visited. If the URL looks similar, and might cause you to be confused or deceived, we’ll show a warning that helps you get back to safety.

We believe that you shouldn't have to be a security expert to feel safe on the web, and that many Chrome power-users share our mission to make the web more secure for everyone. We’ll continue improving Chrome Security to help make Chrome easy to use safely, and are looking forward to collaborating with the community to further that goal. Install the new extension and start helping protect web users!

Posted by Emily Schechter, Chrome Product Manager
Labels: , , , , ,

The Story So Far
As part of an effort to increase user security and privacy, Chrome is planning a number of changes to the extensions platform. We announced some of these changes last October, and have provided additional context on them today. These changes to the platform are being implemented as part of Manifest V3 – the next version of the Chrome Extensions platform.
One of these changes is to move away from the blocking version of the Web Request API towards a new API, called Declarative Net Request. There’s been a lot of confusion and misconception around both the motivations and implications of this change, including speculation that these changes were designed to prevent or weaken ad blockers. This is absolutely not the goal. In fact, this change is meant to give developers a way to create safer and more performant ad blockers.
In order to improve the security and privacy guarantees of the extensions platform, we are rethinking some of the extension platform's core APIs. That's why we're planning to replace the blocking Web Request API with the Declarative Net Request API.


How Web Request Works
With Web Request, Chrome sends all the data in a network request to the listening extension - including any sensitive data contained in that request like personal photos or emails. The extension has a chance to evaluate the request, and then tells Chrome what to do with the request: allow it, block it, or send it with some modifications. As a result, extensions that leverage the Web Request API typically have access to read and manipulate everything a user does on the web.

While this API is used by good actors to implement powerful features like content blockers, it can also be - and has been - abused. Because all of the request data is exposed to the extension, it makes it very easy for a malicious developer to abuse that access to a user’s credentials, accounts, or personal information. Since January 2018, 42% of malicious extensions use the Web Request API.
In addition to these safety concerns, there are also significant performance costs. In most cases, these costs are not from the evaluation of the extension script processing events, but rather from everything else coordinating the script. That overall performance impact can be very large, even for an extension written as performantly as possible where the JavaScript execution time is negligible.
As it’s designed today, the blocking version of the Web Request API requires a persistent, long-running process, and is fundamentally incompatible with “lazy” processes - processes that can be set up or torn down as-needed, conserving valuable system resources. There are also significant costs associated with the serialization of the request data, the inter-process communication needed to send that data to the extensions, and the processing of extension responses.


Enter Declarative Net Request
The Declarative Net Request API works differently than the Web Request API. Instead of Chrome sending all the information about a request to the listening extensions at the time of the request, extensions register rules that tell Chrome what to do if certain types of requests are seen.

This approach has advantages for both user security and privacy, as well as performance. With a declarative approach, Chrome does not need to expose any sensitive data to the extension. The browser can perform the action requested by the extension without sending it all the data associated with the network request, because the extension already specified the conditions under which different actions are taken. This enables the extension to perform content blocking without needing access to all of a user’s personal information.
This has significant performance implications. Most importantly, a persistent, long-running process is no longer necessary because rules are registered before requests are made rather than needing to process them at runtime. This also cuts down on the cost of serializing all the request data and shuttling the inter-process messages to the listening extensions. These performance improvements will make extensions significantly more viable on resource-constrained platforms.


Why Not Both?
In addition to the performance concerns raised above, the Chrome team strongly believes that users should not have to expose their emails, photos, social media, or any other sensitive data to an extension if the extension doesn’t actually need that access to perform its function. And historically, when extension developers are given the choice between capability and security, the vast majority of developers choose capability. We've seen this repeatedly on the extensions platform with event pages, optional permissions, and activeTab.


Enterprise
Enterprises, schools, and businesses often require different network and software controls to comply with corporate policies. Additionally, these organizations typically have administrators whose role it is to understand and set up their environments.

Chrome provides enterprise controls through its administrator policies. The blocking version of the Web Request API remains available for managed extensions because of the deep integrations that enterprises may have between their software suites and Chrome. System administrators can continue to manage Chrome in enterprise environments for free using OS-provided mechanisms to deploy Chrome policies.


Moving Forward
Declarative Net Request, and the whole of Manifest V3, is still very much in design and development. We are continuing to iterate on it, responding to community feedback and working with developers to help support different use cases.
Since the original announcement of the Declarative Net Request API, we have added significant functionality to the API as a result of these discussions. The Declarative Net Request API now allows for the registration and removal of dynamic rules - specified at runtime rather than statically in the manifest. We’ve also added the capability to remove common tracking headers, such as Referer, Cookie, and Set-Cookie.
We are actively exploring other ways to expand this API, including adding methods to get feedback about matched rules, and support for richer redirects leveraging URL manipulation and regular expressions. Additionally, we are currently planning to change the rule limit from maximum of 30k rules per extension to a global maximum of 150k rules.
We will continue working with the developer community moving forward. We understand that adopting Manifest V3 will require developers to update their extensions and we will continue to support them through this transition.



Posted by Simeon Vincent, Developer Advocate for Chrome Extensions
Labels: , , , , , , ,


Incredibly, it’s been nearly a decade since we launched the Chrome extensions system. Thanks to the hard work and innovation of our developer community, there are now more than 180,000 extensions in the Chrome Web Store, and nearly half of Chrome desktop users actively use extensions to customize Chrome and their experience on the web.
The extensions team's dual mission is to help users tailor Chrome’s functionality to their individual needs and interests, and to empower developers to build rich and useful extensions. But, first and foremost, it’s crucial that users be able to trust the extensions they install are safe, privacy-preserving, and performant. Users should always have full transparency about the scope of their extensions’ capabilities and data access.
We’ve recently taken a number of steps toward improved extension security with the launch of out-of-process iframes, the removal of inline installation, and significant advancements in our ability to detect and block malicious extensions using machine learning. Looking ahead, there are more fundamental changes needed so that all Chrome extensions are trustworthy by default.
Today we’re announcing some upcoming changes and plans for the future:
User controls for host permissions
Beginning in Chrome 70, users will have the choice to restrict extension host access to a custom list of sites, or to configure extensions to require a click to gain access to the current page.



While host permissions have enabled thousands of powerful and creative extension use cases, they have also led to a broad range of misuse - both malicious and unintentional - because they allow extensions to automatically read and change data on websites. Our aim is to improve user transparency and control over when extensions are able to access site data. In subsequent milestones, we’ll continue to optimize the user experience toward this goal while improving usability. If your extension requests host permissions, we encourage you to review our transition guide and begin testing as soon as possible.

Changes to the extensions review process
Going forward, extensions that request powerful permissions will be subject to additional compliance review. We’re also looking very closely at extensions that use remotely hosted code, with ongoing monitoring. Your extension’s permissions should be as narrowly-scoped as possible, and all your code should be included directly in the extension package, to minimize review time.

New code readability requirements
Starting today, Chrome Web Store will no longer allow extensions with obfuscated code. This includes code within the extension package as well as any external code or resource fetched from the web. This policy applies immediately to all new extension submissions. Existing extensions with obfuscated code can continue to submit updates over the next 90 days, but will be removed from the Chrome Web Store in early January if not compliant.
Today over 70% of malicious and policy violating extensions that we block from Chrome Web Store contain obfuscated code. At the same time, because obfuscation is mainly used to conceal code functionality, it adds a great deal of complexity to our review process. This is no longer acceptable given the aforementioned review process changes.


Additionally, since JavaScript code is always running locally on the user's machine, obfuscation is insufficient to protect proprietary code from a truly motivated reverse engineer. Obfuscation techniques also come with hefty performance costs such as slower execution and increased file and memory footprints.
Ordinary minification, on the other hand, typically speeds up code execution as it reduces code size, and is much more straightforward to review. Thus, minification will still be allowed, including the following techniques:

  • Removal of whitespace, newlines, code comments, and block delimiters
  • Shortening of variable and function names
  • Collapsing the number of JavaScript files
If you have an extension in the store with obfuscated code, please review our updated content policies as well as our recommended minification techniques for Google Developers, and submit a new compliant version before January 1st, 2019.
Required 2-Step Verification
In 2019, enrollment in 2-Step Verification will be required for Chrome Web Store developer accounts. If your extension becomes popular, it can attract attackers who want to steal it by hijacking your account, and 2-Step Verification adds an extra layer of security by requiring a second authentication step from your phone or a physical security key. We strongly recommend that you enroll as soon as possible.

For even stronger account security, consider the Advanced Protection Program. Advanced protection offers the same level of security that Google relies on for its own employees, requiring a physical security key to provide the strongest defense against phishing attacks.

Looking ahead: Manifest v3
In 2019 we will introduce the next extensions manifest version. Manifest v3 will entail additional platform changes that aim to create stronger security, privacy, and performance guarantees. We want to help all developers fall into the pit of success; writing a secure and performant extension in Manifest v3 should be easy, while writing an insecure or non-performant extension should be difficult.


Some key goals of manifest v3 include:
  • More narrowly-scoped and declarative APIs, to decrease the need for overly-broad access and enable more performant implementation by the browser, while preserving important functionality
  • Additional, easier mechanisms for users to control the permissions granted to extensions
  • Modernizing to align with new web capabilities, such as supporting Service Workers as a new type of background process

We intend to make the transition to manifest v3 as smooth as possible and we’re thinking carefully about the rollout plan. We’ll be in touch soon with more specific details.


We recognize that some of the changes announced today may require effort in the future, depending on your extension. But we believe the collective result will be worth that effort for all users, developers, and for the long term health of the Chrome extensions ecosystem. We’re committed to working with you to transition through these changes and are very interested in your feedback. If you have questions or comments, please get in touch with us on the Chromium extensions forum.
Posted by James Wagner, Chrome Extensions Product Manager

Labels: , , ,

Event pages keep apps and extensions efficient by allowing them to respond to a variety of events such as timers or navigation to a particular site, without having to remain running persistently. But what if you need to respond to something that occurs outside of Chrome, such as a news alert, a message sent to a user or a stock hitting a price threshold? Until now, you had to do this by repeatedly polling a server. This process consumed bandwidth and reduced the battery life of your users’ machines. For a more efficient solution, starting today you can use Google Cloud Messaging for Chrome (GCM) - across all channels of Chrome.

GCM will be familiar to developers who have used Google Cloud Messaging for Android. To send a message, all you need to do is:
  1. Request a token (channel ID) via chrome.pushMessaging.getChannelId(). 
  2. Pass the returned token to your server. 
  3. Whenever you need to send a message to your app or extension, post the message along with the token to the GCM server-side API. 
Your message is then delivered in near real time to Chrome. This makes your event page wake up (if it’s not already running), and the message is delivered to your chrome.pushMessaging.onMessage listener.



To use GCM, your users must be signed into Chrome, as the service relies on an efficient push channel that’s only established for signed-in users. Messages are automatically delivered to all the devices where the user has signed in and installed your app/extension.

To add GCM to your app/extension, take a look at the overview of the service or start with some of the sample apps—and start pushing!

Posted by Mark Scott, Product Manager
Labels: ,

Last year, Chrome introduced manifest V2 to Apps and Extension developers, which brings a variety of security and API improvements such as a default Content Security Policy. As of Chrome 18, manifest V1 was officially deprecated. At the time, we published our manifest version support schedule to give developers transparency and insight into our plans for migrating to the new version.

Today, we’re announcing a slight update to that schedule, to let developers know that they have until Monday, March 4, 2013 to make updates to their existing manifest V1-based items. After that date, the Chrome Web Store will block all updates to products based on manifest V1 unless the update includes switching it to manifest V2.

Developers are strongly encouraged to migrate their items to manifest V2 now. Follow the migration tutorial, and you can always contact us on the chromium-apps forum and our G+ page with any questions you may have.

Posted by Joe Marini, Developer Advocate
Labels: , ,

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
Labels: ,

If you’re a Chrome extensions power user, you may be familiar with a task manager that looks like this:



That’s a lot of extensions running! Most of the time, they’re probably just sitting idle, waiting for the user to interact with them. Do they really need to be running and using your memory all the time?

Over the last several months, we've been working on a new feature for the extension system called Event Pages that we think will help reduce the memory used by these idle extensions. 

How They Work 

Event pages are an evolution of background pages, with one major improvement: rather than running in the background all the time, an event page only runs when it is handling events. Once an event page becomes idle, it is unloaded, freeing memory until the next time it’s needed. Learn more from the event page documentation.

To help event pages support some important use cases, we’re also developing a few new APIs.
  • The alarms API allows an extension to wake itself up at set times, to support features like periodically syncing data to the cloud. 
  • Some new events let extensions know when they have been installed, or when their event page is being unloaded. 
  • A declarative version of the webRequest API lets extensions do network interception without the need for a background page at all. 
Try it Out 

We plan to release event pages to Chrome’s beta and stable channels late this summer, but you can start experimenting with them on the developer channel today. Try converting your overweight extension to event pages, and let us know how it works.

 Posted by Matt Perry, Software Engineer
Labels: ,

Cross-posted from the Google Developers Blog.

A year ago, we released a preview of the PageSpeed Insights Chrome Developer Tools extension, which analyzes the performance of web pages and provides suggestions to make them faster. Today, we’re releasing version 2.0 of the PageSpeed Insights extension, available in the Chrome Web Store.

PageSpeed Insights analyzes all aspects of a web page load and points out the specific things you can do to make your page faster. For instance, PageSpeed Insights can inform you about an expensive JavaScript call that blocks the renderer for too long, remind you about that new photo on the front page of your web site that you might have forgotten to resize or optimize, or recommend changing the way you load third-party content so it no longer blocks the page load.

PageSpeed Insights for Chrome is a Chrome Developer Tools extension that analyzes all aspects of the page load, including resources, network, DOM, and the timeline. If you're already familiar with Chrome Developer Tools, you'll find that PageSpeed Insights integrates with a toolset you're already using.



Using technologies like Native Client, PageSpeed Insights is able to run the open-source PageSpeed Insights SDK securely and with the performance of native code. Leveraging the Insights SDK enables the Chrome extension to automatically optimize the images, CSS, JavaScript and HTML resources on your web page and provide versions of those resources that you can easily deploy on your website.

We hope you’ll give PageSpeed Insights for Chrome a try and start optimizing your web pages today. We’d love to hear from you, as always. Please try PageSpeed Insights for Chrome, and give us feedback on our mailing list with questions, comments, and new features you’d like to see.


Posted by Libo Song and Bryan McQuade, Software Engineers
Labels: , ,

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:

  1. Extensions can no longer use inline scripts, such as <script> ... </script>. Instead, extensions must use out-of-line scripts loaded from within their package, such as <script src="foo.js"></script>. 
  2. Extensions can no longer use eval(). Note: If you’re using eval to parse JSON today, we suggest using JSON.parse instead. 
  3. Extensions can load plug-ins, such as SWF files, only from within their package or from a whitelist of HTTPS hosts. 
A recent study from researchers at UC Berkeley suggested that these restrictions, taken together, would substantially improve the security of the extension system:

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.


Posted by Adam Barth, Chrome Security Engineer
Labels: ,

Interested in making your Chrome Extension (or packaged app) talk using synthesized speech? Chrome now includes a Text-to-Speech (TTS) API that’s simple to use, powerful, and flexible for users.

Let’s start with the "simple to use" part. A few clever apps and extensions figured out how to talk before this API was available – typically by sending text to a remote server that returns an MP3 file that can be played using HTML5 audio. With the new API, you just need to add "tts" to your permissions and then write:

chrome.tts.speak('Hello, world!');

It’s also very easy to change the rate, pitch, and volume. Here’s an example that speaks more slowly:

chrome.tts.speak('Can you understand me now?', {rate: 0.6});

How about powerful? To get even fancier and synchronize speech with your application, you can register to receive callbacks when the speech starts and finishes. When a TTS engine supports it, you can get callbacks for individual words too. You can also get a list of possible voices and ask for a particular voice – more on this below. All the details can be found in the TTS API docs, and we provide complete example code on the samples page.

In fact, the API is powerful enough that ChromeVox, the Chrome OS screen reader for visually impaired users, is built using this API.

Here are three examples you can try now:

    TTS Demo (app)
    Talking Alarm Clock (extension)
    SpeakIt (extension)

Finally, let's talk about flexibility for users. One of the most important things we wanted to do with this API was to make sure that users have a great selection of voices to choose from. So we've opened that up to developers, too.

The TTS Engine API enables you to implement a speech engine as an extension for Chrome. Essentially, you provide some information about your voice in the extension manifest and then register a JavaScript function that gets called when the client calls chrome.tts.speak. Your extension then takes care of synthesizing and outputting the speech – using any web technology you like, including HTML5 Audio, the new Web Audio API, or Native Client.

Here are two voices implemented using the TTS Engine API that you can install now:

    Lois TTS - US English
    Flite SLT Female TTS - US English

These voices both use Native Client to synthesize speech. The experience is very easy for end users: just click and install one of those voices, and immediately any talking app or extension has the ability to speak using that voice.

If a user doesn't have any voices installed, Chrome automatically speaks using the native speech capabilities of your Windows or Mac operating system, if possible. Chrome OS comes with a built-in speech engine, too. For now, there's unfortunately no default voice support on Linux – but TTS is fully supported once users first install a voice from the Chrome Web Store.

Now it's your turn: add speech capability to your app or extension today! We can't wait to hear what you come up with, and if you talk about it, please add the hashtag #chrometts so we can join the conversation. If you have any feedback, direct it to the Chromium-extensions group.

Posted by Dominic Mazzoni, Software Engineer
Labels: ,

Are you already a happy user of Chrome Developer Tools but always wanted that particular feature added to make you even more productive? Then we have some exciting news for you: our developer tools are now extensible!

You can now add new panels and sidebar section panes, retrieve network requests data, evaluate scripts on the page being inspected, and add custom audit rules.



The extension support is still experimental, but we wanted to let you know early, so we can incorporate your feedback before releasing the APIs.

Here’s how to get started with writing extensions for Chrome Developer Tools:
  • Use the dev channel of Chrome as the APIs are still under development;
  • Enable experimental extension APIs using the chrome://flags page;
  • List experimental in the permissions list of your extension;
  • Add a devtools_page field to your extension’s manifest, e.g:
{
"name": ...
"minimum_chrome_version": "14.0",
"devtools_page": "devtools.html",
"permissions": [ "experimental" ... ],
...
}

The developer tools extension pages get access to the chrome.experimental.devtools.* APIs which are described further in our docs. Be sure to check out the sample extensions, which include extensions for jQuery and FirePHP users and a simple audit extension that finds broken links.

For a richer example, you can also check out Page Speed for Chromium, which uses the extensions API to provide Page Speed suggestions right in the Chrome Devtools UI.

We’re looking forward to seeing your feedback on the APIs and, of course, cool extensions coming to life!

Posted by Andrey Kosyakov, Software Engineer
Labels: ,

In Chrome 13, we added some new capabilities to content scripts and proxy management.

First, you can now make cross-origin XMLHttpRequest calls with the privileges of the extension directly from your content script. You will no longer need to relay these requests through a background page; this should simplify your code. In some cases, it may even eliminate your need to use a background page. Here’s a sample extension which demonstrates the old way a content script could make a cross domain request. As you can see, the extension required a background page to route the cross-origin calls through a chrome.extension.onRequest listener. Using the new content script cross-origin capabilities, we were able to successfully rewrite the extension to completely eliminate the background page requirement. This reduces the memory required to run the extension, and reduces code complexity as well. This also means that Greasemonkey scripts that use GM_xmlhttpRequest - such as the classic Book Burro - will now work in Chrome.

Second, we improved how match patterns work. Until this release you could specify a matches array for your content script - the URLs over which it should operate. In Chrome 13 you can now also specify an exclude_matches array, where you can indicate the pages in which your content scripts should not work. This should allow more precise targeting of your content script.

Finally, we added support for the @run-at command for imported Greasemonkey scripts, so you can control when your script is loaded in the same way you’ve been able to do for content scripts. Running scripts at different points in a page's lifecycle can enable additional functionality. For example, we've written a script which runs at "document-start" and lists all of the HTTP resources included in the current page.

In addition to these improvements to scripts, we’ve been working hard to allow extensions to manage Chrome’s proxy settings using different configuration options. With the Proxy Extension API, you can now configure proxy settings by choosing from several options including auto detection, the host OS’s system default, PAC scripts or fixed ProxyRules.

These new configuration options allow for more fine grained proxy controls, which we invite you to try out. There are already several 3rd party extensions available in the Chrome Web Store that showcase the API and its new capabilities, including Proxy Anywhere and Proxy SwitchyPlus.

Let us know what you think of these new features and what else you might like to see us do by joining the discussion at chromium-extensions@chromium.org.

Posted by Tessa MacDuff and Mihai Parparita, Software Engineers
Labels:

Cross posted at the Google Code blog

We recently unveiled ChromeVox — a built-in screen reader for Chrome OS — during Google I/O 2011. This is an early developer beta that is designed to help authors of web applications come up to speed with platform accessibility on Chrome OS.

ChromeVox is built as a Chrome extension — this means that unlike most accessibility software, it is built using only web technologies like HTML5, CSS and Javascript. As the built-in accessibility solution for Chrome OS, it can help users with special needs access modern web apps, including those that utilize W3C ARIA (Access to Rich Internet Applications) to provide a rich, desktop-like experience.

ChromeVox leverages two of Chrome's experimental extension APIs, the experimental.tts API for cross-platform text-to-speech, and the experimental.accessibility API that lets an extension listen for accessibility events in Chrome's menus and toolbars. In turn, ChromeVox exposes a simple screen reader API to web developers who wish to further customize the ChromeVox user experience. Thus, within your application, you can:
  • Automatically generate spoken messages and earcons.
  • Set ChromeVox to synchronize with your application's current focus.
ChromeVox also comes with an interactive online tutorial that demonstrates how users of spoken feedback interact with webpages. Examples range from static content to interactive applications. You can test these same navigation techniques within your own applications to quickly verify users can reach all portions of your application using the keyboard and obtain meaningful feedback. You can then annotate your application with the necessary ARIA properties and other accessibility enhancements to ensure that blind and visually impaired users gain complete access to your application. Please see our Google I/O 2011 talk for more.

Details on enabling accessibility in Chrome OS can be found on the Accessibility help page, and the Chrome extension is available for download from our Wiki page. For now, ChromeVox is targeted at end-users on Chrome OS, but it may also prove a useful tool to web developers using Chrome on all major platforms. We welcome your feedback via our Open Source project website at http://google-axs-chrome.googlecode.com.

Posted by T.V. Raman, Research Scientist
Labels: ,