9 ms·

Chrome updated to temporarily remove the autoplay policy for the Web Audio API

99 points by bjornstar 8y ago

dannyw 8y ago
Chrome needs to ditch this whitelisted exception for 'the top 1000 sites'. This is a barrier to every new video platform that wants to compete with YouTube or Facebook.
- pietroglyph 8y ago
  It appears to be a little more complex than that; this[0] blog post (from September 2017, but linked in as the official recommendation) provides some broader context, and also talks about a "Media Engagement Index" heuristic to determine whether or not to play audio. This doesn't appear to take something like Alexa rank into account. The requested behavior is very similar to the actual (recalled) behavior. Per [0], Chrome allows muted (by JS) videos to play, and then allows audio to play on first interaction (but must be done by JS.) This is subtly different from the proposed behavior, which asks for this unmuting to be automated by the browser. [0]: https://developers.google.com/web/updates/2017/09/autoplay-policy-changes https://developers.google.com/web/updates/2017/09/autoplay-p...
  - dannyw 8y ago
    It’s more complex, but only the top 1000 sites by MEI is still a hurdle. In addition, the non-whitelist path requires at least 20 interactions before it is considered. That’s ridiculous; it should be 3-5 max.
    - sp332 8y ago
      It's not only the top 1,000. It was over 1,000 when it first launched and they said they will expand the list over time.
      - tokyodude 8y ago
        That's really irrelevant. Your youtube competitor may never get in that list if users don't get autoplay on your site. Sure you can train your browser. Until you switch machines. Or use a public machine. Or use a different profile. Or use incognito mode. They're providing a fast lane for the current popular sites and everyone else gets a slow lane. It's kind of hard to get out of the slow lane when you're forced to go slow.
- niftich 8y ago
  Of course, the top 1000 sites is exactly where I don't want anything to autoplay, because half of these sites have spurious videos instead of the textual content that you'd reasonably expect, just to pump ad engagement metrics. It'd be nice to have a whitelist/blacklist import/export, so there can be multiple community-sourced efforts to classify sites into reasonable use of autoplay vs. unreasonable. One can dream.
  - jarfil 8y ago
    Many ad-blockers do just that. Of course they also go a step further and block ads altogether, so blocking autoplay becomes unnecessary since there is only "true content" left to be autoplayed.
tananaev 8y ago
What is the easiest/best way to completely disable any auto-play for videos until I click on them? When I want to watch a video I'm happy to click on it to watch.
- dvh 8y ago
  Write your own browser
  - FreeFull 8y ago
    Firefox has a setting for disabling autoplay, even for gifs
- PastaMonster 8y ago
  If there are sites you often visit you can see if there exist a userscript for those sites that may have that feature. You can also block videos completely with an adblocker.
- moreati 8y ago
  I use https://chrome.google.com/webstore/detail/disable-html5-autoplay/efdhoaajjjgckpbkoglidkeendpkolai https://chrome.google.com/webstore/detail/disable-html5-auto.... It mostly works - a few videos fail to play when I click, and a very few others manage to autoplay.
