Wandering Thoughts

Chrome extensions are becoming a reason not to use Chrome

A couple of weeks ago, a reasonably popular Chrome extension was stolen and infested with adware. If you're familiar with Google, you know what happened next: nothing. As people sent up frantic smoke signals and attempted to recover or at least de-adware a popular extension, Google was its usual black hole self. Eventually, sufficient publicity appears to have gotten Google to do something, and they even did the right thing.

In the process of reading about this, I discovered a couple of things. First, this is apparently a reasonably common happening, either through attacks or just through buying a sufficiently popular extension and then quietly loading it down with adware and counting on Google to be Google. Second and more alarming, this has happened to an extension that I actually had installed, although I didn't have it enabled any more. Long ago, I installed 'User-Agent Switcher for Google Chrome' because it seemed vaguely like something I'd want to have around. Now, well, it's apparently a compromised extension. One that works quite hard to hide its actions, no less. I've said bad things about how Chrome extensions mutate themselves to add adware before, but at least back then this was being done by the extension authors themselves and they seemed to have relatively modest commercial goals. The extension compromises that happen now are active malware, and according to the news about the User-Agent switcher extension, you can't even file any sort of report to get Google's attention.

I'm not going to blame Google too much for making Chrome so popular that its extensions have become an attractive target for malware attackers. I am going to blame Google for everything else they do and don't do to contribute to the problem; the silent, forced extension auto-updates, the cultural view that a certain amount of malware is okay, the clearly ineffective review process for extensions (if there is any at all), and being a black hole when really bad stuff starts to happen. Google runs Chrome extensions with the same care and indifference that they handle abuse on everything else they do.

These days I only use Chrome to run Javascript, because it does that better than Firefox on Linux. But I do use some extensions there, and they're apparently all potential time bombs. I'm sure the author of uBlock Origin is taking precautions, but are they taking enough of them? There are likely plenty of attackers that would love to gain control over such a popular and powerful extension.

(The smarter attackers will target less visible extensions that still have a decent installed base. A uBlock Origin compromise would be so big a thing that it probably would get Google to act reasonably promptly. As the example of User-Agent Switcher shows, if you compromise a less-popular thing you can apparently stay active for quite some time.)

How encryption without authentication would still be useful on the web

In HTTPS is a legacy protocol, I talked about how we are stuck with encryption being tightly coupled to web site authentication then mentioned in an aside that they could be split apart. In a comment, Alexy asked a good question:

How could encryption be useful at all without authentication? Without authentication, any MITM (i.e. ISP) could easily pretend to be other side and happily encrypt the connection. And we would still get our ISP-induced ads and tracking.

The limitation that Alexy mentions is absolutely true; an encryption-only connection can still be MITMd, at least some of the time. Having encryption without authentication for web traffic is not about absolute security; instead it's about making things harder for the attacker and thus reducing how many attackers there are. Encrypting web traffic would do this in at least three ways.

First, it takes passive eavesdropping completely off the table; it just doesn't work any more. This matters a fair bit because passive eavesdropping is easy to deploy and hard to detect. If you force attackers (including ISPs) to become active attackers instead of passive listeners, you make their work much harder and more chancy in various ways. All by itself I think this makes unauthenticated encryption very useful, since passive eavesdropping is becoming increasingly pervasive (partly as it becomes less expensive).

