[go: nahoru, domu]

While most advertising on the web is respectful of user experience, over the years we've increasingly heard from our users that some advertising can be particularly intrusive. As we announced last June, Chrome will tackle this issue by removing ads from sites that do not follow the Better Ads Standards. We've previously discussed some of the details surrounding how Chrome protects users from intrusive ads, but as we approach the launch date of February 15, we wanted to go under the hood and discuss how this feature works in more detail.

 What are the Better Ads Standards?
The Better Ads Standards are the result of public consumer research by the Coalition for Better Ads, an industry group focused on improving users' experience with online advertising. Over 40,000 internet users in North America and Europe participated in surveys where they were shown common ad experiences and asked to evaluate how intrusive the experiences were. The most intrusive ad experiences include prestitial ads (those full-page ads that block you from seeing the content on the page) and flashing animated ads. More details about the research and methodology can be found on the Coalition's website.

Although a few of the ad experiences that violate the Better Ads Standards are problems in the advertisement itself, the majority of problematic ad experiences are controlled by the site owner — such as high ad density or prestitial ads with countdown. This result led to the approach Chrome takes to protect users from many of the intrusive ad experiences identified by the Better Ads Standards: evaluate how well sites comply with the Better Ads Standards, inform sites of any issues encountered, provide the opportunity for sites to address identified issues, and remove ads from sites that continue to maintain a problematic ads experience.

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

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.

CSS Paint API
The CSS Paint API, also known as “CSS Custom Paint”, allows developers to programmatically generate an image whenever a CSS property expects one. Instead of referencing an image resource, developers can now use the new paint() function to reference a paint worklet that will draw the image. This API can be used for many things, including making the DOM tree smaller and transferring significantly less data compared to an image.

<style>
  textarea {
    background-image: paint(checkerboard);
  }
</style>
<textarea></textarea>
<script>
  CSS.paintWorklet.addModule('checkerboard.js');
</script>

To see the paint worklet in action, check out our explainer and the video demo below.


In this example, the CSS Paint API is used to programmatically create a checkerboard image.
Server Timing API
Developers interested in measuring the performance of their web applications have been able to use the Navigation Timing and Resource Timing APIs to request timing data for the document and its resources. Until now, there has been no way for the server to send any details about its response time to the client. The new Server Timing API allows web servers to pass performance timing information via HTTP headers to browsers. This new API provides developers a more complete performance picture that includes the speed of both the client and the server. For example, Chrome Developer Tools now shows server timing performance information via the Server Timing API.

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:

For the past several years, we’ve moved toward a more secure web by strongly advocating that sites adopt HTTPS encryption. And within the last year, we’ve also helped users understand that HTTP sites are not secure by gradually marking a larger subset of HTTP pages as “not secure”. Beginning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as “not secure”.


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