donatj 8y ago
I think sites should simply have to ask for audio permissions like they already do for camera, location or microphone. The browser trying to figure out if I intended to play audio is way too error prone versus me just asking. I work on an audiobook player as a developer have been fighting this junk on iOS for years, it’s nothing but trouble. If I could just secure a permission to play audio worry free it’d make my life so much easier. Right now we need to ensure that all our audio is triggered by a click event, and if it gets too many steps away from the click event itself, everything breaks. It’s literally defined and limited how we can abstract our code.
- MrMember 8y ago
  More granular permissions would be great. I would love to have a whitelist for audio, video, any sort of animation, etc.
  - pietroglyph 8y ago
    This seems to be the right way to go... Chrome's current approach[0] is all heuristic and no user input. I think a quick "Allow" with an optional "Remember Me" would be both easier to implement and less confusing than what they have (also not a huge pain for web developers.) [0]: https://developers.google.com/web/updates/2017/09/autoplay-policy-changes https://developers.google.com/web/updates/2017/09/autoplay-p...
    - digi_owl 8y ago
      Google's ongoing approach is to remove the human from the loop. And more and more human facing projects seems to follow suit.
  - bsimpson 8y ago
    "Any sort of animation"? =( That would make most good UIs unusable. UI animation and audio aren't remotely the same category of interruption.
    - 8y ago
flukus 8y ago
Why listen to developers? They (and their bosses) created such a hostile environment for users in the first place, if they'd done the right thing then this wouldn't need to be baked into the browser at all. Listen to users, they need protection from developers.
- wwweston 8y ago
  Developers make the things users use -- there aren't users without developers. Developer interests therefore often overlap with user interest, even if they don't always. Where they're in tension, the particulars of the solution matter. Users aren't winning if their web audio apps inexplicably stop playing sound in a new version, if Chrome's decision makers decide to muck around with a standard in such a way that devs acting in perfectly good faith find their Web Audio API stuff breaking/working from release to release, and those devs either have to burn time adapting to the hoops du jour particular to each browser or simply give up trying to hit a moving/multiplying target. As others have pointed out, there are simpler ways to offer users consideration for opt-in audio.
- sp332 8y ago
  Cross-posting my comment from Ars Technica: So here's how weird and user-unfriendly this is. If you link straight to a page, it will be muted. [Autoplaying sound - unless you're in Chrome 66] http://dryad.technology/gametitle http://dryad.technology/gametitle But! If you go to http://dryad.technology http://dryad.technology first and then click "Game Title", it plays sound. If you control-click it to open it in a new tab, it also plays sound. But if you drag the link "Game Title" to the tab bar to open a new tab, it doesn't. This honestly doesn't look like a fully-baked feature.
- ksk 8y ago
  Why not just stop visiting sites that don't align with your views? Reward sites that respect your views and interests... 1. "Users want to view my website but Chrome is getting in the way.." 2. "Users don't seem to want to visit my website. Perhaps I'm doing something wrong..."
plasma 8y ago
It's pretty ridiculous that Chrome has a whitelist. This should be enough of a red flag something isn't right.
- setquk 8y ago
  Yes this worries me. Especially with the market share. Surely a large web gatekeeper like Chrome would be in violation of anti trust regulation?
  - jrockway 8y ago
    What's your legal theory behind an antitrust violation? If it were the case, why wouldn't we have already been down this road with SSL certificates? If I want to open the jrockway CA with a policy of "I will literally sign any CSR with no verification", I can't, because no major browser vendor will add me to their certificate whitelists. That's not an antitrust violation.
    - setquk 8y ago
      The legal basis is that google operate the largest video delivery site. If they fail to whitelist smaller organisations then they are operating anti competitively. The CA situation is a different model. To be honest the whole trustworthy CA thing is a joke as we’ve found out recently. The model is broken. Look at Symantec.
  - retox 8y ago
    People are getting e-irate at so called "net neutrality" but don't care when corps force their opinions and business decisions on users, or even block them entirely from working with their competitors. (See goog blocking YouTube on Amazon devices, Netflix refusing to offer the streams non-blessed browsers, etc).
- kodablah 8y ago
  How about blacklists like safe browsing lists or lists of pages to enable ad blocking on?
dmitriid 8y ago
Somehow no one comments that Chrome team rolled this out in the first place, and only then went and started asking for examples of broken sites. Even though their own websited like ”Chrome Experiments” are broken by it. Even though it would take QA a total of few hours to come up with dozens of broken sites.
- cpeterso 8y ago
  These WebAudio autoplay problems were reported to Google last year: https://twitter.com/mcclure111/status/993517176798638080 https://twitter.com/mcclure111/status/993517176798638080 https://bugs.chromium.org/p/chromium/issues/detail?id=765667 https://bugs.chromium.org/p/chromium/issues/detail?id=765667
- sp332 8y ago
  Whole platforms are now broken: Unity, Pico-8, shadertoy, howler.js, phazer.js, pixi.js, kiwi.js, melonjs.... And yeah they broke a feature on the main Google.com page. If you click https://www.google.com/search?q=5+second+timer https://www.google.com/search?q=5+second+timer it will normally beep when the timer goes off.
