Google show signs of reconsidering auto mute after developer critique

As my mom always said, "This is why we can't have nice things."

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.

Well it creates a disincentive for websites to use unnecessary audio. I don't think any user will be surprised or annoyed by seeing youtube or pluralsight asking them permission to play audio/video. For some random website where audio is unsolicited, it creates an incentive to not even ask. Like you don't want to necessary access the location of your users if you don't want to piss them off. I am actually happy when I can press no on some random website trying to access my location.

I think it probably is the right UX.

Those are both already horrible UXs that are abused in the same way the "subscribe to our newsletter" is. I won't ever do any of those three for 99.9% of websites I visit, and yet 70% are requesting it.

They've become user-hostile ways to give websites a way to force interaction from me that I don't ever want, and if I did I could chose the option in the account preferences (if I cared enough to make one).

It's not about being surprised, it's about not reading the dialogue at all.

I make a barcode scanning app in the browser. Our users know that the app scans barcodes using the camera, they receive training on the app before using it, and yet about ~15%~ (Edit: it's closer to 8% now) of our users click "no" when asked to allow camera permissions to scan barcodes. It was causing so many support calls that we ended up doing a 2-stage permissions prompt. First we display a javascript dialog telling the user that they need to click "yes" for the app to work, then we show the native permissions request after they have clicked yes, because if the user selects "no" the first time, we can't ask again, and 99% of users don't know how to go into the settings and re-enable it (hell, even I don't know where it is from memory, and would need to hunt around to find where it is)

And it doesn't create an incentive not to ask at all. At worst the website is where they would be if they didn't ask, at best they are able to display notifications, play audio, play video, get location, etc...

It's a no-lose situation in 99% of cases for the website owner, unless they actually really need that permission to function, then they have a LOT to lose. It's a situation where the incentives are misaligned terribly.

And don't get me wrong, i'm also very VERY happy that I can prevent notifications or location access, but I also think that more could be done to prevent spamming of the permissions prompt itself.

It might be just me, but I cannot (for the life me) understand what the issue is here. Maybe it's because I'm not a mobile game developer or content creator where audio and video is my life.

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.