[go: up one dir, main page]

Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Android WebView, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 93 is beta as of July 29, 2021.

Origin Trials

This version of Chrome introduces the origin trials described below. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones described below, visit the Chrome Origin Trials dashboard. To learn more about origin trials in Chrome, visit the Origin Trials Guide for Web Developers. Microsoft Edge runs its own origin trials separate from Chrome. To learn more, see the Microsoft Edge Origin Trials Developer Console.

New Origin Trials

Cross-Origin-Embedder-Policy: credentialless

Cross-origin no-CORS requests can now be made to omit credentials (cookies, client certificates, etc.) using the credentialless keyword. Similarly to COEP: require-corp, it can enable cross-origin isolation.

Sites that wish to continue using SharedArrayBuffer must opt-in to cross-origin isolation. Today, COEP: require-corp exists, and is used to enable cross-origin isolation. It is functional and solid, but turns out to be difficult to deploy at scale, as it requires all subresources to explicitly opt-in. This is fine for some sites, but creates dependency problems for sites that gather content from users (Google Earth, social media generally, forums, etc.).

Multi-Screen Window Placement

The Multi-Screen Window Placement API allows you to place windows on any display connected to your machine, store that placement, and make a window full-screen on any display. With this API, a presentation app can show slides on one screen and speaker notes on another. An art or music creation app can place palettes on a second screen. And a restaurant can show a touchscreen menu on a kiosk and a separate window for employees. Incorporating developer feedback from the first origin trial, the API enters a second origin trial with an improved shape and ergonomics.

Window Controls Overlay for Installed Desktop Web Apps

Window controls overlay extends an app's client area to cover the entire window, including the title bar, and the window control buttons (close, maximize/restore, minimize). The web app developer is responsible for drawing and input-handling for the entire window except for the window controls overlay. Developers can use this feature to make their installed desktop web apps look like O.S. apps. For more information, see Customize the window controls overlay of your PWA's title bar.

PWAs as URL Handlers

PWA as URL Handlers allows apps like music.example.com to register themselves as URL handlers for URLs that match patterns like https://music.example.com, https://*.music.example.com, or https://🎵.example.com, so that links from outside of the PWA, for example, from an instant messenger application or an email client, open in the installed PWA rather than in a browser tab.

Completed Origin Trials

The following features, previously in a Chrome origin trial, are now enabled by default.

Subresource loading with Web Bundles

Web Bundles provides a new approach to load a large number of resources efficiently using a format that allows multiple resources to be bundled. This feature addresses issues with previous approaches to resource bundling.

The output of some JavaScript bundlers does not interact well with the HTTP cache and configuring them can sometimes be difficult. Even with bundled JavaScript, execution needs to wait for all bytes to download. Ideally loading multiple subresources should use streaming and parallelization, which is not possible with one JavaScript file. For JavaScript modules, execution still needs to wait for an entire resource tree to download because of deterministic execution.

WebXR Plane Detection API

WebXR applications can now retrieve data about planes present in a user's environment, which enables augmented reality applications to create more immersive experiences. Without this feature, developers would have to resort to running their own computer vision algorithms on data from getUserMedia() (available on navigator and MediaDevices) in order to detect planes present in the users' environment. Such solutions have thus far been unable to match the quality and accuracy of native augmented reality capabilities or support world scale.

Other features in this release

AbortSignal.abort() Static Method

AbortSignal.abort() is a static method that allows creating a new AbortSignal object that is already aborted. It is similar in spirit to Promise.reject(), and provides improved developer ergonomics.

Web developers have found aborted AbortSignal objects to be useful for a variety of purposes. They signify to JavaScript APIs that no work should be done. Currently, creating an already-aborted AbortSignal object requires multiple lines of code. AbortSignal.abort() requires one:

return AbortSignal.abort();

CSS Flexbox: Support Alignment Keywords start, end, self-start, self-end, left, right

The flexbox and flex items now obey positional alignment keywords. Flexbox previously only obeyed center, flex-start, and flex-end. The additional alignment keywords (start, end, self-start, self-end, left, right) allow authors to more easily align the flex items in the face of varying writing modes and flex flows.

Without these additional keywords, developers need to change the keyword values whenever they change the writing mode, text direction, or flex reversal properties (flex-direction: row-reverse, flex-direction:column-reverse or align-content: wrap-reverse). The keywords implemented here let them set alignment once.

