Wandering Thoughts archives

2018-08-17

Some Firefox addons I'm experimenting with (as of Firefox 62 or so)

One of the interesting things that's happened as a consequence of my switch to Firefox Quantum (ie 57+) is that I've become much more willing to experiment with addons. My pre-Quantum Firefox setup seemed prone to memory leaks due to addons, which made me fairly nervous about adding more; resigned to leaks or not, I didn't really enjoy the experience. My Firefox Quantum setup seems to be clearly better on all aspects of this (both initial memory usage and growth over time), and this has made me more willing to try addons.

Technically I'm getting most of my exposure to these addons through the latest Firefox master tree ('mozilla-central'), which I compile from source every week or so. But I don't think they do anything different in Firefox 61 or 62, and I have set up some of them there.

Make Medium Readable Again (also, via) is basically what it says on the tin. I'm not affected by as much of the Medium plague as most because I disable most JavaScript and cookies through uMatrix, and I tried dealing with the remaining annoyances by blocking and re-blocking various HTML elements to try to eliminate their top bar and bottom bar, but eventually I got tired of it all. MMRA is a big hammer but it appears to be a reliable one so far, and it works across all of the very many sites and blogs and so on that use Medium, and it has some useful additional effects during the times when I have to turn on JavaScript in order to see important pictures or embedded Github gists of code or the like.

(Medium really is a plague and there is going to be a lot of carnage whenever it winds up shutting down, which I expect it to do within five or ten years at most. A lot of writing is going to disappear from the Internet and that bums me out.)

Certainly Something was pointed out to me on Twitter by @AleXgTorres. It's a quite thorough HTTPS connection information and certificate viewer. I don't use it very often but I care enough about TLS certificate stuff to keep it around in case (I have a history of having some such addon lying around), and it's not particularly obtrusive when I'm not using it. I could pick nits with the interface, but it's not that important in something that I only look at infrequently and CS's presentation of the certificate is traditional.

Finally I've recently added Link Cleaner (via the Mozilla blog entry) because I have to admit that I'm more than a bit tired of all of those utm_ fragments and other things. I sort of wish that it worked like my Google URL fixer addon and fixed the links in place, so that copying a link into some other program also gave me the de-utm'd version, but that's a minor thing. If I cared enough, well, LC's code is GPL3 and I could easily drop it into a version of my addon.

(The LC addon page is clear about how it works and there are probably benefits to cleaning the URL when it's actually used. Ultimately I don't care enough to go out of my way to deal with this; I barely care enough to use the addon when Mozilla basically shoved it under my nose.)

I've considered using 'Stylish' again (these days I'd use Stylus, since the actual 'Stylish' browser extension went bad), but I just don't seem to have much of a desire for re-styling websites these days. Most of what I want to do today is make annoying bits of websites go away entirely, and that's part of what I use uBlock Origin for. Possibly I could use some clever style override to deal with the header and footer plague, but my current answer is often to close the window instead.

Firefox61MoreAddons written at 01:16:38; Add Comment

2018-08-14

Our problem with HTTPS and user-created content

We have a departmental web server, where people can host their personal pages (eg) and pages for their research groups and so on, including user-run web servers behind reverse proxies. In other words, this web server has a lot of content, created by a lot of people, and essentially none of it is under our control. These days, in one sense this presents us with a bit of a problem.

Our departmental web server supports HTTPS (and has for years). Recent browser developments are clearly pushing websites from HTTP to HTTPS, even if perhaps not as much as has been heralded, and so it would be good if we were to actively switch over. But, well, there's an obvious problem for us, and the name of that problem is mixed content. A not insignificant number of pages on our web server refer to resources like CSS stylesheets using explicit HTTP URLs (either local ones or external ones), and so would and do break if loaded over HTTPS, where browsers generally block mixed content.

We are obviously not going to break user web pages just because the Internet would now kind of like to see us using HTTPS instead of HTTP; if we even proposed doing that, the users would get very angry at us. Nor is it feasible to get users to audit and change all of their pages to eliminate mixed content problems (and from the perspectives of many users, it would be make-work). The somewhat unfortunate conclusion is that we will never be able to do a general HTTP to HTTPS upgrade on our departmental web server, including things like setting HSTS. Some of the web server's content will always be in the long tail of content that will never migrate to HTTPS and will continue to be HTTP content for years to come.

(Yes, CSP has upgrade-insecure-requests, but that only helps for local resources, not external ones.)

Probably this issue is confronting anyone with significant amounts of user-created content, especially in situations where people wrote raw HTML, CSS, and so on. I suspect that a lot of these sites will stay HTTPS-optional for plenty of time to come.

(Our users can use a .htaccess to force HTTP to HTTPS redirection for their own content, although I don't expect very many people to ever do that. I have set this up for my pages, partly just to make sure that it worked properly, but I'm not exactly a typical person here.)

(This elaborates on an old tweet of mine, and I covered the 'visual noise' bit in this entry.)

HTTPSUserContentProblem written at 00:15:40; Add Comment

2018-08-05

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.

FirefoxMediaAutoplaySettingsII written at 23:08:19; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.