Chromium Blog

Keeping spam off the Chrome Web Store

Wednesday, April 29, 2020

Since the introduction of the Chrome Web Store in 2011, it has become the largest catalog of browser extensions with over 200,000 available to all of our users. This has helped millions of users to customize their browsing experience on Chrome in ways we could have never imagined, from niche utilities to companies building businesses around the platform’s capabilities.

In response, our abuse systems and review teams have been hard at work ensuring that the Chrome Web Store is free from abuse, as many of our developers have noticed an increase in review times lately. However, the increase in adoption of the extension platform has also attracted spammers and fraudsters introducing low-quality and misleading extensions in an attempt to deceive and trick our users into installing them to make a quick profit. We want to ensure that the path of a user discovering an extension from the Chrome Web Store is clear and informative and not muddled with copycats, misleading functionalities or fake reviews and ratings. Therefore, in order to keep the quality of our inventory high and help users find what they want, we’re introducing some updates to our spam policy:

Developers or their affiliates should not publish multiple extensions that provide duplicate experiences or functionality on the Chrome Web Store.

Extensions should not have misleading, improperly formatted, non-descriptive, irrelevant, excessive, or inappropriate metadata, including but not limited to the extension’s description, developer name, title, icon, screenshots, and promotional images. Developers must provide a clear and well-written description. Unattributed or anonymous user testimonials in the app's description are also not allowed.

Developers must not attempt to manipulate the placement of any extensions in the Chrome Web Store. This includes, but is not limited to, inflating product ratings, reviews, or install counts by illegitimate means, such as fraudulent or incentivized downloads, reviews and ratings.

Extensions with a single purpose of installing or launching another app, theme, webpage, or extension are not allowed.

Extensions that abuse, or are associated with the abuse of, notifications by sending spam, ads, promotions, phishing attempts, or unwanted messages that harm the user’s browsing experience are not allowed. Extensions that send messages on behalf of the user without giving the user the ability to confirm the content and intended recipients are also not allowed.

The new policy can be found in our updated Developer Program Policies.

Developers must comply with this policy by August 27th 2020. After that date, extensions that violate the updated policy may be taken down and disabled. You can learn more about these changes and how they may apply to you in our Spam policy FAQ.

Posted by Rebecca Soares and Benjamin Ackerman, Chrome Policy and Anti-Abuse Team

Chrome 83 Beta: Cross-site Scripting Protection, Improved Form Controls, and Safe Cross-origin Resource Sharing

Friday, April 17, 2020

ChromeStatus.com Trusted Types for DOM ManipulationElement.innerHTMLContent-Security-Policy: require-trusted-types-for 'script'; report-uri //my-csp-endpoint.example Prevent DOM-based cross-site scripting vulnerabilities with Trusted Types Improved Form Controls

Improving form controls in Microsoft Edge and ChromiumUpdates to Form Controls and Focus New Cross-Origin PoliciesCross-Origin-Embedder-PolicyCross-Origin-Opener-Policy

Performance.measureMemory()

JS Self-Profiling API

document.domainMaking your website "cross-origin isolated" using COOP and COEP Origin TrialsOrigin Trials dashboardOrigin Trials Guide for Web Developers Native File SystemThe Native File System API: Simplifying access to local files Performance.measureMemory()Performance.measureMemory()

Analysis of correlation between memory usage and user metrics

Detection of memory regressions

Evaluation of feature launches in A/B tests

Memory optimization.

