Wandering Thoughts

My current set of Chrome extensions (as of July 2016)

I know, I've said bad things about Chrome extensions before. Still, I seem to have slowly accumulated a number of extensions that I use, some of which I even trust, and that means it's worth actually documenting them so I can keep track (and easily put them into a new Chrome instance someday).

Unsurprisingly, my Chrome extensions are broadly similar in spirit to my normal set of Firefox extensions. Some of these Chrome extensions date back to years ago when I made a serious attempt to set up a Chrome equivalent of my Firefox environment so I could give Chrome a fair trial.

The obvious cases:

• uBlock Origin works just as well in Chrome as it does in Firefox, and is good for the same things and the same reason.

• HTTPS Everywhere because I feel that this is a good idea and why not.

User interface issues:

• The bluntly named Don't Fuck With Paste (also, and, via) makes it so that websites can't stop you from pasting things into form input fields. These websites are basically wrong and they make me very annoyed, since how I manage website passwords requires paste to work.

  (The Firefox equivalent is disabling dom.event.clipboardevents.enabled in about:config.)

• MiddleButtonScroll makes it so that you can scroll the page around with the middle mouse button. I'm extremely used to this behavior in Firefox, so I was happy to be able to get it in Chrome too.

• CLEAN crxMouse Gestures is a giant experiment that makes me nervous. There have historically been no good, non-spyware gestures extensions for Chrome (when one existed, it wound up corrupted). This extension at least claims and appears to be a 'clean' (ie non-spyware) version of the relatively good but spyware crxMouse Gestures extension. I'm not sure if I trust it, but I really, really want mouse gestures so I'm willing to take the chance as an experiment. If someone tells me that it too is bad, I will be sad but not surprised.

  (Adding this extension is what pushed me into writing this entry.)

Security, sort of:

• ScriptBlock is what I'm currently using as my NoScript equivalent on Chrome. Because my only major usage of Chrome is my hack use of incognito mode, I don't actually get much exposure to this extension so I don't really have any opinions on how well it works.

• FlashBlock for Chrome is theoretically there for the same reasons that I have it in Firefox, but again in practice I mostly use Chrome in a way that deliberately disables it so I don't really have many opinions. Plus, Chrome is increasingly disabling Flash all on its own.

Things that I should probably remove:

• Stylish is the Chrome version of the Firefox extension of the same name, which I used to make significant use of before I sadly discovered that it was part of my big Firefox memory leaks. In practice I don't use this in Chrome, but it seems harmless (and at the time I initially set up Chrome many years ago, it seemed like something I was going to want).

• Protect My Choices seemed like a good idea at the time that I ran across it but the more I look at it the more I'm not sure I should have this extension sitting around doing things.

  (It turns out that I only have this installed in my work Chrome, not my home Chrome. So it's going to get removed the next time I'm in the office.)

