Chromium Blog: extensions

Project Strobe: Updates to Our User Data Policy

Tuesday, July 23, 2019

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.

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.

User Data FAQ.
Posted by Alexandre Blondin and Swagateeka Panigrahy, Chrome Product & Policy

New Chrome Protections from Deception

Tuesday, June 18, 2019

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

Web Request and Declarative Net Request: Explaining the impact on Extensions in Manifest V3

Wednesday, June 12, 2019

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

Trustworthy Chrome Extensions, by default

Monday, October 1, 2018

li { line-height: 1.38 !important; } 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

Building efficient apps and extensions with push messaging

Thursday, May 9, 2013

Google Cloud Messaging for ChromeGoogle Cloud Messaging for Android

Request a token (channel ID) via chrome.pushMessaging.getChannelId().

Pass the returned token to your server.

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.

chrome.pushMessaging.onMessage

overviewsample appsPosted by Mark Scott, Product Manager

Updates to manifest V1 Chrome Web Store items to be blocked in March

Wednesday, February 6, 2013

manifest V2Content Security Policymanifest version support scheduleChrome Web Storeblock all updatesmigration tutorialchromium-apps forumour G+ pagePosted by Joe Marini, Developer Advocate

Restricting extension APIs in legacy packaged apps

Thursday, November 15, 2012

legacy packaged apps< 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. Chromium extensionsChromium apps
Posted by Peter Ludwig, Product Manager

Put your extensions on a diet with event pages

Thursday, June 21, 2012

Event PagesHow They Work background pagesevent page documentation

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 developer channellet us know
Posted by Matt Perry, Software Engineer

Make your website faster with PageSpeed Insights

Tuesday, June 12, 2012

Cross-posted from the Google Developers Blog.PageSpeed InsightsChrome Web Store

Native ClientPageSpeed Insights SDKPageSpeed Insights for Chromemailing list
Posted by Libo Song and Bryan McQuade, Software Engineers

More secure extensions, by default

Wednesday, February 29, 2012

with security in mindContent-Security-Policyopt into these featuresmanifest_versionscript-src 'self'; object-src 'self'

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

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.

recent studyimprove the securityThese defenses are extremely effective: adopting one of the recommended CSPs would prevent 96% (49 out of 51) of the core extension vulnerabilities we found. manifest_versionmanifest_versionmanifest_versiona complete listmore detailsextension documentationmailing list
Posted by Adam Barth, Chrome Security Engineer

New Text-to-Speech API for Chrome extensions

Tuesday, October 18, 2011

packaged appchrome.tts.speak('Hello, world!');
chrome.tts.speak('Can you understand me now?', {rate: 0.6});
TTS API docssamples pageChromeVoxTTS DemoTalking Alarm ClockSpeakItTTS Engine APIchrome.tts.speakHTML5 AudioWeb Audio APINative ClientLois TTS - US EnglishFlite SLT Female TTS - US English#chromettsChromium-extensionsPosted by Dominic Mazzoni, Software Engineer

New developer tools experimental APIs for Chrome extensions

Monday, October 3, 2011

Chrome Developer Tools

your feedback

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" ... ], ... }docssample extensionsPage Speed for ChromiumPosted by Andrey Kosyakov, Software Engineer

Chrome Extensions: Now with more powerful scripts and improved proxy management.

Wednesday, July 13, 2011

sample extensionbackground pagechrome.extension.onRequestrewrite the extensionGM_xmlhttpRequestBook Burromatch patternsmatchesexclude_matches@run-ata scriptProxy Extension APIProxyRulesProxy AnywhereProxy SwitchyPlusPosted by Tessa MacDuff and Mihai Parparita, Software Engineers

ChromeVox: Built-In Spoken Feedback For Chrome OS

Thursday, May 19, 2011

Cross posted at the Google Code blogChromeVoxW3C ARIAexperimental.tts APIsimple screen reader API

Automatically generate spoken messages and earcons.

Set ChromeVox to synchronize with your application's current focus.

online tutorialGoogle I/O 2011 talkAccessibility help pageour Wiki pagehttp://google-axs-chrome.googlecode.comPosted by T.V. Raman, Research Scientist

Mar	APR	May
	12
2021	2022	2023

Chromium Blog