Monitor your web page's total memory usage with performance.measureMemory() Prioritized Scheduler.postTask()Scheduler.postTask()user-blockinguser-visiblebackgroundTaskController WebRTC Insertable StreamsWebRTC Insertable Streams APIMediaStreamTrackRTCPeerConnection Other features in this release ARIA AnnotationsNew ARIA annotations<mark> 'auto' keyword for '-webkit-appearance' CSS property-webkit-appearance a new auto keyword-webkit-appearanceappearance Barcode Detection API<image><video><canvas>Google Play ServicesThe Shape Detection API: a picture is worth a thousand words, faces, and barcodes CSS contain-intrinsic-sizecontain-intrinsic-sizecontain: sizecontain-intrinsic-sizeavailable from the WICG CSS Color Adjust: color-scheme meta tagprefers-color-schemeImproved dark mode default styling with the color-scheme CSS property and the corresponding meta tag display:inline-grid/grid/inline-flex/flex for <button>displayinline-gridgridinline-flexflexnow function with the <button> elementDemo ES Modules for shared workers ('module' type option)moduleWhat about shared workers Improvements to font-display: optionalfont-display

Setting font-display to optional no longer causes relayout

Web font preloading is allowed to slightly block rendering (for all font-display values), so that if the font loads fast enough, we don't need to render with fallback.

font-display: optionalPrevent layout shifting and flashes of invisibile text (FOIT) by preloading optional fonts IndexedDB relaxed durability transactionsIDBDatabase.transaction()durability"default""strict""relaxed""default"IDBTransaction.durabilityconst iDBTransaction = database.transaction( [ "storeName" ], "readwrite", { durability: "relaxed" } ); Out-Of-Renderer Cross-Origin Resource Sharing Reversed range for <input type=time>now supports reversed ranges for <input> elementstypetime Support "JIS-B5" and "JIS-B4" @pagenow supports two page sizes for the @page rule

"JIS-B5": 182mm wide by 257mm high

"JIS-B4": 257mm wide by 364mm high

@supports selector() feature query function@supportsfeature detection for CSS selectors@supports selector(::before) { div { background: green }; } WebRTC RTCPeerConnection.canTrickleIceCandidatescanTrickleIceCandidates RTCRtpEncodingParameters.maxFramerateThis encoding parameterRTCRtpSender.setParameters()RTCRtpEncodingParameters.maxFrameratemaxFramerate RTCRtpSendParameters.degradationPreferenceRTCRtpSendParametersdegradationPreferencedegradationPreference"maintain-framerate""maintain-resolution""balanced" WebXR DOM Overlaytwosamples JavaScriptlist of recent features fractionalSecondDigits option for Intl.DateTimeFormatadds the fractionalSecondDigits propertyIntl.DateTimeFormatDateTimeFormat Deprecations, and Removalscurrent deprecationsprevious removals Disallow Downloads in Sandboxed iframesprevents downloads in sandboxed iframes'allow-downloads'Posted by Joe Medley

Temporarily rolling back SameSite Cookie Changes

Friday, April 3, 2020

Chrome 80 in FebruaryongoinggraduallySameSite Updates page

Updates to Form Controls and Focus

Monday, March 30, 2020

HTML form controls provide the backbone for much of the web's interactivity. They're easy for developers to use, have built-in accessibility, and are familiar to our users. One issue with native form controls, however, is the inconsistency in their styling. Older controls, such as <button> and <select> were styled to match the user's operating system. Form controls that were added to the platform more recently were designed to match whatever style was popular at the time. For Chromium based browsers, this has led to controls that look mismatched and sometimes outdated, which causes developers to spend extra time (and ship extra code) styling around the controls' default appearance.

a meter, progress, and input type range element stacked vertically. Their visual styles are very different.

<meter>, <progress>, and <input type="range"> look like they come from different worlds in Chrome 80 on Windows.

