Today, the Better Ads Standards consists of 12 ad experiences that research found to be particularly annoying to users. Image Source: Coalition for Better Ads


Evaluating sites for violations
Sites are evaluated by examining a sample of pages from the site. Depending on how many violations of the Better Ads Standards are found, the site will be evaluated as having a status of Passing, Warning, or Failing. The evaluation status of sites can be accessed via the Ad Experience Report API. Site owners can also see more detailed results, such as the specific violations of the Better Ads Standards that were found, via the Ad Experience Report in Google’s Search Console. From the Report site owners can also request that their site be re-reviewed after they have addressed the non-compliant ad experiences.

The Ad Experience Report in Google's Search Console allows site owners to see their overall site evaluation status, as well as the specifics of any violations identified on their site.


Filtering on sites at the network level
At a technical level, when a Chrome user navigates to a page, Chrome’s ad filter first checks if that page belongs to a site that fails the Better Ads Standards. If so, network requests on the page — such as those for JavaScript or images — are checked against a list of known ad-related URL patterns. If there is a match, Chrome will block the request, preventing the ad from displaying on the page. This set of patterns is based on the public EasyList filter rules, and includes patterns matching many ad providers including Google’s own ad platforms, AdSense and DoubleClick.

What this looks like in Chrome
Chrome will automatically block ads on sites that fail the Better Ads Standards, using the approach described above. When at least one network request has been blocked, Chrome will show the user a message indicating that ad blocking has occurred as well as an option to disable this setting by selecting “allow ads on this site.” For desktop users, the notification in Chrome's address bar will look similar to Chrome's existing pop-up blocker. Android users will see message in a small infobar at the bottom of their screen, and can tap on “details” to see more information and override the default setting.

Chrome will automatically block intrusive ads on sites that have been found to violate the Better Ads Standards, but users have the option to disable the feature by selecting “allow ads on this site.” 


Early results show positive progress for users
While the result of this action is that Chrome users will not see ads on sites that consistently violate the Better Ads Standards, our goal is not to filter any ads at all but to improve the experience for all web users. As of February 12, 42% of sites which were failing the Better Ads Standards have resolved their issues and are now passing. This is the outcome we were hoping for — that sites would take steps to fix intrusive ads experiences themselves and benefit all web users. However, if a site continues to maintain non-compliant ad experiences 30 days after being notified of violations, Chrome will begin to block ads on that site.

We're encouraged by early results showing industry shifts away from intrusive ad experiences, and look forwarding to continued collaboration with the industry toward a future where Chrome's ad filtering technology will not be needed.

Posted by Chris Bentzel, Engineering Manager

Screenshot of the Chrome Developer Tools integration of the ServerTiming API.

Other features in this release

Blink > CSS


  • Developers can now use the :any-link pseudo-selector to apply CSS properties to all unvisited or visited hyperlink elements.
  • The syntax for specifying HSL/HSLA and RGB/RGBA coordinates for the color property now match the CSS Color 4 spec.
  • Developers can use display:contents to generate boxes for an element’s children and pseudo-elements without generating the parent box.

Blink > DOM



  • To complement assignedNodes(), the <slot> element now has an assignedElements() method, which returns only the element nodes assigned to a given slot.
  • Chrome now supports the HTMLAnchorElement.relList property to indicate the relationship between the resource represented by the <a> element and the current document. Thanks to Samsung for this contribution!

Blink > Feature Policy

Blink > Network

  • To match compatibility with the TLS spec, Chrome now supports the draft-23 version of the TLS 1.3 protocol.
  • Developers can use Request.destination to evaluate which resource their service worker is fetching.

Blink > Performance APIs

  • As WebIDL was deprecated, PerformanceResourceTiming, PerformanceLongTaskTiming, and TaskAttributionTiming now support the toJSON method to convert objects to JSON.

Blink > Security

  • To protect users against cross-origin information leakage, Chrome will ignore the presence of the download attribute on anchor elements with cross-origin attributes.

Deprecations and interoperability improvements

Blink > Bindings

  • To match compatibility with the HTML spec, document.all is no longer overwritable.

Blink > Network

  • As previously announced, Chrome 65 will not trust certificates issued from Symantec’s Legacy PKI after December 1st, 2017, and will result in interstitials. This will only affect site operators who explicitly opted-out of the transition from Symantec’s Legacy PKI to DigiCert’s new PKI, and does not apply to the previously disclosed independent sub-CAs from this infrastructure.
For a complete list of all features (including experimental features) in this release, see the Chrome 65 milestone hotlist.

Posted by Ian Kilpatrick, Patiently Painting Engineer
Labels:


In Chrome 68, the omnibox will display “Not secure” for all HTTP pages.

Developers have been transitioning their sites to HTTPS and making the web safer for everyone. Progress last year was incredible, and it’s continued since then:

  • Over 68% of Chrome traffic on both Android and Windows is now protected
  • Over 78% of Chrome traffic on both Chrome OS and Mac is now protected
  • 81 of the top 100 sites on the web use HTTPS by default
Chrome is dedicated to making it as easy as possible to set up HTTPS. Mixed content audits are now available to help developers migrate their sites to HTTPS in the latest Node CLI version of Lighthouse, an automated tool for improving web pages. The new audit in Lighthouse helps developers find which resources a site loads using HTTP, and which of those are ready to be upgraded to HTTPS simply by changing the subresource reference to the HTTPS version.

Lighthouse is an automated developer tool for improving web pages.

Chrome’s new interface will help users understand that all HTTP sites are not secure, and continue to move the web towards a secure HTTPS web by default. HTTPS is easier and cheaper than ever before, and it unlocks both performance improvements and powerful new features that are too sensitive for HTTP. Developers, check out our set-up guides to get started.

Posted by Emily Schechter, Chrome Security Product Manager