Google show signs of reconsidering auto mute after developer critique(bugs.chromium.org)
bugs.chromium.org
Google show signs of reconsidering auto mute after developer critique
https://bugs.chromium.org/p/chromium/issues/detail?id=840866
55 comments
Google is starting to show a pattern of addressing the concerns of the large players (which themselves are a part of), and ignoring or degrading everyone else's experience.
Good luck trying to get predicable deliverability to gmail without your mail being put in the spam box as a small mail sender. Google refuses to even tell you anything about why or why not mail is being delivered unless you send hundreds of messages a day.
This is a small personal mailserver, compliant fully with DMARC/DKIM/SPF, has RDNS, reasonably old domain (a few years), IP not and never has been on any blacklist, reputable server provider, has been sending mail to gmail for a few years, is not sending anything except personal mail under my direct control, nothing that could even vaugely be considered commerical or spam of any kind.
Google still classifies it as spam, even with repeated clicking of "this is not spam" button by my recepients, after a while it just goes back in the spam folder, and has absolutely no hint at why, or how to change it.
To top it off im hearing reports that signing up for google suite for your domain immediately seems to remove this mysterious "fuck you filter", and you no longer get deliverability issues.
Ive heard similar rumours about placement in google search results, aswell as stuff like youtube recommendations, if you aren't already in the accepted list of stuff we wanna show you, dont bother even trying.
Its a very concerning thing because the outcry about shitty practices targeting the things 95% of people dont see, will be by definition limited, and yet it is these very things that are essential to remaining out under the thumb of parties like Facebook or Google.
Good luck trying to get predicable deliverability to gmail without your mail being put in the spam box as a small mail sender. Google refuses to even tell you anything about why or why not mail is being delivered unless you send hundreds of messages a day.
This is a small personal mailserver, compliant fully with DMARC/DKIM/SPF, has RDNS, reasonably old domain (a few years), IP not and never has been on any blacklist, reputable server provider, has been sending mail to gmail for a few years, is not sending anything except personal mail under my direct control, nothing that could even vaugely be considered commerical or spam of any kind.
Google still classifies it as spam, even with repeated clicking of "this is not spam" button by my recepients, after a while it just goes back in the spam folder, and has absolutely no hint at why, or how to change it.
To top it off im hearing reports that signing up for google suite for your domain immediately seems to remove this mysterious "fuck you filter", and you no longer get deliverability issues.
Ive heard similar rumours about placement in google search results, aswell as stuff like youtube recommendations, if you aren't already in the accepted list of stuff we wanna show you, dont bother even trying.
Its a very concerning thing because the outcry about shitty practices targeting the things 95% of people dont see, will be by definition limited, and yet it is these very things that are essential to remaining out under the thumb of parties like Facebook or Google.
microsoft is the same, one day our emails started to go directly to spam for office365 customers, the only effective thing that i could do is to move to mandrill.
there is zero spam, and all our emails are b2b notifications so no spam, not even newsletters.
sending emails (if you care about delivery) became very centralized
sending emails (if you care about delivery) became very centralized
Why don't you move away from Google? It's like intentionally sticking to one of the worst companies and then complaining about it.
Try fastmail, it's really great.
Try fastmail, it's really great.
It's not about receiving mail, it's about sending to others using Gmail accounts.
I have moved away from Google, that is the point of this mailserver. My point is that Google isnt interested in doing anything I send to @gmail.com addresses except classifying it as spam.
Now it would be nice if the people I want to email would move away from Google, but I highly doubt that is going to happen anytime soon.
Now it would be nice if the people I want to email would move away from Google, but I highly doubt that is going to happen anytime soon.
Read it again: it's his clients that are using google
Why didn't that happen here?
Chrome has long been the means for expressing "Google knows best" and leaving us to pick up the pieces. It's entirely predictable behavior that they're narrowing another aspect of expected solicitation of feedback before acting.
Chrome has long been the means for expressing "Google knows best" and leaving us to pick up the pieces. It's entirely predictable behavior that they're narrowing another aspect of expected solicitation of feedback before acting.
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.
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.
What I don't understand is why they went this convoluted route of trying to assess what's legitimate or not, what's a user interaction or not. Does anyone know why they didn't go the route of other permissions like notifications or location, with a discrete popup that says the page is attempting to play some audio (or video), do you want to allow? If it is legitimate, the user clicks allow once and the site works forever.
Because they sell ads, some of them video ads.
They probably wanted to avoid "breaking" major sites like Youtube, Spotify, and Soundcloud, and tried to create a smarter whitelist system.
How often do you see the "want to allow X to display notifications?" or "want to allow X to access your location?"
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.
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.
To be honest I'm not bothered by that UX at all. The browser remembers my choice for each site, how many new, different sites do most users visit per day (that would need audio)?
If a user doesn't want to be bothered by the prompt, they can always configure the browser to always accept or always reject. Or use a whitelist/blacklist.
This is very different from the EU "this website has cookies" prompt, which does annoy me a lot. First of all, you are not really choosing anything meaningful, but you still need to click. Secondly, being a website feature (not in the browser) means you don't get a uniform UI (and sometimes it's a nightmare on mobile). Third, it's just pointless as practically all websites have cookies so the amount of information in those messages is close to zero.
If a user doesn't want to be bothered by the prompt, they can always configure the browser to always accept or always reject. Or use a whitelist/blacklist.
This is very different from the EU "this website has cookies" prompt, which does annoy me a lot. First of all, you are not really choosing anything meaningful, but you still need to click. Secondly, being a website feature (not in the browser) means you don't get a uniform UI (and sometimes it's a nightmare on mobile). Third, it's just pointless as practically all websites have cookies so the amount of information in those messages is close to zero.
>The browser remembers my choice for each site, how many new, different sites do most users visit per day (that would need audio)?
How many sites need notifications? And why do I need to decline that permission at least once a day if not more often?
And the issue is that putting this behind a notification removes the downsides of asking for it. Currently if you play audio un-prompted you piss off (a percentage of) your users. If that was behind a notification, you would only inconvenience those users, so there's less of a downside of trying it assuming that only people that want it would click "yes".
My "perfect solution" would be for the major browser developers to get together, and come up with a web standard for where these notifications/prompts will live in the browser chrome, and roughly what they will look like, so that everyone can standardize on a similar UI. Then move from a prompt to a "badge" of sorts, and give websites the power to instruct users how to discover and switch that permission on/off when needed.
I believe on desktop chrome most permission prompts live in the upper-right corner of the address bar, if we could all standardize on somethign like that (at least on desktop, then figure something out for mobile) website owners could then instruct users "to see notifications, click the (standard-notification-icon) up there and select 'yes'".
For "rare" things like notifications, camera access, gps location, and others that seems like a good tradeoff to me, but for "more common" things like audio/video, I don't think it fits.
How many sites need notifications? And why do I need to decline that permission at least once a day if not more often?
And the issue is that putting this behind a notification removes the downsides of asking for it. Currently if you play audio un-prompted you piss off (a percentage of) your users. If that was behind a notification, you would only inconvenience those users, so there's less of a downside of trying it assuming that only people that want it would click "yes".
My "perfect solution" would be for the major browser developers to get together, and come up with a web standard for where these notifications/prompts will live in the browser chrome, and roughly what they will look like, so that everyone can standardize on a similar UI. Then move from a prompt to a "badge" of sorts, and give websites the power to instruct users how to discover and switch that permission on/off when needed.
I believe on desktop chrome most permission prompts live in the upper-right corner of the address bar, if we could all standardize on somethign like that (at least on desktop, then figure something out for mobile) website owners could then instruct users "to see notifications, click the (standard-notification-icon) up there and select 'yes'".
For "rare" things like notifications, camera access, gps location, and others that seems like a good tradeoff to me, but for "more common" things like audio/video, I don't think it fits.
That's the thing. I don't think audio and video should be that common on websites. Outside of youtube and netflix, 99% of the time I do not want audio or video content to play automatically.
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.
I think it probably is the right UX.
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.
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.
Yeah, clearly they read the dialogue if by adding more dialogue you change their action.
The problem may have been that simply asking for permission to use the camera in general and not stating when and how you would use that permission, people thought about the fact that they didn't really want to give the app blanket permission to use their camera.
The solution to that problem is to point out what you are using it for and tell them it is necessary, which is what you did.
The problem may have been that simply asking for permission to use the camera in general and not stating when and how you would use that permission, people thought about the fact that they didn't really want to give the app blanket permission to use their camera.
The solution to that problem is to point out what you are using it for and tell them it is necessary, which is what you did.
>Yeah, clearly they read the dialogue if by adding more dialogue you change their action.
No, because with our first-stage dialog we can just keep showing it until they click yes, but with the native dialog we only get one chance, and if they click "no" we might not even get a callback that they clicked anything at all on some browsers (which I honestly kind of like from a privacy standpoint).
But to be clear, i'm not happy with the 2-stage dialog. It feels condescending to ask for permission to ask, and for non-business applications it just slows down the "thing" that you are asking for permission for even more. But thus far it's the only thing that has consistently worked for us.
>The problem may have been that simply asking for permission to use the camera in general and not stating when and how you would use that permission
Our app is a business-oriented application that is running on dedicated company-owned phones in most cases. Users are trained on how to use it, how to set it up, how to create accounts and more.
About 8% of our new users still click no on average 2-3 times spending less than a second on the dialog according to some analytics I have on it. It dropped from 15% with the change from 1-step to 2-step permissions, but that's still a LOT of users that instinctively click "no".
No, because with our first-stage dialog we can just keep showing it until they click yes, but with the native dialog we only get one chance, and if they click "no" we might not even get a callback that they clicked anything at all on some browsers (which I honestly kind of like from a privacy standpoint).
But to be clear, i'm not happy with the 2-stage dialog. It feels condescending to ask for permission to ask, and for non-business applications it just slows down the "thing" that you are asking for permission for even more. But thus far it's the only thing that has consistently worked for us.
>The problem may have been that simply asking for permission to use the camera in general and not stating when and how you would use that permission
Our app is a business-oriented application that is running on dedicated company-owned phones in most cases. Users are trained on how to use it, how to set it up, how to create accounts and more.
About 8% of our new users still click no on average 2-3 times spending less than a second on the dialog according to some analytics I have on it. It dropped from 15% with the change from 1-step to 2-step permissions, but that's still a LOT of users that instinctively click "no".
So are you saying that you don't allow them to say no to the first-stage, and have it pop up immediately after, or that you pop it up every time they open the app?
I don't think it's innately condescending to ask someone for permission and outline exactly what you need the permission for, but I don't know the copy you are using.
I know that in context it makes sense, but people read things and don't think about them in larger context all the time. They think about them individually - do I want to give this thing permission to use my camera? No. Do I want to give it permission to use my camera so that it can do this thing I want it to do? Yes.
That's why outlining the purpose as in the second case makes it more likely for people to say yes.
Have you tried putting the reasoning on the second dialogue or is this a native one that is uneditable? You might be right if they are spending less than a second, but I've found with websites that a surprising number of people read everything. It'd be an interesting test if it's possible.
I don't think it's innately condescending to ask someone for permission and outline exactly what you need the permission for, but I don't know the copy you are using.
I know that in context it makes sense, but people read things and don't think about them in larger context all the time. They think about them individually - do I want to give this thing permission to use my camera? No. Do I want to give it permission to use my camera so that it can do this thing I want it to do? Yes.
That's why outlining the purpose as in the second case makes it more likely for people to say yes.
Have you tried putting the reasoning on the second dialogue or is this a native one that is uneditable? You might be right if they are spending less than a second, but I've found with websites that a surprising number of people read everything. It'd be an interesting test if it's possible.
>So are you saying that you don't allow them to say no to the first-stage, and have it pop up immediately after, or that you pop it up every time they open the app?
Basically we lock them from going further in the app by repeatedly showing the dialog immediately after a "no" answer, because at that point they need to scan barcodes and if they can't then the entire app is completely useless anyway.
>I don't think it's innately condescending to ask someone for permission and outline exactly what you need the permission for, but I don't know the copy you are using.
It just feels like it to me. We found it difficult to explain how you MUST say "yes" to the next prompt, it's for barcode scanning (which explaining this alone feels condescending, the app is called "x barcode scanning" FFS), the app cannot function without it. Just asking to ask alone feels wrong. I want my applications to be as easy to use and straightforward as possible, and doing stuff "automatically" rather than making the user manually do it is like 40% of my job, so it feels really wrong when I need to make it worse in that way.
>Have you tried putting the reasoning on the second dialogue or is this a native one that is uneditable?
Yeah it's the native one, so you can't change what it says.
It's tough, i can understand not wanting to allow websites to spam notifications constantly, but the "you only get one chance" really sucks.
Basically we lock them from going further in the app by repeatedly showing the dialog immediately after a "no" answer, because at that point they need to scan barcodes and if they can't then the entire app is completely useless anyway.
>I don't think it's innately condescending to ask someone for permission and outline exactly what you need the permission for, but I don't know the copy you are using.
It just feels like it to me. We found it difficult to explain how you MUST say "yes" to the next prompt, it's for barcode scanning (which explaining this alone feels condescending, the app is called "x barcode scanning" FFS), the app cannot function without it. Just asking to ask alone feels wrong. I want my applications to be as easy to use and straightforward as possible, and doing stuff "automatically" rather than making the user manually do it is like 40% of my job, so it feels really wrong when I need to make it worse in that way.
>Have you tried putting the reasoning on the second dialogue or is this a native one that is uneditable?
Yeah it's the native one, so you can't change what it says.
It's tough, i can understand not wanting to allow websites to spam notifications constantly, but the "you only get one chance" really sucks.
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.
NoScript / JS off by default will get rid of 99% of those annoyances and give you the article content immediately. (I am aware of the sites which hide the content behind JS, which are truly "shitty UX", but if more people used this config, perhaps they wouldn't proliferate as much. Fortunately most news sites aren't like that, in my experience.)
NoScript / JS off by default will get rid of 99% of those annoyances and give you the article content immediately. (I am aware of the sites which hide the content behind JS, which are truly "shitty UX", but if more people used this config, perhaps they wouldn't proliferate as much. Fortunately most news sites aren't like that, in my experience.)
If a website asks me to show notifications, to get my location or access my microphone before I even start to read what it is about, it fully deserves a permanent NO to any kind of permission.
Offer me notifications after you notice that I came back a couple of times to your website, ask me to autoplay the video the moment I play the video by hand. Remind me to grant permission to use the microphone the moment I try to start a video call.
Websites (and web developers) should learn to be _polite_.
Offer me notifications after you notice that I came back a couple of times to your website, ask me to autoplay the video the moment I play the video by hand. Remind me to grant permission to use the microphone the moment I try to start a video call.
Websites (and web developers) should learn to be _polite_.
I’ll immediately switch to using any browser that blocks auto play by default on all websites without exception.
there's got to be a "Silent Navigation" equivalent to the "Icognito/Private Navigation".
Silent Navigation would block videos, audio, notifications, have an adblocker built-in etc.
that's the dream browser in 2018 IMO.
Silent Navigation would block videos, audio, notifications, have an adblocker built-in etc.
that's the dream browser in 2018 IMO.
Firefox -> about:config -> media.autoplay.enabled -> false
Edit: troydavis points out this Chrome option doesn't actually block autoplay: Chrome -> chrome://flags/#autoplay-policy -> Document user activation is required
Edit: troydavis points out this Chrome option doesn't actually block autoplay: Chrome -> chrome://flags/#autoplay-policy -> Document user activation is required
Doesn’t seem to work on mobile (iOS)? Desktop is already sorted with noscript or uMatrix.
I use Firefox focus on mobile for news sites since it blocks most video and othe trash, but the lack of tabs and bookmarks is an issue.
I use Firefox focus on mobile for news sites since it blocks most video and othe trash, but the lack of tabs and bookmarks is an issue.
The Chrome flag doesn't do what it sounds like it does (and what it should). Essentially everyone logically interprets it as blocking all auto playing videos, audio or not, but that isn’t one of its options.
Given the number of people who hate unauthorized autoplaying video (including silent video), it’s sort of amazing that Chrome’s product management team hasn’t added a way to prevent it - at least as a buried config flag and ideally as domain rules (like the “Clear cookies on exit” rules). That wouldn’t preclude using automated heuristics to add and remove sites from the filters, but at least there’d be a reliable way to turn it off and whitelist a few domains.
Background from https://news.ycombinator.com/item?id=16367457#16370471:
“Alas, this flag only prevents video that has sound from auto-playing. It’s the inadequate option that my earlier comment was referring to.
Here’s more: https://www.chromium.org/audio-video/autoplay
https://developers.google.com/web/updates/2017/09/autoplay-p...
Quoting the blog post, Google’s decision that ”Muted autoplay is always allowed” is the problem. If any other Chrome users wondered why videos now auto-play without sound (even with this option set), at least based on the relatively minimal docs about this flag, this is why.
Given the number of people who hate unauthorized autoplaying video (including silent video), it’s sort of amazing that Chrome’s product management team hasn’t added a way to prevent it - at least as a buried config flag and ideally as domain rules (like the “Clear cookies on exit” rules). That wouldn’t preclude using automated heuristics to add and remove sites from the filters, but at least there’d be a reliable way to turn it off and whitelist a few domains.
Background from https://news.ycombinator.com/item?id=16367457#16370471:
“Alas, this flag only prevents video that has sound from auto-playing. It’s the inadequate option that my earlier comment was referring to.
Here’s more: https://www.chromium.org/audio-video/autoplay
https://developers.google.com/web/updates/2017/09/autoplay-p...
Quoting the blog post, Google’s decision that ”Muted autoplay is always allowed” is the problem. If any other Chrome users wondered why videos now auto-play without sound (even with this option set), at least based on the relatively minimal docs about this flag, this is why.
> Given the number of people who hate unauthorized autoplaying video (including silent video), it’s sort of amazing that Chrome’s product management team hasn’t added a way to prevent it
I wouldn't hold much hope for them doing this - the official autoplay policy announcement blog post says [1]:
> One cool way to engage users is about using muted autoplay and let them chose to unmute (see code snippet below). Some websites already do this effectively, including Facebook, Instagram, Twitter, and YouTube.
[1] https://developers.google.com/web/updates/2017/09/autoplay-p...
I wouldn't hold much hope for them doing this - the official autoplay policy announcement blog post says [1]:
> One cool way to engage users is about using muted autoplay and let them chose to unmute (see code snippet below). Some websites already do this effectively, including Facebook, Instagram, Twitter, and YouTube.
[1] https://developers.google.com/web/updates/2017/09/autoplay-p...
> One cool way to engage users is about using muted autoplay and let them chose to unmute (see code snippet below).
This line really illustrates how poorly Google understands the role of the browser. The browser's job isn't to help developers "engage" users, which just means getting them to spend more of their time on the site. Why would any user install a browser which is optimized to consume as much of their time as possible? The browser's job is to protect me from abusive publishers, not enable more abuse.
This line really illustrates how poorly Google understands the role of the browser. The browser's job isn't to help developers "engage" users, which just means getting them to spend more of their time on the site. Why would any user install a browser which is optimized to consume as much of their time as possible? The browser's job is to protect me from abusive publishers, not enable more abuse.
I would suggest just having the tab muted by default, and maybe an easier button to toggle on/off, than current right-click, to unmute/solo. Perhaps, a limited notification for the first 100 times your tab is muted and it detects sound being played in the tab, so you're not wondering why no sound is playing.
Something like this:
https://addons.mozilla.org/en-US/firefox/addon/mute-sites-by...
https://addons.mozilla.org/en-US/firefox/addon/mute-sites-by...
I'm not sure I saw any signs that they're "reconsidering" on this ticket -- just that they're now aware of how many corner cases they have.
I can easily see Google saying, "eh, that's your problem, learn to whitelist your site with us."
I can easily see Google saying, "eh, that's your problem, learn to whitelist your site with us."
That's not my interpretation of their comments at all.
#55 "Chrome Product Manager for desktop here. Thank you for posting these examples, they're superful helpful to the team. We didn't intend to break all this awesome existing content that relies on webaudio, and we are investigating paths forward now. More updates will follow on this bug."
#55 "Chrome Product Manager for desktop here. Thank you for posting these examples, they're superful helpful to the team. We didn't intend to break all this awesome existing content that relies on webaudio, and we are investigating paths forward now. More updates will follow on this bug."
that's corporate talk for "we don't care, let's stall and come with even more fucked up solution"
That's overly synical. They broke tons of their own stuff too, so my bet is on this being genuine.
The Issue report is not very well done.
> 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.
> 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.
Wouldn't this be easily resolved by giving the user the option upon visiting the site: "This website would like your permission to play audio. You can revoke this at any time."
Similar to how storing files or sending push notifications works?
Similar to how storing files or sending push notifications works?
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).
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).
The way that browsers typically handle this though is that your interaction isn't blocked by the prompt. There's a default state ('disallow'), the website can ask you for permission, and you can choose to either:
I agree that the permissions system isn't ideal, and I would hope that the way we handle this interchange in the future can improve to a point where it's less invasive in terms of screen space. But at least for now, it shouldn't invade your ability to continue using the site.
1. Allow
2. Deny
3. Do nothing at all
I agree that the permissions system isn't ideal, and I would hope that the way we handle this interchange in the future can improve to a point where it's less invasive in terms of screen space. But at least for now, it shouldn't invade your ability to continue using the site.
Its not about being blocked from continuing, it's about having to answer questions (or click away the dialogues) to peruse content.
And the "subscribe to our newsletter" overlay often does block progress without hunting for the often obfuscated "no thanks" link.
And the "subscribe to our newsletter" overlay often does block progress without hunting for the often obfuscated "no thanks" link.
Now I know I've been reading too much Reddit. I was really impressed by the well articulated, grammatically correct, and properly spelled postings in that bug thread. My standards have been lowered too far.
Until I read this entry's title, I'd never thought about whether Google is singular or plural—is "Google show..." an acceptable variant of "Google shows...?"
In general, style-guides say "companies are singular"
In American English it's "Group does X" but in British English it's "Group do X."
Both are fine. American English tends to treat collective nouns as singular, while British English treats them as plural. (http://www.dictionary.com/e/collective-nouns/)
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.
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.
This new Chrome "feature" mutes audio from many browser games and interactive audiovisual websites, offering no indication that audio is muted, and no way for the user to restore the audio.
By trying to silence autoplaying video ads, they have thrown the baby out with the bathwater (except for certain specially whitelisted domains, like youtube).
By trying to silence autoplaying video ads, they have thrown the baby out with the bathwater (except for certain specially whitelisted domains, like youtube).
isn't the "Allow website to send Notifications" prompt on 99% of mainstream websites irritating enough?
That’s because the api is badly defined, the javascript call to ask for notification is syncronous so the browser need that annoying blocking popup insteas of something less invasive like the popup notification
The javascript call to request notification permissions is async (returning a promise in newer browsers, callback in older ones).
https://developer.mozilla.org/en-US/docs/Web/API/Notificatio...
https://developer.mozilla.org/en-US/docs/Web/API/Notificatio...
Since JavaScript can generate moving imagery, and animated GIFs can as well, the only sensible thing is to consider the video as something conceptually different from audio. I wouldn't mind if they always allow videos to play, except I want full control over the audio at all times.
Is MySpace going to make a comeback here or what?
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?