Wandering Thoughts archives

Some more notes on Firefox 63 and perhaps later media autoplay settings

A few months ago I wrote some notes on Firefox's current media autoplay settings, which described the then state of affairs of Firefox Nightly and Firefox (and I then followed it up by discovering that Firefox needed some degree of autoplay support). It's perhaps not surprising that Mozilla has kept evolving this (given the general publicity around how people are unhappy about auto-playing videos), so things have changed around a bit in Firefox Nightly and thus presumably in Firefox 63 and later (until they change again). The current state of affairs has fixed some of my irritations but not all of them, and Mozilla has now made things more accessible in general.

First, Firefox now exposes a preference for media autoplay, and can have per-site settings for it. You find this in Preference → Privacy & Security, down in the 'Permissions' section, in a new setting that is (in English) 'For websites that autoplay sound'. Your options are allow, ask (or 'prompt'), and deny, and you also have an 'Exceptions' list. This preference corresponds to the media.autoplay.default setting. If set to 'ask', ever time you visit a new site that wants to autoplay something Firefox will pop up a little note about it, and then remember whatever you answer. If you block a site (or block all sites), you can still start video autoplay by hand.

(The old media.autoplay.enabled setting is now no longer used by anything. Also, it turns out that surfacing the preferences stuff is controlled by the media.autoplay.ask-permission setting, which Firefox Nightly defaults to true. It's possible that this means that some of this won't be visible and enabled in Firefox 63, but you can turn it on manually.)

As before, Firefox defaults to auto-playing silent or muted video. However, you can now control this through a setting, media.autoplay.allow-muted. Because this is an un-exposed setting, the 'can I play this' questions from Firefox always refer to 'media with sound' even if the video in question is silent or muted. This can be a little bit confusing. Unlike before, Firefox now always allows autoplay for bare video content such as directly linked .mp4s (these appear to be called 'video documents'), regardless of your settings (although they seem to start playing only when you switch to their tab). This is hard-coded in IsMediaElementAllowedToPlay() in AutoplayPolicy.cpp. Since I don't like this behavior, I hope that Mozilla adds a setting that allows us to control it, as they have for silent and muted video.

(Conveniently, the code in AutoplayPolicy.cpp now has log messages to record why something was allowed to autoplay; these are very helpful in understanding the code itself. One of the interesting new cases this exposes is that apparently addons can always autoplay things on their own internal pages.)

There is also now a separate check and setting for audio. Based on the code, setting media.autoplay.block-webaudio to true will more or less completely block web audio, possibly without any user override at all. Probably you don't want to do this unless you never, ever want your Firefox to play web audio under any circumstances at all.

The new setting media.autoplay.block-event.enabled appears to control whether JavaScript gets some sort of 'your autoplay is blocked' error when the autoplay is blocked by your settings. Firefox defaults it to off and I would leave it that way; presumably Mozilla knows what they're doing here.

So, the short version of what you want to do on Firefox Nightly and likely Firefox 63 if you want as little autoplay as possible is now:

• go to Preferences → Privacy & Security and the Permissions area, and set 'For websites that autoplay sound' to 'Don't Autoplay'. Equivalently, set media.autoplay.default to 1, but I'd use the Preferences version just to be slightly safer.
• in about:config, set media.autoplay.allow-muted to false.

Other relevant settings are now already at the values that you want. In particular, media.autoplay.enabled.user-gestures-needed now defaults to true, and probably will get removed some day in the future.

Why email is often not as good as modern communication protocols

I was recently reading Git is already federated & decentralized (via). To summarize the article, it's a reaction to proposals to decentralize large git servers (of the Github/Gitlab variety) by having them talk to each other with ActivityPub. Drew DeVault ntes that notes that Git can already be used in a distributed way over email, describes how git forges could talk to each other via email, and contrasts it with ActivityPub. In the process of this article, Drew DeVault proposes using email not just between git forges but between git forges and users, and this is where my sysadmin eyebrows went up.

The fundamental problem with email as a protocol, as compared to more modern ones, is that standard basic email is an 'anonymous push' protocol. You do not poll things you're interested in, they push data to you, and you can be pushed to with no form of subscription on your part required; all that's needed is a widely shared identifier in the form of your email address. This naturally and necessarily leads to spam. An anonymous push protocol is great if you want to get contacted by arbitrary strangers, but that necessarily leads to arbitrary strangers being able to contact you whether or not you're actually interested in what they have to say.

This susceptibility to spam is not desired (to put it one way) in a modern protocol, a protocol that is designed to survive and prosper on today's Internet. Unless you absolutely need the ability to be contacted by arbitrary strangers, a modern protocol should be either pull-based or require some form of explicit and verifiable subscription, such that pushes without the subscription information automatically fail.

(One form of explicit verification is to make the push endpoint different for each 'subscription' by incorporating some kind of random secret in eg the web-hook URL that notifications are POSTed to.)

It's possible to use email as the transport to implement a protocol that doesn't allow anonymous push; you can require signed messages, for example, and arrange to automatically reject or drop unsigned or badly signed ones. But this requires an additional layer of software on top of email; it is not simple, basic email by itself, and that means that it can't be used directly by people with just a straightforward mail address and mail client. As a result, I think that Drew DeVault's idea of using email as the transport mechanism between git forges is perfectly fine (although you're going to want to layer message signatures and other precautions on top), but the idea of extending that to directly involving people's email boxes is not really the right way to go, or at least not the right way to go by itself.

(To be blunt, one of the great appeals of Github to me is that I can to a large extent participate in Github without spraying my email address around to all and sundry. It still leaks out and I still get spam due to participating in Github, but it's a lot less than I would if all Github activity took place in mailing lists that were as public as eg Github issues are.)