(One of the less obvious advantages of passive eavesdropping is that you don't have to handle the full traffic volume that's going past. Sure, it would be nice to have a complete picture, but generally if you drop some amount of the traffic because your eavesdropping machine is too overloaded it's not a catastrophe. With active interception, at least some part of your system must be able to handle the full traffic volume or increasingly bad things start to happen. If you drop some traffic, that's generally traffic that's not getting through, and people notice that and get upset.)

Second, using encryption significantly raises the monetary costs of active MITM interception, especially large-scale interception. Terminating and initiating encrypted sessions takes a lot more resources (CPU, memory, etc) than does fiddling some bits and bytes in a cleartext stream as it flows through you. Anyone who wants to do this at an ISP's network speed and scale is going to need much beefier and more expensive hardware than their current HTTP interception boxes, which changes the cost to benefit calculations. It's also probably going to make latency worse and thus to slow down page loads and so on, which people care about.

Finally, in many situations it's probably going to increase the attacker's risks from active MITM interception and reduce how much they get from it. As an example, consider the case of Ted Unangst's site and me. I haven't accepted his new root CA, so in theory my HTTPS connection to his site is completely open to a MITM attack. In practice my browser has a memorized exception for his current certificate and if it saw a new certificate, it would warn me and I'd have to approve the new one. In a hypothetical world with encryption-only HTTP, there are any number of things that browsers, web sites, and the protocol could do to make MITM interception far more obvious and annoying to users (especially if browsers are willing to stick to their current hardline attitudes). This doesn't necessarily stop ISPs, but it does draw attention and creates irritated customers (and raises the ISP's support costs). And of course it's very inconvenient to attackers that want to be covert; as with HTTPS interception today, it would be fairly likely to expose you and to burn whatever means you used to mount the attack.

None of this stops narrowly targeted MITM interception, whether by your ISP or a sufficiently determined and well funded attacker. Instead, unauthenticated encryption's benefit is that it goes a long way towards crippling broad snooping on web traffic (and broad alterations to it), whether by your ISP or by anyone else. Such broad snooping would still be technically possible, but encryption would raise the costs in money, irritated customers, and bad press to a sufficient degree that it would cut a great deal of this activity off in practice.

The problem with distributed authentication systems for big sites

In the comments on my entry on 'sign in with your Google/Facebook' authentication, people wished for a distributed cross-site web authentication system (of which there have been some number) but then lamented that nobody significant adopted any of them (as Anton Eliasson put it). As it happens, I think that there are good reasons for this disinterest by big sites beyond the obvious business ones.

The simple version is that when you allow your users to authenticate themselves using another site you put part of their experience with you in the hands of someone else, along with part of their account security. If you are a big site, some noticeable amount of your users will choose badly; they will use sites that are not reliable, that do not stay online forever, or are not secure. When bad things happen, those users will be unable to use your site (or at least have a much harder time of it) or their accounts get hacked and exploited. You will inevitably have to spend some amount of engineering resources building systems to deal with this, and then some amount of user support resources on dealing with people who run into these problems and can't fix them themselves. On top of that, a fair number of these users will probably blame you for their problems, even though they are not your fault in one sense.

(In another sense the problems are your fault. It is up to you to design your website so that people can use it, and if people find themselves locked out, that is your fault for allowing it to happen.)

When you run your own authentication system and require your users to use it, you own the full experience. You're entirely responsible for making authentication work well, but in exchange you're self-contained; you don't have to hope that anyone else is up and working right. When you are big and heavily engineered and almost everyone else is smaller and less well engineered, you may rationally feel that you're going to do a much better job on average than they are, with less downtime and problems. And if there are problems, you can troubleshoot the entire system yourself; you have end to end ownership of all components.

(As a corollary, if you're in this situation the very last thing you want to see is a bunch of your users all relying on the same outside authentication provider. The more of your users rely on a single outside provider, the more of an impact there will be if that provider stops working right. If a quarter of your users decide to authenticate with Yahoo and one day Yahoo is sold and turns off their authentication, you have a big problem. Unfortunately it's pretty likely that users will concentrate this way.)

Small sites that rely on big sites for user authentication face many of the same issues, but both the odds and the tradeoffs are different. It's pretty unlikely that Google's or Facebook's authentication systems will be broadly unavailable or malfunctioning, for instance. You can also cover most of your potential users by supporting only a few carefully chosen outside authentication sources, instead of potentially having a huge number of small ones (with various degrees of bugs or differences in how they view, eg, the OAuth spec).

(I'm talking here strictly about authentication, not about accounts and identity. Any serious site must own its own account system, because you cannot count on other people to keep spammers and abusers out of your system. To put it one way, Facebook is not going to close someone's account because they were nasty on your site.)

Sidebar: The business reasons matter too

Let's not pretend that business considerations don't matter, because they do for any commercial organization. To put it one way, when you allow authentication to be outsourced, you don't entirely 'own' all of your customers or users. Instead some of them are basically loaned to you from their authentication sources, and those sources might some day decide to end that loan. In an extreme case, all you have for those users is 'user X on service Y', and once service Y cuts you off you have no way of re-establishing a connection with those people so they can come back to your service.

Why I'll never pick the 'sign in with a Facebook or Google account' option

Recently I read Mike Hearn's Building account systems (via), where he strongly recommends that people not build an account system themselves but instead outsource it to Facebook and Google via OAuth. When I read that, I winced; not just at the idea of having 'sign in with ...' as my only option, but also because Mike Hearn's arguments here are actually solid ones. As he covers, it is a lot of hard work to build a good web account system and you will probably never be able to do it as well as Google and Facebook can.

I have any number of moderate problems with big-site OAuth, like how it gives Google and Facebook more information on my activities than I like (information they don't normally get). But this is not the core reason why I assiduously avoid 'sign in with ...' options. The core reason is that when I sign in with OAuth, my Facebook or Google account becomes a central point of losing access to many things. If Google or Facebook decide that they don't like me any more and suspend my account (or lock me out of it), I've probably lost access to everything authenticated through OAuth using that account. If I had to use 'sign in with ...', that could be any number of things that I care very much about (for example), far more than I care about my Google or Facebook account.

Facebook is far more dangerous here. Google generally doesn't seem to care if you have multiple accounts, while Facebook wants you to have only one and may suspend it if they decide that you're using a fake name. It's nominally possible to make a separate Google account for each site that demands you sign in with Google; it's not with Facebook as far as I know, at least within their Terms of Service.

(The other issue, as seen in an interaction with LinkedIn, is that using these sites as OAuth sources requires agreeing to their TOS as well as the TOS for the site you really care about. But then, everyone ignores TOSes anyway because if we didn't we'd all go mad.)

I have never personally been locked out of my Google or Facebook account (although I did worry about G+ stuff before the Google Reader shutdown). However, on a global scale it happens to plenty of people (anguished stories about it show up periodically in the usual circles), and I actually know someone who is currently locked out of their GMail account and is rather unhappy about it. As a result, I very much want to separate out all of my online accounts and I basically insist on it. So for entirely selfish reasons I certainly hope that web sites don't listen to Mike Hearn here.

Modern web page design and superstition

In yesterday's entry I said some deeply cynical things about people who design web pages with permanently present brand headers and sharing-links footers (or just permanent brand-related footers in general). I will condense these cynical things to the following statement:

Your page design, complete with its intrusive elements and all, shows what you really care about.

As the logic goes, if you actually cared about the people reading your content, you wouldn't have constantly present, distracting impediments to their reading. You wouldn't have things that got in the way or obscured parts of the text. If you do have articles that are actually overrun with branding and sharing links and so on, the conclusion to draw is the same as when a page of writing on a 'news' site is overrun by a clutter of ads. In both cases, the content is simply bait and the real reason the page exists is the ads or the branding.

Although it might be hard to believe, I'm actually kind of an optimist. So my optimist side says that while this cynical view of modern page design is plausible, I don't think it's universally true. Instead I think that what is going on some of the time is a combination of blindness and superstition. Or to put it concretely, I believe that most people putting together page design don't do it from first principles; instead, much as with programming, most people copy significant design elements from whatever web page design trend is currently the big, common thing.

(This includes both actual web designers and people who are just putting together some web pages. The latter are much more likely to just copy common design elements for obvious reasons.)

Obviously you don't copy design elements that you have no use for, but most people do have an interest in social media sharing and have some sort of organization or web site identity even if it's not a 'brand' as such (just 'this is the website of <X>' is enough, really). Then we have the massive design push in this direction from big, popular content farm sites that are doing this for entirely cynical reasons, like Medium. You see a lot of big web sites doing this, it's at least more or less applicable to you (and may help boost your writing and site, and who doesn't want that), so you replicate these permanent headers and footers in your site and your designs because it's become just how sites are done. In some cases, it may be made easier due to things like canned design templates that either let you easily turn these on or simply come with them already built in (no doubt partly because that's what a lot of people ask for). Neither you nor other people involved in this ever sit down to think about whether it's a good idea; it's enough that it's a popular design trend that has become pretty much 'how pages should look on modern sites'.

(I'm sure there's a spectrum running between the two extremes. I do drop by some websites where I suspect that social media shares are part of what keeps the site going but I also believe that the person running the site is genuinely well-intentioned.)

I consider this the optimistic take because means I don't have to believe a fairly large number of people are deeply cynical and are primarily writing interesting articles and operating websites in order to drive branding. Instead they do care about what they seem too and are just more or less reflexively copying from similar sites, perhaps encouraged by positive results for things like social media sharing.

Some terrible article page design elements on the modern web

Late last August, I tweeted the following rant:

I'm reading your article in Firefox's reader mode because your fancy, very pretty page layout sucks and gets in the way. Yes, yours.

You can improve your article layout immediately by removing the permanent bottom bar that wants me to share it on Twitter and Facebook.

Is your company's branding more important than your article? Your permanent top bar with your brand identity says that it is, to me.

I know, you're posting articles on the web primarily to build your brand identity. But you can be subtle about it, not rub it in my face.

(Since then, the specific article that triggered my rant (via) seems to have lost the bottom bar of sharing links but I think its top bar has gotten worse.)

I regret to say that nothing much has changed here in the past almost a year. What John Gruber has called persistent sharing dickbars are if anything more prevalent (although you can sometimes make them go away), and I haven't noticed any reduction in the number of sites with persistent branding headers either. In fact a permanent line or three at the top seems to now be a standard design element for everyone, and this remains just as terrible as it was last August.

(This is on a desktop. On my phone, sites usually have slightly less clutter but suffer more from what they have because a phone has less screen space.)

Vertical space is and always has been a precious resource (and the move to displays with a 16:9 aspect ratio hasn't helped). Stealing even a small portion of it is hostile to readers; just as with red, very little is actually that important. Well, at least to readers. Readers do not care that much about either sharing things on social media or someone's brand identity. The someone may care that much, or they may just be not thinking about it.

(Designers or people approving designs may even be so habituated to seeing these obnoxious things that brand headers and sharing footers no longer register as obnoxious; they've become something you ignore.)

These days I have become more and more trigger-happy with uBlock Origin's element zapper mode. I may not be quite willing to make people's header bars go away permanently because who knows, I may need something from them sometime. However, I'm certainly willing to make such bars go away while I'm reading an article, so I do.

(Sharing footers too, and they go away permanently if I can identify what to block and it seems worthwhile, which is mostly a function of how often I expect to visit the site. I should probably be more trigger-happy with permanent blocks too.)

HTTPS is a legacy protocol

Ted Unangst recently wrote moving to https (via), in which he gave us the following (in his usual inimitable style):

On the security front, however, there may be a few things to mention. Curiously, some browsers react to the addition of encryption to a website by issuing a security warning. Yesterday, reading this page in plaintext was perfectly fine, but today, add some AES to the mix, and it’s a terrible menace, unfit for even casual viewing. But fill out the right forms and ask the right people and we can fix that, right?

(You may have trouble reading Ted's post, especially on mobile devices.)

One way to look at this situation is to observe that HTTPS today is a legacy protocol, much like every other widely deployed Internet protocol. Every widely deployed protocol, HTTPS included, is at least somewhat old (because it takes time to get widely deployed), and that means that they're all encrusted with at least some old decisions that we're now stuck with in the name of backwards compatibility. What we end up with is almost never what people would design if they were to develop these protocols from scratch today.

A modern version of HTTP(S) would probably be encrypted from the start regardless of whether the web site had a certificate, as encryption has become much more important today. This isn't just because we're in a post-Snowden world; it's also because today's Internet has become a place full of creepy ad-driven surveillance and privacy invasion, where ISPs are one of your enemies. When semi-passive eavesdroppers are demonstrably more or less everywhere, pervasive encryption is a priority for a whole bunch of people for all sorts of reasons, both for privacy and for integrity of what gets transferred.

But here on the legacy web, our only path to encryption is with HTTPS, and HTTPS comes with encryption tightly coupled to web site authentication. In theory you could split them apart by fiat with browser and web server cooperation (eg); in practice there's a chicken and egg problem with how old and new browsers interact with various sorts of sites, and how users and various sorts of middleware software expect HTTP and HTTPS links and traffic to behave. At this point there may not be any way out of the tangle of history and people's expectations. That HTTPS is a legacy protocol means that we're kind of stuck with some things that are less than ideal, including this one.

(I don't know what the initial HTTPS and SSL threat model was, but I suspect that the Netscape people involved didn't foresee anything close to the modern web environment we've wound up with.)

So in short, we're stuck with a situation where adding some AES to your website does indeed involve making it into a horrible menace unless you ask the right people. This isn't because it's particularly sensible; it's because that's how things evolved, for better or worse. We can mock the silliness of the result if we want to (although every legacy protocol has issues like this), but the only real way to do better is to destroy backwards compatibility. Some people are broadly fine with this sort of move, but a lot of people aren't, and it's very hard to pull off successfully in a diverse ecology where no single party has strong control.

(It's not useless to point out the absurdity yet again, not exactly, but it is shooting well-known fish in a barrel. This is not a new issue and, as mentioned, it's not likely that it's ever going to be fixed. But Ted Unangst does write entertaining rants.)

I've become resigned to Firefox slowly leaking memory

Over the years I've written a number of things here about how my Firefox setup seems to be fairly fragile as far as memory usage goes, in that any number of addons or other changes seem to cause it to leak memory, often rapidly. Sometimes there have been apparently innocuous changes in addons I use, like NoScript, that cause a new version of the addon to make my Firefox sessions explode.

(I've actually bisected some of those changes down to relatively innocent changes and found at least one pattern in addon and even core Firefox JavaScript that seems to cause memory leaks, but I'm not sure I believe my results.)

For a long time I held out hope that if I only found the right combination of addons and options and so on, I could get my Firefox to have stable memory usage over a period of a week or more (with a fixed set of long-term browser windows open, none of which run JavaScript). But by now I've slowly and reluctantly come around to the idea that that's not going to happen. Instead, even with my best efforts I can expect Firefox's Resident Set Size to slowly grow over a few days from a starting point of around 600 to 700 MBytes, eventually crossing over the 1 GB boundary, and then I'll wind up wanting to restart it once I notice.

The good news is that Firefox performance doesn't seem to degrade drastically at this sort of memory usage. I haven't kept close track of how it feels, but it's certainly not the glaringly obvious responsiveness issues that used to happen to me. Instead I wind up restarting Firefox because it's just using too much of my RAM and I want it to use less.

(It's possible that Firefox's performance would degrade noticeably if I let it keep growing its memory usage, which of course is one reason not to.)

Restarting Firefox is not too much of a pain (I built a tool to help a while back), but it makes me vaguely unhappy despite my resignation. Software should be better than this, but apparently it isn't and I just get to live with it. Restarting Firefox feels like giving in, but not restarting Firefox is clearly just tilting at windmills.

Sidebar: The JavaScript pattern that seemed to leak

The short version is 'calling console.log() with an exception object'. The general pattern seemed to be:

try {
  [... whatever ...]
} catch (e) {
  console.log(e);
}

My theory is that this causes the browser-wide Firefox developer console to capture the exception object, which in turn presumably captures a bunch of JavaScript state, variables, and code, and means that none of them can be garbage collected the way they normally would be. Trigger such exceptions very often and there you go.

Replacing the console.log(e) with 'console.log("some-message")' seemed to usually make the prominent leaks go away. The loss of information was irrelevant; it's not as if I'm going to debug addons (or core Firefox code written in JavaScript). I never even look at the browser console.

It's possible that opening the browser console every so often and explicitly clearing it would make my memory usage drop. I may try that the next time I have a bloated-up Firefox, just to see. It's also possible that there's a magic option that causes Firefox to just throw away everything sent to console.log(), which would be fine by me.

In praise of uBlock Origin's new 'element zapper' feature

The latest versions of uBlock Origin have added a new feature, the element zapper. To quote the documentation:

The purpose of the element zapper is to quickly deal with the removal of nuisance elements on a page without having to create one or more filters.

uBlock Origin has always allowed you to permanently block page elements, and a while back I started using it aggressively to deal with the annoyances of modern websites. This is fine and works nicely, but it takes work. I have to carefully pick out what I want to target, maybe edit the CSS selector uBlock Origin has found, preview what I'm actually going to be blocking, and then I have a new permanent rule cluttering up my filters (and probably slightly growing Firefox's memory usage). This work is worth it for things that I'm going to visit regularly, but some combination of the amount of work required and the fact that I'd be picking up a new permanent rule made me not do it for pages I was basically just visiting once. And usually things weren't all that annoying.

Enter Medium and their obnoxious floating sharing bar at the bottom of pages. These things can be blocked on Medium's website itself with a straightforward rule, but the problem is that tons of people use Medium with custom domains. For example, this article that I linked to in a recent entry. These days it seems like every fourth article I read is on some Medium-based site (I exaggerate, but), and each of them have the Medium sharing bar, and each of them needs a new site-specific blocking rule unless I want to globally block all <divs> with the class js-stickyFooter (until Medium changes the name).

(Globally blocking such a <div> is getting really tempting, though. Medium feels like a plague at this point.)

The element zapper feature deals with this with no fuss or muss. If I wind up reading something on yet another site that's using Medium and has their floating bar, I can zap it away in seconds The same is true of any number of floating annoyances. And if I made a mistake and my zapping isn't doing what I want, it's easy to fix; since these are one-shot rules, I can just reload the page to start over from scratch. This has already started encouraging me to do away with even more things than before, and just like when I started blocking elements, I feel much happier when I'm reading the resulting pages.

(Going all the way to using Firefox's Reader mode is usually too much of a blunt hammer for most sites, and often I don't care quite that much.)

PS: Now that I think about it, I probably should switch all of my per-site blocks for Medium's floating bar over to a single '##div.js-stickyFooter' block. It's unlikely to cause any collateral damage and I suspect it would actually be more memory and CPU efficient.

(And I should probably check over my personal block rules in general, although I don't have too many of them.)

My situation with Twitter and my Firefox setup (in which I blame pseudo-XHTML)

Although it is now a little bit awkward to do this, let's start with my tweet:

I see Twitter has broken viewing regular Tweets in a browser that doesn't run JavaScript (gives endless redirections to the mobile site).

Twitter does this with a <noscript> meta-refresh, for example:

<noscript><meta http-equiv="refresh" content="0; URL=https://mobile.twitter.com/i/nojs_router?path=%2Fthatcks%2Fstatus%2F877738130656313344"></noscript>

Since I have JavaScript forced off for almost everyone in my main Firefox (via NoScript), Twitter included, my Firefox acts on this <noscript> block. What is supposed to happen here is that you wind up on the mobile version of the tweet, eg, and then just sit there with things behaving normally. In my development tree Firefox, the version of this page that I get also contains another <noscript> meta-refresh:

<noscript><meta content="0; URL=https://mobile.twitter.com/i/nojs_router?path=%2Fthatcks%2Fstatus%2F877738130656313344" http-equiv="refresh" /></noscript>

This is the same URL as the initial meta-refresh, and so Firefox sits there going through this cycle over and over and over again, and in the mean time I see no content at all, not even the mobile version of the tweet.

In other environments, such as Fedora 25's system version of Firefox 54, Lynx, and wget, the mobile version of the tweet is a page without the circular meta-refresh. At first this difference mystified me, but then I paid close attention to the initial HTML I was seeing in the page source. Here is the start of the broken version:

<!DOCTYPE html>
<html dir="ltr" lang="en">
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width,initial-scale=1,maximum-scale=1,user-scalable=0" />
<noscript>[...]

(I suspect that this is HTML5.)

And here is the start of the working version:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.1//EN" "http://www.openmobilealliance.org/tech/DTD/xhtml-mobile11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
  [... much more verbiage ...]

Although this claims to be some form of XHTML in its declarations, Twitter is serving this with a Content-Type of text/html, which makes it plain old HTML soup as far as Firefox is concerned (which is a famous XHTML issue).

What I don't understand is why Twitter serves HTML5 to me in one browser and pseudo-XHTML to me in another. As far as I can tell, the only significant thing that differs here between the system version of Firefox and my custom-compiled one is the User-Agent (and in particular both are willing to accept XHTML). I can get Twitter to serve me HTML5 using wget, but it happens using either User-Agent string:

wcat --user-agent 'Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0' https://mobile.twitter.com/thatcks/status/877738130656313344 | less

I assume that one of the issues here is that when Twitter decided to start forcing non-JavaScript browsers to the mobile version of tweets, they forgot to update the HTML5 version of the mobile tweet page to not have its own forcing of non-JavaScript people to what was originally (presumably) somewhere else. I suspect that this is because the HTML5 version is something very few people actually get, so the Twitter developers just forgot that it existed.

(Both versions of the mobile page try to load some JavaScript, but the HTML5 version seems to have more of it.)

Sidebar: How I worked around this

Initially I went on a long quest to try to find an extension that would turn this off or some magic trick that would make Firefox ignore it (and I failed). It turns out that what I need is already built into NoScript; the Advanced settings have an option for 'Forbid META redirections inside <NOSCRIPT> elements', which turns off exactly the source of my problems. This applies to all websites, which is a bit broader of a brush than would be ideal, but I'll live with it for now.

(I may find out that this setting breaks other websites that I use, although I hope not.)