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.
sending emails (if you care about delivery) became very centralized
Try fastmail, it's really great.
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.
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.
I think it probably is the right UX.
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_.
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 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.
Silent Navigation would block videos, audio, notifications, have an adblocker built-in etc.
that's the dream browser in 2018 IMO.
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.
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...