Google show signs of reconsidering auto mute after developer critique
bugs.chromium.org
bugs.chromium.org
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?
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.
Try fastmail, it's really great.
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.
sending emails (if you care about delivery) became very centralized
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.
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.
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.
I think it probably is the right UX.
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.
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.
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".
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.
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.
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.
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.
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.)
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_.
Silent Navigation would block videos, audio, notifications, have an adblocker built-in etc.
that's the dream browser in 2018 IMO.
Edit: troydavis points out this Chrome option doesn't actually block autoplay: Chrome -> chrome://flags/#autoplay-policy -> Document user activation is required
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.
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...
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 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.
https://addons.mozilla.org/en-US/firefox/addon/mute-sites-by...
I can easily see Google saying, "eh, that's your problem, learn to whitelist your site with us."
#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."
> 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?
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).
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.
And the "subscribe to our newsletter" overlay often does block progress without hunting for the often obfuscated "no thanks" link.
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.
By trying to silence autoplaying video ads, they have thrown the baby out with the bathwater (except for certain specially whitelisted domains, like youtube).
https://developer.mozilla.org/en-US/docs/Web/API/Notificatio...