Error.cause Property

The Error() constructor supports a new options property called cause, which will be assigned to the error as a property. This allows errors to be chained without unnecessary and overelaborate formalities on wrapping the errors in conditions.

Honor Media HTML Attribute for meta name=theme-color

The meta element's "media" attribute will be honored for meta[name="theme-color"] so that web developers can adjust the theme color of their site based on a media query (dark and light modes for instance). The first one that matches will be picked.

noplaybackrate in HTMLMediaElement.controlsList

The HTMLMediaElement.controlsList property now supports noplaybackrate, which allows websites to enabled or disable the playback speed control exposed by the browser. With browser vendors adding playback speed control to their media controls, developers should have a way to control the visibility of this new control. Try the new property on the noplaybackrate in HTMLMediaElement.controlsList Sample.

Sec-CH-Prefers-Color-Scheme Client Hint Header

The CSS user preference media feature prefers-color-scheme has a potentially significant impact on the amount of CSS that needs to be delivered by a page and on the experience the user is going to have when the page loads. The new Sec-CH-Prefers-Color-Scheme client hint header allows sites to obtain the user's preference optionally at request time, allowing servers to inline the right CSS and therefore avoid a flash of incorrect color theme.

User-Agent Client Hints API Updates

This version of Chrome adds four new features and changes to the User-Agent client hints API.

  • Sec-CH-UA-Bitness: a request header that gives a server information about the bitness of the architecture of the platform on which a given user agent is executing. Bitness is the number of bits comprising the basic value a particular system can evaluate.
  • Make Sec-CH-UA-Platform a low-entropy hint: Sec-CH-UA-Platform is a request header that gives a server information about the platform on which a given user agent is executing.
  • Adds low-entropy hints to UADataValues.getHighEntropyValues(): If a hint moves from high to low-entropy, this future proofs any code relying on it.
  • Improves NavigatorUAData.toJSON() method: This method now returns useful data.

Low-entropy hints are those that don't give away too much information, or give information that would be too easy to discover in other ways to realistically hide. In the context of client hints, this means that these hints are available in every request, whether or not the origin involved requested it or whether the frame involved is a first or third party context.

WebOTP API: Cross-Device Support

The WebOTP API will now be supported on desktop when both Chrome on Desktop and Android Chrome are logged in using the same Google account. The WebOPT API provides the ability to programmatically read a one-time code from specially-formatted SMS messages addressed to their origin, reducing user friction during sign-on. Previously, this was only available on mobile devices where SMS was supported.

JavaScript

This version of Chrome incorporates version 9.3 of the V8 JavaScript engine. It specifically includes the changes listed below. You can find a complete list of recent features in the V8 release notes.

Object.hasOwn

Object.hasOwn, a new boolean property, provides an easier-to-use, static method version of Object.prototype.hasOwnProperty.

Deprecations, and Removals

This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.

Block ports 989 and 990

Connections to HTTP, HTTPS or FTP servers on ports 989 and 990 now fail. These ports are used by the FTPS protocol, which has never been implemented in Chrome. However, FTPS servers can be attacked in a cross-protocol attack by malicious web pages using carefully-crafted HTTPS requests. This is a mitigation for the ALPACA attack.

Remove 3DES in TLS

Chrome has now removed support for the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite. TLS_RSA_WITH_3DES_EDE_CBC_SHA is a remnant of the SSL 2.0 and SSL 3.0 era. 3DES in transport layer security (TLS) is vulnerable to the Sweet32 attack. Being a CBC cipher suite, it is also vulnerable to the Lucky Thirteen attack. The first replacement AES cipher suites were defined for TLS in RFC3268, published around 19 years ago, and there have been several iterations since.

WebAssembly Cross-Origin Module Sharing

WebAssembly module sharing between cross-origin but same-site environments will be deprecated to allow agent clusters to be scoped to origins long term. This follows a WebAssembly specification change, which has an impact on the platform as well.

Labels:




Keeping Chrome users safe as they browse the web is crucially important to Chrome; in fact, security has always been one of our four core principles. In some cases, security can come at the expense of performance. In our next post in The Fast and the Curious series, we are excited to share how improvements to our phishing detection algorithms keeps users safe online. With these improvements, phishing detection is now 50 times faster and drains less battery.

