Also it's odd that Chrome decided to explicitly whitelist some sites. Surely that's an admission that their automated workflow doesn't actually work well?

I deeply miss the days when all it took was installing something akin to "Flask Block" and this problem was solved. I've been using Firefox with their built-in autoplay blocking feature (hidden in about:config) for a while now on my desktop and on mobile -- mainly because of idiotic news sites that seem to think I want to listen/watch the article I clicked in to (with the included pre-roll commercial, I assume[0]) and that my coworkers/wife want to listen to it, too.

The solution offered by the original bug report sounds practical, but the thing of it is, the solution that Chrome has implemented, in my opinion, doesn't go far enough[1]. I don't just want the audio muted, I want the whole video prevented from even starting to download (on my mobile device) -- it wastes limited data and costs me money.

It's sad that a "fix" to workaround a misuse of a feature is breaking legitimate uses. Having done a few years on the security side of the house at a telecom, I've tried to push developers in the direction of thinking about solutions from these sorts of angles. It's important when designing something to think about not just how your creation will be used, but how it can be misused and while the latter shouldn't necessarily prevent a feature from being implemented, it's important to weigh the two against each other and think about ways that problems might be mitigated. This might result in the adjustment of a feature, or it might be nothing more than a contingency plan should nefarious use eclipse legitimate use.

[0] I run uBlock Origin so I'm not entirely sure that there's a commercial -- I can only assume because the quality of the video, which is often nothing more than a man or woman reading the article, verbatim, in near-monotone voice is so poor that I can't imagine this being a feature added because of user demand.

[1] Though, muting audio is certainly a good start. I remember in the 2000s when people would pass around e-mails with links to important sounding things that, when clicked, would open a browser that screamed a message out of your speakers "Hey, everybody! I'm looking at porn!". Haven't seen that in a long time, but it'll come around again -- everything that's old is new again at some point.

I can easily see Google saying, "eh, that's your problem, learn to whitelist your site with us."

> Autoplay restrictions on the web have long been inconsistent and served only to impede legitimate use cases.

This is judgmental, and it is not backed up with any data. Has it really "served only" to impede the legitimate uses?

> I've described this in detail in the following blog

Blog promotion.

> What is the expected behavior? Allow audio playback on page load without any user interaction.

Definitively this is not the expected behavior. Chromium team has defined that no audio will be allowed until there is user interaction.

> Abusive content will just blare out audio at the first opportunity.

Yes. This is a red queen race. But doesn't means that it is not worth pursuing.

I think that the point is valid. But the premise of the report, it is not. With the goal of minimizing sound SPAM in the web, Chromium has imposed some drastic measures that require changes in the interfaces of a large unknown amount of Javascript code.

> "These restrictions require special coding to handle them. Instead, the browser could simply allow all playback attempts to succeed, but mute the master audio output. Then the browser can automatically unmute the master audio output the first time the user touches the screen (or whenever else it deems the user is OK with audio)."

The proposed solution is quite good. Let the browser show a button to enable sound like they did with pop-ups. So all the affected companies and individuals don't need to repeat the checks all over the internet, to create a unified experience and to keep legacy games and applications that have no chance of being updated.

But as another post says, there is a lot of corner cases. I can imagine a blind user wanting to have sound without having to read some text.

The company I work for was affected by this change. And there was a lot of problems in production. To fix it, people had to work the weekend. I know that should not be like that, that we need to improve beta browser testing, and such. But sometimes the realities of companies make this kind of behavioral changes difficult.

I hope that Chromium finds a good way of keeping ads muted, while not breaking the Internet.

Similar to how storing files or sending push notifications works?

I think people like me would benefit with an actual side-by-side demonstration of what the issue is now vs the resolution the author is proposing.

It's a shitty UX for everyone involved.

It's shitty for the user because they get asked it on SO MANY sites. I see friends/family browsing the web and they will go to a news site, click "no" to notifications, need to click away the fullscreen "want to subscribe to our newsletter" modal, then scroll down to the content. Adding a "want to allow this to display video" is just another step you need before being able to use the site.

And it sucks for site owners because those that legitimately need the ability to display video will have a pretty large percentage of their users react-click "no" on the dialog, meaning the site is broken until that user goes into settings and changes that one manually (and unsurprisingly, just about 0 do that).

Now I don't necessarily agree with the choice they've made here, but I do agree that a permissions dialog isn't the right UX.