Since Chrome's incognito mode is mostly how I use Chrome, I have a number of these extensions enabled in it. Right now, the list is uBlock Origin, MiddleButtonScroll, Don't Fuck With Paste, and CLEAN crxMouse Gestures (because there isn't much point in adding a mouse gestures extension I don't entirely trust if I'm not going to use it).

In Firefox, I consider It's All Text! to be essential. Unfortunately Chrome's very different extension model means that the Chrome equivalents have always had to do terribly awkward things that made them unattractive to me.

Since incognito mode discards cookies when I close it down, I haven't tried to find any sort of cookie management extension. As usual, this might be a bit of a mistake, as I do use non-incognito Chrome just a bit and so I've probably picked up a certain amount of cookie lint in the process.

(For me, Linux Chrome is significantly faster than Linux Firefox for Flickr. Since logging in all the time is annoying, I use the regular Chrome in order to retain the necessary login cookies.)

My current set of essential extensions for Firefox profiles

For reasons beyond the scope of this entry, I recently set up a new Firefox profile. As a new profile it needs to be (re) customized for my preferences, including extensions. I can't just use my regular browser's set of extensions because this profile is for staying logged in to Twitter and needs to be set up so that Twitter is usable. Also, I don't want to spend a lot of time maintaining it, because I'm only going to use it once in a while.

Since there may be more single-use profiles like this in my future, I'm writing down my current set of essential Firefox extensions for this sort of environment. They are:

• FireGestures is just as essential here as it is in my regular browser. Its various gestures are part of my automatic reflexes by now and it's disconcerting to be in a browser environment that doesn't support them.

• uBlock Origin is a painless way to keep the tracking and advertisement and other invasions of my privacy down to a dull roar. A great benefit is that it basically needs no maintenance, so I can just ignore that I have it installed.

• Self-Destructing Cookies is a painless way to clean out the underbrush of invasive third party cookies that I'm probably slowly picking up every so often (partly from following the odd link from Twitter to elsewhere). I allow Twitter's cookies to persist so that I stay logged in, and everything else gets quietly junked.

  (In general SDC is good for any low usage or specialized profile where I want to use the low friction model of cookie handling.)

Although I've considered it, I'm not currently using NoScript in this profile. In theory NoScript shouldn't be blocking anything because I only use this profile on Twitter and I'd have to whitelist Twitter's JavaScript; in practice, it's likely to need at least periodic attention to whitelist some new domain that now has JavaScript that's necessary to keep Twitter working.

(If I follow links from Twitter to other sites in this profile, I may regret this choice. But I generally don't do that, since I read Twitter almost entirely through choqok and choqok is set to open links in my regular browser session.)

A number of my regular extensions are okay here and potentially useful, but aren't compelling enough to bother installing in a new profile that I'm using this way. Part of this is that Twitter allows you to control video autoplay in your settings, so I have it turned off; if that changed, FlashStopper or some equivalent might become important.

(Things would be a bit different if you could build bundles of extensions and extension preferences that would all install together. Then I'd probably roll in more of my standard extensions, because each additional extension wouldn't be a little additional drip of hassle to get and customize.)

Our central web server, Apache, and slow downloads

Recently, our monitoring system alerted us that our central web server wasn't responding. This has happened before and so I was able to immediately use our mod_status URL to see that yep, all of the workers were busy. This time around it wasn't from a popular but slow CGI or a single IP address; instead, a bunch of people were downloading PDFs of slides for a course here. Slowly, apparently (although the PDFs aren't all that big).

This time around I took the simple approach to deal with the problem; I increased the maximum number of workers by a bunch. This is obviously not an ideal solution, as we're using the prefork MPM and so more workers means more processes which means more memory used up (and potentially more thrashing in the kernel for various things). In our specific situation I figured that this would have relatively low impact, as worker processes that are just handling static file transfers to slow clients don't need many resources.

A high maximum workers setting is dangerous in general, though. With a different access pattern, the number of workers we have configured right now could easily kill the entire server (which would have a significant impact on a whole lot of people). Serving static files to a whole lot of slow clients is not a new problem (in fact it's a classic problem), but Apache has traditionally not had any clever way to handle it.

Modern versions of Apache have the event MPM, which its documentation claims is supposed to deal reasonably with this situation. We're using the prefork MPM, but I don't think we've carefully evaluated our choice here; it's just both the Ubuntu default and the historical behavior. We may want to reconsider this, as I don't think there's any reason we couldn't switch away from prefork (we don't enable PHP in the central web server).

(Per this serverfault question and answer, in the ever increasing world of HTTPS the event MPM is basically equivalent to the worker MPM. However, our central web server is still mostly HTTP, so could benefit here, and even the worker MPM is apparently better than prefork for avoiding memory load and so on.)

PS: There are potential interactions between NFS IO stalls and the choice of MPM here, but in practice in our environment any substantial NFS problem rapidly causes the web server to grind to a halt in general. If it grinds to a halt a little bit faster with the event or worker MPM than with the prefork one, this is not a big deal.

How (some) syndication feed readers deal with HTTP to HTTPS redirections

It's now been a bit over a year since Wandering Thoughts switched from HTTP to HTTPS, of course with a pragmatic permanent redirect from the HTTP version to the HTTPS version. In theory syndication feed readers should notice permanent HTTP redirections and update their feed fetching information to just get the feed from its new location (although there are downsides to doing this too rapidly).

In practice, apparently, not so much. Looking at yesterday's stats from this server, there are 6,700 HTTP requests for Atom feeds from 520 different IP addresses. Right away we can tell that a number of these IPs made a lot of requests, so they're clearly not updating their feed source information. Out of those IPs, 30 of them did not make HTTPS requests for my Atom feeds; in other words, they didn't even follow the redirection, much less update their feed source information. The good news is that these IPs are only responsible for 102 feed fetch attempts, and that a decent number of these come from Googlebot, Google Feedfetcher (yes, still), and another web spider of uncertain providence and intentions. The bad news is that this appears to include some real syndication feed readers, based on their user agents, including Planet Sysadmin (which is using 'Planet/1.0'), Superfeedr, and Feedly.

The IPs that did at least seem to follow the HTTP redirection have a pretty wide variety of user agents. The good or bad news is that this includes a number of popular syndication feed readers. It's good that they're at least following the HTTP redirection, but it's bad that they're both popular and not updating feed source information after over a year of permanent HTTP redirections. Some of these feed readers include CommaFeed, NewsBlur, NetNewsWire, rss2email, SlackBot, newsbeuter, Feedbin, Digg's Feed Fetcher, Gwene, Akregator, and Tiny Tiny RSS (which has given me some heartburn before). Really, I think it's safer to assume that basically no feed readers ever update their feed source information on HTTP redirections.

As it turns out, the list of user agents here comes with a caveat. See the sidebar.

(Since it's been more than a year, I have no way to tell how many feed readers did update their feed source information. Some of the people directly fetching the HTTPS feeds may have updated, but certainly at least some of them are new subscribers I've picked up over the past year.)

At one level, this failure to update the feed source is harmless; the HTTP to HTTPS redirection here can and will continue basically forever without any problems. At another level it worries me, both for Wandering Thoughts and for blogs in general, because very few things on the web are forever and anything that makes it harder to move blogs around is worth concern. Blogs do move, and very few are going to be able to have a trail of HTTP redirections that lives forever.

(Of course the really brave way to move a blog is to just start a new one and announce it on the old one. That way it takes active interest for people to keep reading you; you'll lose the ones who aren't actually reading more (but haven't removed you from their feed reader) and the ones who decide they're not interested enough.)

Sidebar: Some imprecision in these results

Without more work than I'm willing to put in, I can't tell when a HTTPS request from a given IP is made due to following a redirection from a HTTP request. All I can say is that an IP address that made one or more HTTP requests also made some HTTPS requests. I did some spot checks (correlating the times of some requests from specific IPs) and they did look like HTTP redirections being followed, but this is far from complete.

The most likely place where I'd be missing a feed reader that doesn't follow redirections is shared feed reader services (ie, replacements for Google Reader). There it would be easy for one person to have imported the HTTP version of my feed and another person to have added the HTTPS version later, quite likely causing the same IP fetching both HTTPS and HTTP versions of my feed and leading me to conclude that it did follow the redirection.

I have some evidence that there is some amount of this sort of feed duplication, because as far as I can tell I see more HTTPS requests from these IPs than I do HTTP ones. Assuming my shell commands based analysis is correct, I see a number of cases where per-IP request counts are different, in both directions (more HTTPS than HTTP, more HTTP than HTTPS).

(This is where it would be really useful to be able to pull all of these Apache logs into a SQL database in some structured form so I could sophisticated ad-hoc queries, instead of trying to do it with hacky, awkward shell commands that aren't really built for this.)

My concern about the potential dominance of the mobile web

Yesterday I wrote about how I don't know and can't find out how dominant the mobile web actually is. Today, let's take the (implicit) claims of the 'mobile first' design people as given and posit that the mobile web is either already dominant or going to become dominant in the not too distant future. In that case, well, I have concerns. In fact they are predictable concerns and are basically wrapped up in that nice phrase of 'mobile first' design.

Put simply, the web has seen this show before but back then it was usually called 'IE first design' or before then 'Netscape first design'. What these really translate to is that everyone else is a de facto second class citizen. Oh, sure, some amount of designers have good intentions and want to do a good job for other people (like the desktop web), but designers (and web developers) also have deadlines and priorities and only so much time. When you say 'mobile first', you implicitly accept that desktop people are allowed to have a degraded experience. That's what putting someone second means.

This is a direct concern of mine because I'm exclusively a desktop user, and more than that a Linux user of Firefox. This puts me well outside even the outside area of a broad 'mobile first' design (which is likely to target Safari and Chrome). This goes beyond worries about non-functional websites, as mobile first designs are likely going to be built for significantly smaller screen sizes than I have (well, smaller browser window sizes than I have). A functional website that wastes three quarters of the screen space I have and squeezes all of the content into a small area is probably not going to make me very happy.

(In theory responsive design can deal with this. In practice, I'm not at all convinced that people can (or will) make designs that scale across that large a screen size change, especially if mobile becomes their first priority.)

All of this concern is probably somewhat overblown, for many reasons including that much of my use of the web is fundamentally a diversion. In fact, the growth of the mobile web may have seen off the largest threat to the usable web that I've faced, namely the growth of Javascript-mandatory websites. Those defy even 'view page in no style' or Firefox's reader view.

(My understanding is that JavaScript on mobile is a lot slower and more power-hungry than it is on desktop, especially on lower end smartphones. My impression is that this has led to less client side JS and more server side content rendering in mobile focused website designs, although I may be out of touch here.)

How dominant is the mobile web (versus the desktop web)?

I was all set to write an entry about how the increasing dominance of the 'mobile web' (web usage from mobile devices) concerned me, but then I made the mistake of trying to find some reasonably current and solid facts about how web traffic is split between mobile and desktop and how it's been changing. Now I'm writing a different entry, because when I started looking I couldn't find anything that felt solid enough.

Everyone seems to agree that mobile usage as a whole is quite high (at least in first world countries), but a bunch of sources also claim that a lot of that time is spent in apps, not in browsing the web from mobile devices. Google apparently said in 2015 that more searches came from mobile devices than desktops in a number of countries (including the US and Japan). But the only actual usage numbers I could find seem to still have mobile browsing under half of browsing, and apparently not changing too fast; however, I have no idea how trustworthy those numbers are.

(Most people who put forward numbers seem to be out to sell you something, and who knows how reliable their methodologies are. I do believe Google's claim, but they did carefully hedge it.)

There is certainly a 'mobile first' movement for website design, but again there seems to be an aspect of boosterism to it. Certainly there have been plenty of past web design 'trends' that people advocated quite hard for but that never materialized in practice to the degree that their boosters thought (semantic markup, anyone?). And to the extent that this material is produced by pundits, well, pundits have to have something to hold forth about and that's often a future trend instead of a present reality.

(Some of this is a self-fulfilling prophecy, too. Depending on your perspective and how the website works, a 'mobile first' website might either unleash the pent up demand for well-done content from mobile devices or drive away some amount of the remaining desktop usage.)

Sidebar: 'Important' versus 'dominant'

If the mobile web is approaching half of all your web traffic, it's certainly big enough to be worth catering to and designing for. But if it's only (less than) half of traffic you can't focus on it to the exclusion of desktop design, the way you might if desktop usage was (say) only 20% and decreasing.

(It seems pretty clear that including the mobile web in your design is important these days. If nothing else, Google will rap your knuckles in search results if they don't consider you mobile-friendly (although some sources say that that's only for mobile searches).)

The browser security dilemma

So Pete Zaitcev ran into the failure mode of modern browsers being strict about security, which is that the browser locks you out of something that you need to access. The only thing I'm much surprised about is that it happened to Pete Zaitcev before it happened to me. On the one hand, this is really frustrating when it happens to you; on the other hand, the browsers are caught on the horns of a real security dilemma here.

To simplify, there are two sorts of browser users; let us call them sysadmins and ordinary people. Sysadmins both know what they're doing and deal with broken cryptography things on a not infrequent basis, such as device management websites that only support terribly outdated cryptography (say SSLv3 only), or have only weak certificates or keys (512 bytes only, yes really), or their certificate has long since expired and are for the wrong name anyways. As a result, sysadmins both want ways to override TLS failures and can (in theory) be trusted to use them safely. By contrast, ordinary people both don't normally encounter broken cryptography and don't really know enough to handle it safely if they do.

In an ideal world, a browser would be able to tell which sort of person you were and give you an appropriate interface. In this less than ideal world, what browser vendors have discovered is that if you expose a 'sysadmin' interface in basically any way, ordinary people will eventually wind up using it for TLS failures that they definitely should not override. It doesn't matter how well you hide it; sooner or later someone will find it and write it up on the Internet and search engines will index it and people will search for it and navigate the ten steps necessary to enable it (and ignore your scary warnings in the process). If we have learned anything, we've learned that people are extremely motivated to get to their websites and are willing to jump through all sorts of hoops to do so. Even when this is a terrible idea.

Since ordinary people vastly outnumber sysadmins, browsers are increasingly opting to throw sysadmins under the bus (ie, completely not supporting our need to override these checks some of the time). At the moment, some major browsers are less strict than others, but I suspect that this will pass and sooner or later Chrome too will give me and Pete Zaitcev no option here. Maybe we'll still be able to rely on more obscure things (on Linux) like Konqueror, at least if they're functional enough to handle the device management websites and IPMIs and so on that I need to deal with.

(Failing that, there may come a day where I keep around an ancient copy of Firefox to handle such sites, in just the same way that I keep around an ancient copy of Java to deal with various Java based 'KVM over IP' IPMI things. Don't worry, my ancient Java isn't wired up as an applet and only works in a non-default browser setup in the first place.)

It's time for me to upgrade my filtering HTTP proxy

I've been using a filtering HTTP proxy for a very long time now in order to filter out various sorts of things I didn't want from my browsing experience (most prominently cookies). I probably haven't been doing this for quite as long as filtering proxies have been available, but I now suspect that it's actually close, because it turns out that the filtering proxy I use was last updated in 1998. Increasingly, this long stasis in my filtering proxy is kind of a problem that I should deal with.

I haven't stuck with Junkbuster because I think it's some paragon of perfection here. Instead I've stuck with it because it still works without problems and, more importantly, I have a moderate collection of non-default filtering rules that I would have to copy over to any new filtering tool that I adopted (probably Privoxy, which I'm actually already using for filtering stuff related to syndication feed reading). But even though it still works, using Junkbuster is not without problems. Really, there are two big ones.

First, Junkbuster is HTTP/1.0 only, which means that all of my interactions with HTTP websites are constrained down to that. In practice this probably just costs me some amount of latency and speed. I'm not going to say that this is unimportant, but I can't say I've really noticed it. Still, I'd kind of like to have HTTP/1.1 available, if only to be nicer to websites out there by reusing the same connection instead of opening new one after new one.

More importantly (and more relevantly), Junkbuster is very definitely IPv4 only. This means that all of my regular HTTP browsing is IPv4 only, since it all goes through Junkbuster. Even if a site offers IPv6, I'll ignore that. As a result I don't actually use IPv6 all that much even when I have it available, and as a result of that I don't necessarily notice if my IPv6 connectivity breaks for some reason. I would like to change this, which definitely means a new proxy.

A mitigating factor is that all of this is irrelevant for HTTPS connections. Those are not proxied through anything for the obvious reasons, which means that they get HTTP/1.1 (or HTTP/2) and IPv6 support (and also that I have to rely purely on the protections of my browser addons). Over time I expect more and more browsing I do to be HTTPS browsing, but I also don't expect HTTP browsing to go away any time soon; there are still quite a lot of sites that are HTTP-based and they're probably going to stay that way for, oh, the next decade or more.

(As is traditional, I'm writing this entry partly to motivate myself into actually doing this at some point. Since nothing is really broken today, the work required is not entirely attractive; it's basically a bunch of work for very little or no visible improvement. Although probably I can simplify or eliminate a bunch of my current filtering rules; it's not as if I pay them much attention, so a bunch are likely to be long obsolete.)

An Apache trick: using directories to create redirections

Suppose, not entirely hypothetically, that you're using Apache ProxyPass directives as a reverse proxy to map /someurl/ on your website to another web server. You generally have to redirect the URL with the trailing slash, but of course you would like a request for a plain '/someurl' to also work right instead of just getting a 404 status response. Here, 'work right' means that you'll generate a redirection from '/someurl' to '/someurl/'.

It's certainly possible to do this with one of the various Apache directives for explicit redirections (I'd use RedirectMatch). But often there's an easier way: use a real filesystem directory. If somedir is a directory in the Apache document root and you send a request for '/somedir', Apache's default behavior is to send exactly the redirection we want. And Apache doesn't care if the '/somedir/' URL is being diverted somewhere other than the filesystem (via ProxyPass or other directives); it will still send that redirection regardless.

So we can just do 'mkdir /docroot/someurl' and everything will work. The directory contents don't matter; I tend to put a README file there with a note about how the directory is just there for the redirection and actual contents in it will be ignored.

(This redirection trick happens automatically if you're using .htaccess files in a directory to control, say, internal redirections. However there are various reasons for not using .htaccess files, including centralizing your configuration in one easily visible place instead of spraying it all over the filesystem in a bunch of nominally invisible files.)

Back when I wrote my entry on ProxyPass, I theorized about using this trick. I can now say that we've actually done this in our configuration and it works fine.

(This trick is a very old one, of course; I'm sure people have been doing it in Apache for ages. I just feel like writing it down explicitly for various reasons.)

A weird little Firefox glitch with cut and paste

Yesterday I wrote about Chrome's cut and paste, so to be fair today is about my long standing little irritation with Firefox's cut and paste. Firefox doesn't have Chrome's problem; I can cut and paste from xterm to it without issues. It's going the other way that there's a little issue under what I've now determined are some odd and very limited circumstances.

The simplest way to discuss this is to show you the minimal HTML to reproduce this issue. Here it is:

<html> <body>
<div>word1
  word2</div>
</body> </html>

If you put this in a .html file, point Firefox at the file, double click on 'word2', and try to paste it somewhere, you will discover that Firefox has put a space in front of it (at least on X). If you take out the whitespace before 'word2' in the HTML source, the space in the paste goes away. No matter how many spaces are before 'word2', you only get one in the pasted version; however, if you put a real hard tab before word2, you get a tab instead of a space.

(You can add additional ' wordN' lines, and they'll get spaces before the wordN when pasted. Having only word2 is just the minimal version.)

You might wonder how I noticed such a weird thing. The answer is that this structure is present on Wandering Thoughts entry pages, such as the one for this entry. If you look up at the breadcrumbs at the top (and at the HTML source), the name of the page is structured like this. As it happens, I do a lot of selecting the filenames of existing entries when I'm writing new entries (many of my entries refer back to other entries), so I hit this all the time.

(Ironically I would not have hit this issue if I didn't care about making the HTML generated by DWiki look neat. The breadcrumbs are autogenerated, so there's no particular reason to indent them in the HTML; it just makes the HTML look better.)

This entry is also an illustration of the use of writing entries at all. Firefox has been doing this for years and years, and for those years and years I just assumed it was something known because I never bothered to narrow down exactly when it happened. Writing this entry made me systematically investigate the issue and even narrow down a minimal reproduction so I can file a Firefox bug report. I might even get a fixed version someday.

PS: If you use Firefox on Windows or Mac, I'd be interested to know if this cut and paste issue happens on them or if it's X-specific.