lioeters 8y ago
Whew, that's a relief - until October when the same policy will be applied in Chromium 70? As many are pointing out in the issue thread, I hope they figure out a solution that doesn't break countless existing sites, apps and experiments (including their own, such as https://musiclab.chromeexperiments.com https://musiclab.chromeexperiments.com) using the Web Audio API. I'm also not happy about the whitelist, and suspicious of the new Media Engagement Index.
fenomas 8y ago
This was a really awful change. Not only did it break lots of existing sites, it broke lots of sites that weren't even trying to autoplay. Basically the new policy triggered based on how you set up your AudioContext, regardless of whether you played any sounds. Most sites doing anything interesting with WebAudio just set up their context at init time (until now there was no reason not to), so as a result almost every WebAudio demo out there got broken. I was looking through back issues of Web Audio Weekly and in Chrome it was a wasteland - nothing worked, autoplay or not. I know the Chrome team works hard, but sometimes it's hard to believe that they feel the responsibility of stewardship they have over the web. Breaking existing content with no benefit to user experience should be considered a showstopper bug, not something you just delay until "after developers have time to update their code".
- xfitm3 8y ago
  I live a quiet life and want my browser to be quiet too. I don’t fully understand the API changes behind this decision but from what I have read this is a huge win. The real problem is the unethical use of APIs to increase advertisement related KPIs.
  - sp332 8y ago
    Not that many people are really advocating for autoplay. They just want a way to enable audio on specific sites. The Chrome changes take control away from the user.
  - fenomas 8y ago
    You're saying you like the intent of the policy - that's fair enough. I'm saying that the implementation didn't match the intent - Chrome broke WebAudio sites regardless of whether they followed the intended policy. That's not a big win for anyone, it just breaks content to no benefit.
  - ksk 8y ago
    The simplest solution is to not visit sites that don't respect your point of view. Reward sites who align with your interests and views.
mattdesl 8y ago
This is terrible. Chrome responded to a major breaking change by simply... delaying it? The exact same problems will be faced come October.
jimrandomh 8y ago
Currently they're saying: > The policy will be re-applied to the Web Audio API in Chrome 70 (October). Developers should update their code based on the recommendations at: https://developers.google.com/web/updates/2017/09/autoplay-policy-changes#webaudio https://developers.google.com/web/updates/2017/09/autoplay-p... This is wrong and really needs to be reconsidered. Nearly all of the examples of broken webpages on that thread are write-and-forget games, which will never be updated; this plan would break them permanently, just to save a little engineering effort in Chrome. The solution is simple: display a permissions request, like there currently is for camera, location and microphone. That's how it should've worked in the first place.
- Ajedi32 8y ago
  A permissions request isn't a good solution. Instead of having to deal with auto-playing video on every other site you visit, you'd now have to deal with a permissions prompt constantly popping up. IMO the best solution is to just mute the autoplaying media until the user interacts with the page. Completely transparent to sites, and doesn't burden the user with unnecessary pop-ups.
  - anonymfus 8y ago
    Permission request is not necessary a pop-up prompt. It can be implemented as an additional state of the sound playing icon in the tab's title for example, and I am sure that good designers can invent something better.
    - unilynx 8y ago
      They already show an inline notification on the address bar when a page is trying to open a popup. They could've done the same for audio
  - wyldfire 8y ago
    > IMO the best solution is to just mute the autoplaying media until the user interacts with the page This seems like a good compromise but doesn't sound like enough on its own. Sometimes I just open pages and look at the resulting video and it would be puzzling for it to be muted. Or does "interacts with" include merely viewing the tab? Even though it's religion for me, lots of people never or rarely ever "open in new tab". So this design change would eliminate the benefit.
tokyodude 8y ago
I actually agree with the motivations if not the outcome. Here's a maybe dumb suggestion. Make make a new API. Sites using the old API will get a blocking dialog. Sites using the new API will get the desired behavior. That way old content is still accessible. Maybe `new AudioContext2()` or `new AudioContext({version: 2})` or `new AudioContext({optIntoNewBehavior: true})` where old behavior pops up a modal dialog? Just throwing out ideas.
- mattdesl 8y ago
  I may be misunderstanding your comment, but what exactly is the benefit? Advertising websites can just switch to the new API to achieve autoplay audio, meanwhile all old sites will have a poor user experience as they will require additional browser UI and popups to use.
  - tokyodude 8y ago
    The new API doesn't autoplay. The old API did. Changing the old API is what's breaking everything. So, if the old API blocks the page that page is still accessible. Click "Ok" and it's unblocked. If the page is using the new API then it doesn't get blocked but it also doesn't autoplay

99 points by bjornstar 8y ago

Chrome needs to ditch this whitelisted exception for 'the top 1000 sites'. This is a barrier to every new video platform that wants to compete with YouTube or Facebook.

pietroglyph 8y ago
It appears to be a little more complex than that; this[0] blog post (from September 2017, but linked in as the official recommendation) provides some broader context, and also talks about a "Media Engagement Index" heuristic to determine whether or not to play audio. This doesn't appear to take something like Alexa rank into account. The requested behavior is very similar to the actual (recalled) behavior. Per [0], Chrome allows muted (by JS) videos to play, and then allows audio to play on first interaction (but must be done by JS.) This is subtly different from the proposed behavior, which asks for this unmuting to be automated by the browser. [0]: https://developers.google.com/web/updates/2017/09/autoplay-policy-changes https://developers.google.com/web/updates/2017/09/autoplay-p...
- dannyw 8y ago
  It’s more complex, but only the top 1000 sites by MEI is still a hurdle. In addition, the non-whitelist path requires at least 20 interactions before it is considered. That’s ridiculous; it should be 3-5 max.
  - sp332 8y ago
    It's not only the top 1,000. It was over 1,000 when it first launched and they said they will expand the list over time.
    - tokyodude 8y ago
      That's really irrelevant. Your youtube competitor may never get in that list if users don't get autoplay on your site. Sure you can train your browser. Until you switch machines. Or use a public machine. Or use a different profile. Or use incognito mode. They're providing a fast lane for the current popular sites and everyone else gets a slow lane. It's kind of hard to get out of the slow lane when you're forced to go slow.
niftich 8y ago
Of course, the top 1000 sites is exactly where I don't want anything to autoplay, because half of these sites have spurious videos instead of the textual content that you'd reasonably expect, just to pump ad engagement metrics. It'd be nice to have a whitelist/blacklist import/export, so there can be multiple community-sourced efforts to classify sites into reasonable use of autoplay vs. unreasonable. One can dream.
- jarfil 8y ago
  Many ad-blockers do just that. Of course they also go a step further and block ads altogether, so blocking autoplay becomes unnecessary since there is only "true content" left to be autoplayed.

tananaev 8y ago

What is the easiest/best way to completely disable any auto-play for videos until I click on them? When I want to watch a video I'm happy to click on it to watch.

dvh 8y ago
Write your own browser
- FreeFull 8y ago
  Firefox has a setting for disabling autoplay, even for gifs
PastaMonster 8y ago
If there are sites you often visit you can see if there exist a userscript for those sites that may have that feature. You can also block videos completely with an adblocker.
moreati 8y ago
I use https://chrome.google.com/webstore/detail/disable-html5-autoplay/efdhoaajjjgckpbkoglidkeendpkolai https://chrome.google.com/webstore/detail/disable-html5-auto.... It mostly works - a few videos fail to play when I click, and a very few others manage to autoplay.

donatj 8y ago

I think sites should simply have to ask for audio permissions like they already do for camera, location or microphone. The browser trying to figure out if I intended to play audio is way too error prone versus me just asking. I work on an audiobook player as a developer have been fighting this junk on iOS for years, it’s nothing but trouble. If I could just secure a permission to play audio worry free it’d make my life so much easier. Right now we need to ensure that all our audio is triggered by a click event, and if it gets too many steps away from the click event itself, everything breaks. It’s literally defined and limited how we can abstract our code.

MrMember 8y ago
More granular permissions would be great. I would love to have a whitelist for audio, video, any sort of animation, etc.
- pietroglyph 8y ago
  This seems to be the right way to go... Chrome's current approach[0] is all heuristic and no user input. I think a quick "Allow" with an optional "Remember Me" would be both easier to implement and less confusing than what they have (also not a huge pain for web developers.) [0]: https://developers.google.com/web/updates/2017/09/autoplay-policy-changes https://developers.google.com/web/updates/2017/09/autoplay-p...
  - digi_owl 8y ago
    Google's ongoing approach is to remove the human from the loop. And more and more human facing projects seems to follow suit.
- bsimpson 8y ago
  "Any sort of animation"? =( That would make most good UIs unusable. UI animation and audio aren't remotely the same category of interruption.
  - 8y ago

flukus 8y ago

Why listen to developers? They (and their bosses) created such a hostile environment for users in the first place, if they'd done the right thing then this wouldn't need to be baked into the browser at all. Listen to users, they need protection from developers.

wwweston 8y ago
Developers make the things users use -- there aren't users without developers. Developer interests therefore often overlap with user interest, even if they don't always. Where they're in tension, the particulars of the solution matter. Users aren't winning if their web audio apps inexplicably stop playing sound in a new version, if Chrome's decision makers decide to muck around with a standard in such a way that devs acting in perfectly good faith find their Web Audio API stuff breaking/working from release to release, and those devs either have to burn time adapting to the hoops du jour particular to each browser or simply give up trying to hit a moving/multiplying target. As others have pointed out, there are simpler ways to offer users consideration for opt-in audio.
sp332 8y ago
Cross-posting my comment from Ars Technica: So here's how weird and user-unfriendly this is. If you link straight to a page, it will be muted. [Autoplaying sound - unless you're in Chrome 66] http://dryad.technology/gametitle http://dryad.technology/gametitle But! If you go to http://dryad.technology http://dryad.technology first and then click "Game Title", it plays sound. If you control-click it to open it in a new tab, it also plays sound. But if you drag the link "Game Title" to the tab bar to open a new tab, it doesn't. This honestly doesn't look like a fully-baked feature.
ksk 8y ago
Why not just stop visiting sites that don't align with your views? Reward sites that respect your views and interests... 1. "Users want to view my website but Chrome is getting in the way.." 2. "Users don't seem to want to visit my website. Perhaps I'm doing something wrong..."

plasma 8y ago

It's pretty ridiculous that Chrome has a whitelist. This should be enough of a red flag something isn't right.

setquk 8y ago
Yes this worries me. Especially with the market share. Surely a large web gatekeeper like Chrome would be in violation of anti trust regulation?
- jrockway 8y ago
  What's your legal theory behind an antitrust violation? If it were the case, why wouldn't we have already been down this road with SSL certificates? If I want to open the jrockway CA with a policy of "I will literally sign any CSR with no verification", I can't, because no major browser vendor will add me to their certificate whitelists. That's not an antitrust violation.
  - setquk 8y ago
    The legal basis is that google operate the largest video delivery site. If they fail to whitelist smaller organisations then they are operating anti competitively. The CA situation is a different model. To be honest the whole trustworthy CA thing is a joke as we’ve found out recently. The model is broken. Look at Symantec.
- retox 8y ago
  People are getting e-irate at so called "net neutrality" but don't care when corps force their opinions and business decisions on users, or even block them entirely from working with their competitors. (See goog blocking YouTube on Amazon devices, Netflix refusing to offer the streams non-blessed browsers, etc).
kodablah 8y ago
How about blacklists like safe browsing lists or lists of pages to enable ad blocking on?

dmitriid 8y ago

Somehow no one comments that Chrome team rolled this out in the first place, and only then went and started asking for examples of broken sites. Even though their own websited like ”Chrome Experiments” are broken by it. Even though it would take QA a total of few hours to come up with dozens of broken sites.

cpeterso 8y ago
These WebAudio autoplay problems were reported to Google last year: https://twitter.com/mcclure111/status/993517176798638080 https://twitter.com/mcclure111/status/993517176798638080 https://bugs.chromium.org/p/chromium/issues/detail?id=765667 https://bugs.chromium.org/p/chromium/issues/detail?id=765667
sp332 8y ago
Whole platforms are now broken: Unity, Pico-8, shadertoy, howler.js, phazer.js, pixi.js, kiwi.js, melonjs.... And yeah they broke a feature on the main Google.com page. If you click https://www.google.com/search?q=5+second+timer https://www.google.com/search?q=5+second+timer it will normally beep when the timer goes off.

lioeters 8y ago

Whew, that's a relief - until October when the same policy will be applied in Chromium 70? As many are pointing out in the issue thread, I hope they figure out a solution that doesn't break countless existing sites, apps and experiments (including their own, such as https://musiclab.chromeexperiments.com https://musiclab.chromeexperiments.com) using the Web Audio API. I'm also not happy about the whitelist, and suspicious of the new Media Engagement Index.

fenomas 8y ago

This was a really awful change. Not only did it break lots of existing sites, it broke lots of sites that weren't even trying to autoplay. Basically the new policy triggered based on how you set up your AudioContext, regardless of whether you played any sounds. Most sites doing anything interesting with WebAudio just set up their context at init time (until now there was no reason not to), so as a result almost every WebAudio demo out there got broken. I was looking through back issues of Web Audio Weekly and in Chrome it was a wasteland - nothing worked, autoplay or not. I know the Chrome team works hard, but sometimes it's hard to believe that they feel the responsibility of stewardship they have over the web. Breaking existing content with no benefit to user experience should be considered a showstopper bug, not something you just delay until "after developers have time to update their code".

xfitm3 8y ago
I live a quiet life and want my browser to be quiet too. I don’t fully understand the API changes behind this decision but from what I have read this is a huge win. The real problem is the unethical use of APIs to increase advertisement related KPIs.
- sp332 8y ago
  Not that many people are really advocating for autoplay. They just want a way to enable audio on specific sites. The Chrome changes take control away from the user.
- fenomas 8y ago
  You're saying you like the intent of the policy - that's fair enough. I'm saying that the implementation didn't match the intent - Chrome broke WebAudio sites regardless of whether they followed the intended policy. That's not a big win for anyone, it just breaks content to no benefit.
- ksk 8y ago
  The simplest solution is to not visit sites that don't respect your point of view. Reward sites who align with your interests and views.

mattdesl 8y ago

This is terrible. Chrome responded to a major breaking change by simply... delaying it? The exact same problems will be faced come October.

jimrandomh 8y ago

Currently they're saying: > The policy will be re-applied to the Web Audio API in Chrome 70 (October). Developers should update their code based on the recommendations at: https://developers.google.com/web/updates/2017/09/autoplay-policy-changes#webaudio https://developers.google.com/web/updates/2017/09/autoplay-p... This is wrong and really needs to be reconsidered. Nearly all of the examples of broken webpages on that thread are write-and-forget games, which will never be updated; this plan would break them permanently, just to save a little engineering effort in Chrome. The solution is simple: display a permissions request, like there currently is for camera, location and microphone. That's how it should've worked in the first place.

Ajedi32 8y ago
A permissions request isn't a good solution. Instead of having to deal with auto-playing video on every other site you visit, you'd now have to deal with a permissions prompt constantly popping up. IMO the best solution is to just mute the autoplaying media until the user interacts with the page. Completely transparent to sites, and doesn't burden the user with unnecessary pop-ups.
- anonymfus 8y ago
  Permission request is not necessary a pop-up prompt. It can be implemented as an additional state of the sound playing icon in the tab's title for example, and I am sure that good designers can invent something better.
  - unilynx 8y ago
    They already show an inline notification on the address bar when a page is trying to open a popup. They could've done the same for audio
- wyldfire 8y ago
  > IMO the best solution is to just mute the autoplaying media until the user interacts with the page This seems like a good compromise but doesn't sound like enough on its own. Sometimes I just open pages and look at the resulting video and it would be puzzling for it to be muted. Or does "interacts with" include merely viewing the tab? Even though it's religion for me, lots of people never or rarely ever "open in new tab". So this design change would eliminate the benefit.

tokyodude 8y ago

I actually agree with the motivations if not the outcome. Here's a maybe dumb suggestion. Make make a new API. Sites using the old API will get a blocking dialog. Sites using the new API will get the desired behavior. That way old content is still accessible. Maybe `new AudioContext2()` or `new AudioContext({version: 2})` or `new AudioContext({optIntoNewBehavior: true})` where old behavior pops up a modal dialog? Just throwing out ideas.

mattdesl 8y ago
I may be misunderstanding your comment, but what exactly is the benefit? Advertising websites can just switch to the new API to achieve autoplay audio, meanwhile all old sites will have a poor user experience as they will require additional browser UI and popups to use.
- tokyodude 8y ago
  The new API doesn't autoplay. The old API did. Changing the old API is what's breaking everything. So, if the old API blocks the page that page is still accessible. Click "Ok" and it's unblocked. If the page is using the new API then it doesn't get blocked but it also doesn't autoplay