Phishing detectionEvery time you navigate to a new page, Chrome evaluates a collection of signals about the page to see if it matches those of phishing sites. To do that, we compare the color profile of the visited page - that’s the range and frequency of the colors present on the page - with the color profiles of common pages. For example in the image below, we can see that the colors are mostly orange, followed by green and then a touch of purple.





If the site matches a known phishing site, Chrome warns you to protect your personal information and prevent you from exposing your credentials.



What you will see if a phishing attempt is detected

To preserve your privacy, by default Chrome's Safe Browsing mode never sends any images outside the browser. While this is great for privacy, it means that your machine has to do all the work to analyze the image.

Image processing can often generate heavy workloads because analyzing the image requires an evaluation of each pixel in what is commonly known as a “pixel loop.” Some modern monitors display upwards of 14 million pixels, so even simple operations on each of those pixels can add up to a lot of CPU use! For phishing detection, the operation that takes place on each pixel is the counting of its basic colors.

Here is what this looks like. The counts are stored in an associative data structure called a hashmap. For each pixel, we extract its RGB color values and store the counts in one of 3 different hashmaps -- one for each color.





Making it more efficientAdding one item to a hashmap is fast, but we have to do this for millions of pixels. We try to avoid reducing the number of pixels to avoid compromising the quality of the analysis. However, the computation itself can be improved.

Our improvements to the pipeline look like this:
  • The code now avoids keeping track of RGB channels in three different hashmaps and instead uses only one to index by color. Three times less counting!
  • Consecutive pixels are summed before being counted in the hashmap. For a site with a uniform background color, this can reduce the hashmap overhead to almost nothing.
Here is what the counting of the colors looks like now. Notice how there are significantly fewer operations on the hashmap:





How much faster did this get?Starting with M92, Chrome now executes image-based phishing classification up to 50 times faster at the 50th percentile and 2.5 times faster at the 99th percentile. On average, users will get their phishing classification results after 100 milliseconds, instead of 1.8 seconds.

This benefits you in two ways as you use Chrome. First and foremost, using less CPU time to achieve the same work improves general performance. Less CPU time means less battery drain and less time with spinning fans.

Second, getting the results faster means Chrome can warn you earlier. The optimization brought the percentage of requests that took more than 5 seconds to process from 16.25% to less than 1.6%. This speed improvement makes a real difference in security - especially when it comes to stopping you from entering your password in a malicious site!

Overall, these changes achieve a reduction of almost 1.2% of the total CPU time used by all Chrome renderer processes and utility processes.

At Chrome’s scale, even minor algorithm improvements can result in major energy efficiency gains in aggregate. Here’s to many more centuries of CPU time saved!

Stay tuned for many more performance improvements to come!

Posted by Olivier Li Shing Tat-Dupuis, Chrome Developer

Data source for all statistics: Real-world data anonymously aggregated from Chrome clients.



Labels: , ,


When a browser connects to websites over HTTPS (vs. HTTP), eavesdroppers and attackers on the network can't intercept or alter the data that's shared over that connection (including personal info, or even the page itself). This level of privacy and security is vital for the web ecosystem, so Chrome continues to invest in making HTTPS more widely supported.

Thankfully, HTTPS adoption has come a long way in recent years, and most operating systems now see 90%+ of page loads over HTTPS in Chrome. Still, there's more we can do to help make HTTPS the preferred protocol on the web, and better protect users on the remaining slice of the web that doesn’t yet support HTTPS, so today we're sharing some future work in this area.



Opting in to an HTTPS-First World

Beginning in M94, Chrome will offer HTTPS-First Mode, which will attempt to upgrade all page loads to HTTPS and display a full-page warning before loading sites that don’t support it. Users who enable this mode gain confidence that Chrome is connecting them to sites over HTTPS whenever possible, and that they will see a warning before connecting to sites over HTTP. Based on ecosystem feedback, we’ll explore making HTTPS-First mode the default for all users in the future. Mozilla has also shared their intent to make HTTPS-only mode the future of web browsing in Firefox.



Experimenting with the lock icon
As we approach an HTTPS-first future, we're also re-examining the lock icon that browsers typically show when a site loads over HTTPS. In particular, our research indicates that users often associate this icon with a site being trustworthy, when in fact it's only the connection that's secure. In a recent study, we found that only 11% of participants could correctly identify the meaning of the lock icon. To try and reduce this confusion, Chrome will run an experiment in M93 that replaces the lock in the address bar with a more neutral entry point to Page Info (example below). We hope that this experiment will improve the discoverability of critical privacy and security information and controls provided in Page Info, such as site permissions. Importantly, a "Not Secure" indicator will continue to show on sites without HTTPS support, and the experiment includes an enterprise policy in case organizations want to opt-out. In all cases, we'll provide advance notice if we decide to move ahead with a full launch.