To help fix this problem, the teams at Microsoft Edge and Google Chrome spent the last year collaborating to retheme and improve the functionality of the built-in form controls on Chromium browsers. The two teams also worked to make the focused states of form controls and other interactive elements like links easier to perceive. These changes are available today in Edge on Windows, and may be seen in Chrome 81 as part of experiments. The chrome://flags/#form-controls-refresh enables the changes in Chrome 81 as well. The changes will roll out in Chrome 83 on Windows, macOS, ChromeOS, and Linux. See the updated release schedule for Chrome 81 and 83. Updates for Chrome on Android should roll out later this year. If you want to hear more about what's coming to form controls, take a look at Nicole Sullivan and Greg Whitworth's talk from CDS 2019. A Fresh Coat of Paint The two teams wanted to make the controls feel like they were part of a matched set. This meant doing away with gradients and using more of a flat design inspired by current design systems. As Nicole Sullivan, a member of the Chrome team, describes it: We were going for beautiful, webby, and neutral. We hope that every design system would see a bit of themselves in the new designs and easily imagine how they might be adapted for their own branding. Below is a comparison of the form controls as they previously appeared in Chromium and as they appear after the redesign: Form controls as they appear in Chrome 80

Form controls as they appear in Chrome 80

Form controls as they appear after the redesign. The styles are much more consistent.

Left: Prior styling of form controls in Chrome 80.

Right: Controls as they appear after the redesign.

Improved Accessibility and Touch Support In addition to improving the default styling, the two teams also tuned up form controls' accessibility and enhanced touch support.
These changes are most notable in a few key areas: A More Visible Focus Ring The focus indicator—sometimes referred to as the "focus ring"—is an important accessibility feature that helps people using a keyboard or switch device to identify which element they're interacting with.
Previously, Chromium used a light single color outline to indicate the focused element. However, if the focused element happened to be on a similarly colored background, the ring would be difficult to perceive:
A button on a blue background. The focus indictor on the button is not discernible.

A button on a blue background. The focus indictor on the button is not discernible.

The previous focus ring on a similarly colored background.

The new focus indicator uses a thick dark ring with a thin white outline, which should improve visibility on both light and dark backgrounds. This is an easy accessibility win that automatically improves the keyboarding experience on a number of sites without developers needing to write any new code.
Black and white double-strokes make the focus ring visible on both light background and dark background

Black and white double-strokes make the focus ring visible on both light background and dark background

The new two-line design for the focus indicator ensures that it's visible on both black and white backgrounds.

Note that there are still some scenarios where the focus ring may be hard to perceive—for example, if a black button is on a white background, or if the focus ring is clipped by elements that are positioned closely together.
If you run into a scenario where the focus ring is hard to perceive, or if the new focus indicator does not match the design of your site, there are ways to style focus including the new :focus-visible pseudo-class, which provides fine-grained control over when the focus indicator is displayed. Increased Tap Target Sizes for Multi-input Displays Over the past few years we've seen an increase in multi-input devices like 2-in-1 devices, tablets, and touch-enabled laptops. This means that touch becomes an important consideration for desktop. However, many of the existing form controls were not designed with multi-input surfaces in mind. For example, <input type="date"> works great on mobile, but the tap targets are much too small to be usable on a touch-screen laptop.
The input type date element as it appears in Chrome 80. The element has very small buttons for incrementing and decrementing the date.

The input type date element as it appears in Chrome 80. The element has very small buttons for incrementing and decrementing the date.

The previous design for <input type="date"> with small tap targets.

To improve functionality on touch screens, the updated controls will now have better flyouts, larger tap targets, and support for swiping and inertia when scrolling:
The redesigned input type date element. It has large buttons and easy to click dates.

The redesigned input type date element. It has large buttons and easy to click dates.

The new design for <input type="date"> with much more accessible tap targets
Improved Color Picker Previously the <input type="color"> element was not fully keyboard accessible, meaning users relying on a keyboard or switch device couldn't use it. Along with a new appearance, the control is also now fully keyboard accessible and includes additional modifier keys (Control, or Command on Mac). These improvements let users jump by ten color values at a time.
An animation of the redesigned color picker, showing improved keyboard navigation

An animation of the redesigned color picker, showing improved keyboard navigation

The new <input type="color"> with improved keyboard accessibility.

