Google Chrome calculates your autoplay settings so you don't have to - others disagree

We'll just let muted videos autoplay on Chrome for Android because publishers can't be stopped

Google's rules for when its Chrome browser allows and blocks the automatic playback of web audio and video have come under fire following a company developer's decision not to address objections to the removal of autoplay blocking controls from Chrome for Android.

Earlier this year, a user of the mobile version of Chrome on Android complained on the Google support forum that videos started playing upon visiting a web page and there appeared to be no way to prevent this.

Other forum participants chimed in, noting that the controls for preventing videos from autoplaying had disappeared. It's a concern that has been raised before.

The issue applies specifically to muted videos since unmuted videos aren't supposed to autoplay, even if they do sometimes. It was raised in March as a bug in the Chromium bug tracking system.

For Chrome users, enabling or disabling autoplay for audio and video is a matter of personal preference, bandwidth usage, bandwidth cost, and accessibility, among other considerations. That decision also has implications for web publishers and those operating web kiosks where interaction requirements before videos play may not be possible. And Google's approach has been to try to tailor Chrome for both those viewing websites and those making them, rather than picking a side.

In April, Google developer Mounir Lamouri marked the bug "Won't Fix," indicating that the ad biz doesn't intend to change its browser's behavior.

The reason, Lamouri explained, is that the response from some web publishers just makes things worse.

"Unfortunately, full autoplay blocking is counter productive as images and <canvas> can do 'video' playback just fine," Lamouri wrote. "We had this issue on mobile and ended up enabling muted autoplay there to avoid that issue. We found many websites having 100MB gifs that could be one order of magnitude smaller when implemented as <video autoplay muted>."

In other words, faced with a user's decision to prevent videos from playing automatically, web publishers would deploy bulky .gif animations that play using the browser Canvas API, a choice that would consume even more bandwidth than automatically played videos.

According to Lamouri, there's still a command line flag to disable autoplay fully – both for audio and video: "--autoplay-policy=user-gesture-required". But it's likely to be removed at some point, he said.

When this issue surfaced in a Hacker News discussion over the weekend, it prompted objections from forum participants that Chrome fails to give users control of their browser. Several of those discussing the issue pointed to other browsers like Apple Safari and Mozilla Firefox that provide more extensive media playback options.

But in the context of autoplay, Google has tried to serve both users and publishers since at least 2016, when Chrome 53 debuted and brought with it a change: Instead of disabling video autoplay, the update would allow it to play, but without sound.

"Autoplay was disabled in previous versions of Chrome on Android because it can be disruptive, data-hungry and many users don't like it," Google developer advocate Sam Dutton explained at the time. "Disabling autoplay had the unintended effect of driving developers to alternatives such as animated GIFs, as well as <canvas> and <img alt=""> hacks. These techniques are much worse than optimized video in terms of power consumption, performance, bandwidth requirements, data cost and memory usage."

In 2017, Google announced changes in its autoplay policy, describing the revised rules, affecting both audio and video, as simple. The ad biz's post continues by explaining the rather complicated Media Engagement Index (MEI) threshold used in desktop Chrome to determine when audio will automatically play.

The Chocolate Factory delayed its changes in November, 2018, after objections from those developing web audio applications. In that post, Lamouri and two other Google developers, Tom Greenaway and Hongchan Choi, explained that browsers haven't done a good job helping users manage sound.

"Unwanted noise is the primary reason that users do not want their browser to autoplay content," they wrote. "However, sometimes users want content to autoplay, and a meaningful number of blocked autoplays in Chrome are subsequently played by the user."

Yet rather than letting users choose – and risk upsetting publishers with that choice – Google's coders chose for them by calculating the appropriate autoplay setting via its MEI system. Per the company's Autoplay Policy Design Rationale document, the declared goal is: "For 99 per cent of users, Chrome will be 95 per cent accurate at predicting when a user wants an audible playback before a user gesture on a page."

Chrome's autoplay policy, implemented with Chrome 71, is as follows:

• The content is muted, or does not include any audio (video only)
• The user tapped or clicked somewhere on the site during the browsing session
• On mobile, if the site has been added to the Home Screen by the user
• On desktop, if the user has frequently played media on the site, according to the Media Engagement Index

This policy brought the removal of the block autoplay setting in Chrome for Android and the removal of autoplay blocking on mobile when data saver mode is enabled.

Not everyone is convinced that this is the right approach. On Tuesday, a developer with NOA Labs submitted a Chromium bug report asking the Chromium team to revisit the "Won't Fix" bug. ®