Protecting users on the HTTP web
While we are excited to see users adopt HTTPS-First Mode in future versions of Chrome, HTTP connections will still continue to be supported and Chrome will take additional steps to protect and inform users whenever they are using insecure connections. Continuing from our past efforts to restrict new features to secure origins and deprecate powerful features on insecure origins, we’ll evaluate a broad set of web platform features to determine if they should be limited or restricted on HTTP webpages.

In order to focus on changes that provide the greatest security improvements to our users, we are relying on a set of guiding principles to prioritize our future work in this area:

  • Better inform users when making trust decisions about sites over insecure connections
  • Limit the ability for sites to opt out of security policies over insecure connections
  • Restrict how, and for how long, Chrome stores site content provided over insecure connections
A deeper explanation of how we plan to act on these principles, as well as an updated list of affected features will be maintained on the Chromium wiki and we are excited to announce more details later this year.

Posted by Shweta Panditrao, Devon O'Brien, Emily Stark, Google Chrome team


Labels: ,

We previously announced that Chrome will soon release a new milestone every 4 weeks, starting with Chrome 94 in Q3 of 2021. We’re excited to also share our plans today for adjusting the Chrome OS release schedule.

To deliver new features more rapidly to consumers while also continuing to prioritize the key pillars of Chrome OS – security, stability, speed and simplicity – Chrome OS will move to a 4-week stable channel starting with M96 in Q4. For enterprise and education users, Chrome OS will also introduce a new channel with a 6-month update cadence by M96. More details to be announced soon.

To bridge the gap between M94 when Chrome moves to a four week release and M96, Chrome OS will skip M95 (see the updated Chrome schedule page for milestone-specific details).

As we head into our next decade, these changes enable us to evolve Chrome OS to keep helping people get things done and to provide more helpful and secure experiences.


Marina Kazatcker, Chrome OS Release TPM Lead

Labels:

Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 92 is beta as of June 3, 2021

File Handling API

Now that web apps are capable of reading and writing files, the next logical step is to let developers declare web apps as file handlers for files they create and process. The File Handling API allows you to do exactly this. For example, after a text editor PWA has registered itself as a file handler, you can right-click a .txt file in your operating system's file manager and instruct this PWA to (always or just once) open .txt files. This means PWAs are just a (double) click away from the file manager.

The Excalidraw context menu.


This improves the user experience for PWA use cases, making them more like OS apps than they are already. For example:

  • Office applications like text editors, spreadsheet apps, and slideshow creators.
  • Graphics editors and drawing tools.
  • Video game level editor tools.

File Handling is starting an origin trial in 92 that is expected to run until around the end of August, 2021. For more information on this feature, see Let web applications be file handlers. For information about other origin trials in this release, see Origin Trials, below.

Origin Trials

This version of Chrome introduces the origin trials described below. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones described below, visit the Chrome Origin Trials dashboard. To learn more about origin trials in Chrome, visit the Origin Trials Guide for Web Developers. Microsoft Edge runs its own origin trials separate from Chrome. To learn more, see the Microsoft Edge Origin Trials Developer Console.

New Origin Trials

Shared Element Transitions

Shared Element Transitions allows a simple set of transitions in both single-page applications (SPAs) and multi-page applications (MPAs). This enhances the visual polish of pages with minimal effort by letting developers select from a set of user-agent provided transition effects. Without this, single-page app transitions are difficult since they require a careful coordination of animations and DOM manipulations to achieve the desired effect. Multi-page app transitions are, for the most part, not possible since each page can only control the contents of its own view. This origin trial is only for SPA use cases.

Other features in this release

Change in Allowed App Shortcuts

Most Android launchers now allow only three app shortcuts instead of the previously allowed four. A shortcut to the site settings was added to the application icon in the Android launcher, taking one of the available shortcut slots for the app. For more information, see Get things done quickly with app shortcuts.

CSS

size-adjust Descriptor for @font-face