More Consistent Keyboard Access Finally, the teams updated the ARIA role mapping of all the controls to match the recommendations in the HTML Accessibility API Mappings specification. This should provide a more consistent experience for anyone relying on a keyboard or assistive technology, like a screen reader, to access the page. How You Can Get Involved While the design refresh is a much needed change, the two teams have also heard from developers that it should be easier to style the built-in form controls and plan to tackle that work next. If you're excited by the idea of improved styling, functionality, and possibly even new high-level components, the folks at Edge and Chrome need your help! Test Your Sites Try out the new form controls and focus indicator in Edge and Chrome Beta. If the design changes have negatively affected your existing sites or apps, let us know using this bug template. Or, if you find a related bug, give it a star! ⭐️ Starring is extremely valuable because it helps platform teams triage and decide what to work on next. Tell us What You Want to See Much of the work on the new form controls was enabled through surveying developers, and interviewing design system and UI framework authors. In an effort to help centralize this feedback and include as many developers as possible in the standards process, the team at Edge have created open-ui.org. If you work on a design system, or a UI component set, consider sharing your knowledge on Open UI to help classify and identify gaps in the existing form controls.
Posted by Rob Dodson, Developer Advocate

Chrome and Chrome OS release updates

Thursday, March 26, 2020

Cross-posted from the Chrome Releases Blog We previously paused upcoming releases for Chrome and Chrome OS. Today we’re sharing an update as we’re now resuming releases with an adjusted schedule:

M83 will be released three weeks earlier than previously planned and will include all M82 work as we cancelled the M82 release (all channels).

Our Canary, Dev and Beta channels have or will resume this week, with M83 moving to Dev, and M81 continuing in Beta.

Our Stable channel will resume release next week with security and critical fixes in M80, followed by the release of M81 the week of April 7, and M83 ~mid-May.

We will share a future update on the timing of the M84 branch and releases.

We continue to closely monitor that Chrome and Chrome OS are stable, secure, and work reliably. We’ll keep everyone informed of any changes on our schedule on our release blog and will share additional details on the schedule in the Chromium Developers group, as needed. You can also check our schedule page for specific dates for each milestone at any time. Thanks everyone for the help and patience during this time. Posted by the Chrome Release Team

Upcoming Chrome releases

Wednesday, March 18, 2020

Cross-posted from the Chrome Releases Blog Due to adjusted work schedules at this time, we are pausing upcoming Chrome and Chrome OS releases. Our primary objectives are to ensure Chrome continues to be stable, secure, and work reliably for anyone who depends on them. We’ll continue to prioritize any updates related to security, which will be included in Chrome 80.Chrome Releases blog

New developer dashboard and registration flow for Chrome Web Store

Thursday, March 12, 2020

Chrome Web Store New dashboard is now the default

When you click Settings > Developer Dashboard on the Chrome Web Store home page.

When you follow existing bookmarks or links to the developer dashboard.

When you navigate explicitly to chrome.google.com/webstore/developer/dashboard.

Opting out means that you’ll see the old dashboard in each of the cases listed above. You can always opt in again by clicking the link in the old dashboard’s banner:

Opting out is useful for specific use cases that affect a small number of developers. The new dashboard does not yet support the following tasks:

Transfer items

Edit or publish a paid item, or add in-app purchases, using Chrome Web Store Payments

View an item’s public key

Re-order screenshots

Preview a new version of your item or promotional tiles

View revenue stats

known issues document Developer registration fee now required earlier

Developers who previously published items to the public were required to pay the registration fee at that time. These developers do not need to pay the fee again: no action is required.

New developers must register and pay this fee before they can use the Chrome Web Store developer dashboard.

Previously registered developers who have never published an item to the public must now pay this fee before they can use the CWS developer dashboard. If you have published to private domain or to trusted testers, but not to the public, you will now need to pay the registration fee. Note: This will look like a new developer registration flow, but all that’s required is to pay the fee and complete the flow.