Adds the size-adjust descriptor for @font-face allowing scaling of glyph sizes for a particular font face without affecting the CSS font-size and derived metrics such as em. CSS font-size can be seen as a scale factor for a box that the font draws in. Glyph sizes within that box vary between fonts, and size-adjust enables harmonising them across different fonts. That's why it reduces cumulative layout shift by matching up the fallback font and primary web font using this descriptor.

Imperative Slot Distribution Behavior

Imperative slotting allows node-to-slot assignments without needing the slot attribute in markup. This enables dynamic slotting behavior based on input conditions and types. The feature originally shipped in Chrome 86; in this release some adjustments to the API have been made to ensure interoperability with other browsers.

JavaScript

This version of Chrome incorporates version 9.2 of the V8 JavaScript engine. It specifically includes the changes listed below. You can find a complete list of recent features in the V8 release notes.

Add dayPeriod option for Intl.DateTimeFormat

A dayPeriod option (part of ECMA402 2021) has been added to the Intl.DateTimeFormat() method so the caller can format times such as "7 in the morning", "11 in the morning", "12 noon", "1 in the afternoon", "6 in the evening", "10 at night" (or in Chinese, "清晨7時", "上午11時", "中午12時", "下午1時" ,"下午6時" ,"晚上10時").

This enhances Intl.DateTimeFormat() to match what is already possible in C++ and Java by calling ICU and ICU4J. Without this feature, developers need to either format the quarter in the server or ship a set of day period patterns and hour to day period mappings from the server to client to perform such tasks.

Relative Indexing Method for Array, String, and TypedArrays

Adds a new method named at(), to Array.prototype, String.prototype, and the TypedArray prototypes, that permit relative indexing with negative indices. For example:

let arr = [1,2,3,4];
arr.at(-1); // Returns 4

Intl BestFitMatcher by Using ICU LocaleMatcher

The ICU LocaleMatcher now implements the BestFitMatcher abstract operation to better match locale data.

SharedArrayBuffers on Desktop Platforms Restricted to Cross-Origin Isolated Environments

SharedArrayBuffers on desktop platforms are now restricted to cross-origin isolated environments, matching the behavior recently shipped on Android and Firefox. A Cross-origin isolated page is considered a secure environment because it blocks loading cross-origin resources that are not opt-in and communicating with cross-origin windows. Only pages that opt-in to cross-origin isolation will be able to use SharedArrayBuffers. Learn more about the upcoming options at SharedArrayBuffer updates in Android Chrome 88 and Desktop Chrome 92.

Media Session API: Video conferencing actions

Adds actions to the Media Session API, specifically "togglemicrophone", "togglecamera", and "hangup". This enables developers of video conferencing websites to handle these actions from the browser interface. For example, if the user puts their video call into a picture-in-picture window, the browser could display buttons for mute/unmute, turn-on/turn-off camera, and hanging up. When the user clicks these, the website handles them through the Media Session API. For more information, see the section from our recent article, or try our demo.

Tainted Origin Flag applied to Resource Timing

Chrome now accounts for the tainted origin flag when computing whether a fetched resource passes the timing allow origin check. The timing allow origin check is used in resource timing to determine whether the page can receive detailed timing information about a resource used in the page. The tainted origin flag impacts this check in cases where there are multiple redirects that cross origins. In those cases, the header should be '*'. In other words, it can no longer be a specific origin.

If a resource performs two cross-origin crosses (via redirects), then the developer needs to use Timing-Allow-Origin: * for the checks to pass. For example if a page on origin A fetches a resource on origin B, which redirects to a resource on origin C, then the tainted origin flag is set and the final resource needs to have Timing-Allow-Origin: * in order to receive detailed timing information."

URL Protocol Handler Registration for PWAs

Web applications can now register themselves as handlers of custom URL protocols or schemes using their web app manifests. Operating system applications often register themselves as protocol handlers to increase discoverability and usage. Websites can already register to handle schemes via registerProtocolHandler(), it is desirable to have web apps be first-class citizens and be launched directly when a custom-scheme link is invoked. 

Web Bluetooth Manufacturer Data Filter

The Web Bluetooth API can now filter based on manufacturer data such as vendor ID and product ID. Developers have been able to prompt users through a browser picker to select a nearby Bluetooth device that matches their advertised name and services. However it hasn't been possible to filter nearby Bluetooth devices based on advertised manufacturer specific data. Manufacturer data is specified through new properties on options.filters, which is passed to Bluetooth.requestDevice(). For more information, see Communicating with Bluetooth devices over JavaScript or try our demo.

Deprecations and Removals

This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.

Payment Handlers for Standardized Payment Method Identifiers

This feature, which enabled web-based payment handlers to receive paymentrequest events with non-URL, but standardized payment method identifiers, such as "basic-card" or "tokenized-card", has been removed.

Labels:

Since the launch of Chrome in 2008, speed has been one of the 4 core principles that shape the work we do to deliver a highly performant browser. The V8 JavaScript compiler is a critical part of delivering maximum speed for the JavaScript that’s shipped on practically every web page. In our next post in The Fast and the Curious series, we are excited to share how improvements to the V8 engine are delivering up to 23% faster performance.


An important component of delivering a fast browser is fast JavaScript execution. In Chrome, that job is done by the V8 engine which executes over 78 years worth of JavaScript code on a daily basis. In M91 Chrome is now up to 23% faster with the launch of a new Sparkplug compiler and short builtin calls, saving over 17 years of our users' CPU time each day! Sparkplug is a new JavaScript compiler that fills the gap between needing to start executing quickly and optimizing the code for maximum performance. Short builtin calls optimize where in memory we put generated code to avoid indirect jumps when calling functions.



SparkplugThe V8 engine has multiple compilers which can make different tradeoffs throughout the various phases of executing JavaScript. Three years ago, we launched a new two-tier compiler system consisting of Ignition and Turbofan. Ignition is a bytecode interpreter whose job is to start executing the JavaScript with as little delay as possible. Turbofan is the optimizing compiler that generates high-performance machine code based on information gathered during JavaScript execution; as a result, it starts up more slowly than Ignition’s bytecode compiler. Sparkplug strikes a balance between Ignition and Turbofan in that it does generate native machine code but does not depend on information gathered while executing the JavaScript code. This lets it start executing quickly while still generating relatively fast code. For a complete technical deep dive into what it took to make this new engine, please see our V8 blog post.






Short builtins Short builtins is a mechanism by which the V8 engine optimizes the location in memory of generated code. When V8 generates CPU-specific code from JavaScript, it lays that code out in memory. This generated code will frequently call builtin functions, which are small snippets of code for handling common routines --everything from basic operations like adding two variables, to full-fledged functions in the JavaScript standard library. For some CPUs, calling functions that are further away from your generated code can cause CPU-internal optimizations (such as branch prediction logic) to fail. The fix for this is to copy the builtin functions into the same memory region as the generated code. This change is especially impactful for the new Apple M1 chip. Please see our V8 blog post to learn more about the impact across platforms of this feature.

Stay turned for many more performance improvements to come!

Posted by Thomas Nattestad, Chrome Product Manager


Data source for all statistics: Speedometer 2.0.
Labels: ,

Today, people have many ways to keep up with their favorite websites, including subscribing to mailing lists, notifications and RSS. It’s a lot for any one person to manage, so we’re exploring how to simplify the experience of getting the latest and greatest from your favorite sites directly in Chrome, building on the open RSS web standard. Our vision is to help people build a direct connection with their favorite publishers and creators on the web.

In the coming weeks, some Android users in the US on Chrome Canary may see an experimental Follow feature designed to help people get the latest content from sites they follow. Our goal for this feature is to allow people to follow the websites they care about, from the large publishers to the small neighborhood blogs, by tapping a Follow button in Chrome. When websites publish content, users can see updates from sites they have followed in a new Following section on the New Tab page:




Keeping a site’s RSS up-to-date will ensure Chrome can provide the latest content to users with this experiment. We will provide more guidance to web publishers as we learn and evaluate whether this feature will graduate from an experiment to a broader rollout in Chrome.

We welcome feedback from publishers, bloggers, creators, and citizens of the open web (like you!) on this experiment as we aim to build deeper engagement between users and web publishers in Chrome. You can also stay up-to-date and ask us questions via @GoogleCreators on Twitter or via email to webcreators@google.com. As part of this year’s Google I/O, we’ll be hosting a Meet Up for web publishers, creators and developers who would like to learn more, ask questions and share feedback. You can sign up for I/O (free this year) and register for the Following on the Open Web session, being held on May 19 (today) at 11 AM PT.

Posted by Janice Wong, Product Manager, Google Chrome
Labels: