Wandering Thoughts archives

My current hassles with Firefox, Flash, and (HTML5) video

When I've written before about my extensions, I've said that I didn't bother with any sort of Flash blocking because NoScript handled that for me. The reality turns out to be that I was sort of living a charmed life, one that has recently stopped working the way I want it and forced me into a series of attempts at workarounds.

How I want Flash and video to work is that no Flash or video content activates automatically (autoplay is evil, among other things) but that I can activate any particular piece of content if and when I want to. Ideally this activation (by default) only last while the window is open; if I discard the window and re-visit the URL again, I don't get an autoplaying video or the like. In particular I want things to work this way on YouTube, which is my single most common source of videos (and also my most common need for JavaScript).

For a long time, things worked this way with just NoScript. Then at some point recently this broke down; if I relied only on NoScript, YouTube videos either would never play or would autoplay the moment the page loaded. If I turned on Firefox's 'ask to activate' for Flash, Firefox enabled and disabled things on a site-wide basis (so the second YouTube video I'd visit would autoplay). I wound up having to add two extensions to stop this:

• Flashblock is the classic Flash blocker. Unlike Firefox's native 'ask to activate', it acts by default on a per-item basis, so activating one YouTube video I watch doesn't auto-play all future ones I look at. To make Flashblock work well I have disabled NoScript's blocking of Flash content so that I rely entirely on Flashblock; this has had the useful side effect of allowing me to turn on Flash elements on various things besides YouTube.

  But recently YouTube added a special trick to their JavaScript arsenal; if Flash doesn't seem to work but HTML5 video does, they auto-start their HTML5 player instead. For me this includes if Flashblock is blocking their Flash, so I had to find some way to deal with that.

• StopTube stops YouTube autoplaying HTML5 videos. With both Flashblock and StopTube active, YouTube winds up using Flash (which is blocked and enabled by StopTube). I don't consider this ideal as I'd rather use HTML5, but YouTube is what it is. As the name of this addon sort of suggests, StopTube has the drawback that it only stops HTML5 video on YouTube itself. HTML5 video elsewhere are not blocked by it, including YouTube videos embedded on other people's pages. So far those embedded videos aren't autoplaying for me, but they may in the future. That might force me to not whitelist YouTube for JavaScript (at which point I almost might as well turn JavaScript off entirely in my browser).

  (An energetic person might be able to make such an addon starting from StopTube's source code.)

Some experimentation suggests that I might get back to what I want with just NoScript if I turn on NoScript's 'Apply these restrictions to whitelisted sites too' option for embedded content it blocks. But for now I like Flashblock's interface better (and I haven't been forced into this by being unable to block autoplaying HTML5 video).

There are still unfortunate aspects to this setup. One of them is that Firefox doesn't appear to have an 'ask to activate' (or more accurately 'ask to play') option for its HTML5 video support; this forces me to keep NoScript blocking that content instead of being able to use a nicer interface for enabling it if I want to. It honestly surprises me that Firefox doesn't already do this; it's an obviously feature and is only going to be more and more asked for as more people start using auto-playing HTML5 video for ads.

(See also this superuser.com question and its answers.)

Some other benefits of using non-HTTP frontend to backend transports

A commentator left a very good comment on my entry on why I don't like HTTP as a frontend to backend transport that points out the security benefits of using a simple protocol instead of a complex one. That makes a good start to talking about the general benefits of using a non-HTTP transport, beyond the basic lack of encapsulation I talked about in my entry.

The straightforward security benefit (as noted by the commentator) is that a simple protocol exposes less attack surface and will lead to implementations that are easier to audit. Very related to this is that full HTTP is a very complicated protocol with many dark corners, especially if people start trying tricky exploits against you. In practice, HTTP used as a transport is unlikely to use full HTTP (and hopefully many of the perverse portions will be sanitized by the frontend); however, just what subset of HTTP it uses is going to be some unpredictable, generally undocumented, and variable (between frontends). As a result, if you're implementing HTTP for a backend you have a problem; put simply, where do you stop? You probably don't want to try to implement the warts and all version of full HTTP, if only because some amount of the code you're writing will never get used in practice, but you don't necessarily know where it's safe to stop.

(Related to that is how do you test your implementation, especially its handling of errors and wacky requests? In a sense, real HTTP servers have a simple life here; you can simply expose them on the Internet and see what crazy things clients send you and expect to work.)

A transport protocol, even a relatively complicated one like FastCGI, gives you a definite answer to this. The protocol is much simpler than HTTP and much more bounded; you know what you have to write and what you have to support.

(There is a devil's advocate take on this that I will get to in a sidebar.)

Another pragmatic advantage is that using a separate transport protocol imposes a strong separation between the HTTP URL, host, port, and so on of the original request and the possible TCP port and endpoint of the transport protocol. Your backend software has to work very hard to confuse the two and thus to generate URLs that use the backend information instead of the real frontend request information. By contrast software behind a HTTP reverse proxy has to take very special care to use the right host, URL, and so on; in many configurations it needs to be specifically configured with the appropriate frontend URL information instead of being able to pull it from the request. This is a perennial issue with software.

Sidebar: the devil's advocate view of full HTTP complexity

Using a non-HTTP transport protocol doesn't necessarily mean that you avoid all of the complexity of HTTP, because after all your application is still dealing with HTTP requests. What your backend gets to avoid is some amount of parsing the HTTP request and sanitizing it; with some frontend servers you can also avoid handling things like compressing your response in a way that the client can deal with. Even under the best of circumstances this still leaves your backend (generally your application and framework) to handle the contents of HTTP headers and the HTTP request itself. This is where a great deal of the complexity of HTTP resides and it's relatively irreducible because the headers contain application level information.

You are also at the mercy of your frontend for how much sanitization is done for you, and this may not be well documented. Is there a header size limit? Does it turn multi-line headers (if a client is perverse enough to send them) into single-line entities or does it leave them with embedded newlines? And so on.

(Let's not even ask about, say, chunked input.)

If you're dealing with the contents of HTTP headers and so on anyways, I think that you can rationally ask if not having to parse the HTTP request is such a great advantage.

Why I don't like HTTP as a frontend to backend transport mechanism

An extremely common deployment pattern in modern web applications is not to have the Internet talk HTTP directly to your application but instead to put it behind a (relatively lightweight) frontend server like Apache, nginx, or lighttpd. While this approach has a number of advantages, it does leave you with the question of how you're going to transport requests and replies between your frontend web server and your actual backend web application. While there are a number of options, one popular answer is to just use HTTP; effectively you're using a reverse proxy.

(This is the method of, for example, Ruby's Unicorn and clones of it in other languages such as Gunicorn.)

As it happens, I don't like using HTTP for a transport this way; I would much rather use something like SCGI or FastCGI or basically any protocol that is not HTTP. My core problem with using HTTP as a transport protocol can be summarized by saying that standard HTTP does not have transparent encapsulation. Sadly that is jargon, so I'd better explain this better.

An incoming HTTP request from the outside world comes with a bunch of information and details; it has a source IP, a Host:, the URL it was requesting, and so on. Often some or many of these are interesting to your backend. However, many of them are going to be basically overwritten when your frontend turns around and makes its own HTTP request to your backend, because the new HTTP request has to use them itself. The source IP will be that of the frontend, the URL may well be translated by the frontend, the Host: may be forced to the name of your backend, and so on. The problem is that standard HTTP doesn't define a way to take the entire HTTP request, wrap it up intact and unaltered, and forward it off to some place for you to unwrap. Instead things are and have to be reused and overwritten in the frontend to backend HTTP request, so what your backend sees is a mixture of the original request plus whatever changes the frontend had to make in order to make a proper HTTP request to you.

You can hack around this; for example, your frontend can add special headers that contain copies of the information it has to overwrite and the backend can know to fish the information out of these headers and pretend that the request had them all the time. But this is an extra thing on top of HTTP, not a standard part of it, and there are all sorts of possibilities for incomplete and leaky abstractions here.

A separate transport protocol avoids all of this by completely separating the client's HTTP request to the frontend from the way it's transported to the backend. There's no choice but to completely encapsulate the HTTP request (and the reply) somehow and this enforces a strong separation between HTTP request information and transport information. In any competently designed protocol you can't possibly confuse one for the other.

Of course you could do the same thing with HTTP by defining an HTTP-in-HTTP encapsulation protocol. But as far as I know there is no official or generally supported protocol for this, so you won't find standard servers or clients for such a thing the way you can for SCGI, FastCGI, and so on.

(I feel that there are other pragmatic benefits of non-HTTP transport protocols, but I'm going to defer them to another entry.)

Sidebar: another confusion that HTTP as a transport causes

So far I've talked about HTTP requests, but there's an issue with HTTP replies as well because they aren't encapsulated either. In a backend server you have two sorts of errors, errors for the client (which should be passed through to them) and errors for the frontend server that tells it, for example, that something has gone terribly wrong in the backend. Because replies are not encapsulated you have no really good way of telling these apart. Is a 404 error a report from the web application to the client or an indication that your frontend is trying to talk to a missing or misconfigured endpoint on the backend server?

A peculiarity: I'm almost never logged in to websites

Over time, I've come to understand that normal people are almost always logged in to a whole host of big websites out there, even when they're not actually using them. Facebook, Twitter, Flickr, LinkedIn, Google, and so on and so forth, all of these pervasive behemoths that many people sooner or later wind up with accounts on (undoubtedly plus many other sites).

As you may have guessed, I don't do this. I especially don't do this with behemoths that have their tendrils of social buttons stretching across the Internet because I don't trust them. The only sites I'm willing to stay logged in on are ones that I trust a fair bit (and generally also use a decent amount). On top of this, my regular browser is so heavily protected from being infected with cookies that it's often easier to use my testing browser or Incognito Chrome for logins on new sites; as a consequence I wind up effectively 'logging out' when I close the browser and the cookies are discarded.

(I've wound up with a few sites that I use relatively regularly but that I don't trust in my main browser, sometimes because they require way too much JavaScript. So far I've isolated these into separate profiles in my testing browser, profiles that don't flush cookies.)

Among other effects, this sometimes gives me a skewed perspective on using popular sites, especially sites that I'm a member of. For instance, when I look at people's Twitter profiles in my browser I'm sure I'm getting a somewhat different experience than I would be if I was logged in. One of the differences, relevant to a recent issue, is that I cannot accidental betray to a website that member X followed link Y from social media, unassociated email, or whatever.

(Twitter is actually an especially interesting case of logged in versus not logged in because of how blocks work. If someone with an open account blocks you and you're logged in on Twitter, you apparently can't even look at their profile to see their tweets in your browser, although if you log out you can. Of course it goes the other way too; if I'm not logged in I can't see into private accounts that I do have access to through my Twitter accounts. This sometimes matters because looking at tweets in a browser can be the best way to see the thread of a conversation.)

HTTPS should remain genuinely optional on the web

I recently ran across Mozilla Bug 1041087 (via HN), which has the sort of harmless sound title of 'Switch generic icon to negative feedback for non-https sites'. Let me translate this to English: 'try to scare users if they're connecting to a non-https site'. For anyone who finds this attractive, let me say it flat out; this is a stupid idea on today's web.

(For the record, I don't think it's very likely that Mozilla will take this wishlist request seriously. I just think that there are people out there who wish that they would.)

I used to be very down on SSL Certificate Authorities, basically considering the whole thing a racket. It remains a racket but in today's environment of pervasive eavesdropping it is now a useful one; one might as well make the work of those eavesdroppers somewhat harder. I would be very enthusiastic for pervasive encryption if we could deploy that across the web.

Unfortunately we can't, exactly because of the SSL CA racket. Today having a SSL certificate means either scaring users and doing things that are terrible for security overall or being beholden to a SSL CA (and often although not always forking over money for this dubious privilege). Never mind the lack of true security due to the core SSL problem, this is not an attractive solution in general. Forcing mandatory HTTPS today means giving far too much power and influence to SSL CAs, often including the ability to turn off your website at their whim or mistake.

You might say that this proposal doesn't force mandatory HTTPS. That's disingenuous. Scaring users of a major browser when they visit a non-HTTPS site is effectively forcing HTTPS for the same reason that scary warnings about self-signed certificates force the use of official CA certificates. Very few websites can afford to scare users.

The time to force people towards HTTPS is when we've solved all of these problems. In other words, when absolutely any website can make itself a certificate and then securely advertise and use that certificate. We are nowhere near this ideal world in today's SSL CA environment (and we may or may not ever get there).

(By the way, I mean really mean any website here, including a hypothetical one run by anonymous people and hosted in some place either that no one likes or that generates a lot of fraud or both. There are a lot of proposals that basically work primarily for people in the West who are willing to be officially identified and can provide money; depart from this and you can find availability going downhill rapidly. Read up on the problems of genuine Nigerian entrepreneurs someday.)

Some consequences of widespread use of OCSP for HTTPS

OCSP is an attempt to solve some of the problems of certificate revocation. The simple version of how it works is that when your browser contacts a HTTPS website, it asks the issuer of the site's certificate if the certificate is both known and still valid. One important advantage of OCSP over CRLs that the CA now has an avenue to 'revoke' certificates that it doesn't know about. If the CA doesn't have a certificate in its database, it can assert 'unknown certificate' in reply to your query and the certificate doesn't work.

The straightforward implication of OCSP is that the CA knows that you're trying to talk to a particular website at a particular time. Often third parties can also know this, because OCSP queries may well be done over HTTP instead of HTTPS. OCSP stapling attempts to work around the privacy implications by having the website include a pre-signed, limited duration current attestation about their certificate from the CA, but it may not be widely supported.

(Website operators have to have software that supports OCSP stapling and specifically configure it. OCSP checking in general simply needs a field set in the certificate, which the CA generally forces on your SSL certificates if it supports OCSP.)

The less obvious implication of OCSP is that your CA can now turn off your HTTPS website any time it either wants to, is legally required to, or simply screws up something in its OCSP database. If your browser checks OCSP status and the OCSP server says 'I do not know this certificate', your browser is going to hard-fail the HTTPS connection. In fact it really has to, because this is exactly the response that it would get if the CA had been subverted into issuing an imposter certificate in some way that was off the books.

You may be saying 'a CA would never do this'. I regret to inform my readers that I've already seen this happen. The blunt fact is that keeping high volume services running is not trivial and systems suffer database glitches all the time. It's just that with OCSP someone else's service glitch can take down your website, my website, or in fact a whole lot of websites all at once.

As they say, this is not really a good way to run a railroad.

(See also Adam Langley on why revocation checking doesn't really help with security. This means that OCSP is both dangerous and significantly useless. Oh, and of course it often adds extra latency to your HTTPS connections since it needs to do extra requests to check the OCSP status.)

PS: note that OCSP stapling doesn't protect you from your CA here. It can protect you from temporary short-term glitches that fix themselves automatically (because you can just hold on to a valid OCSP response while the glitch fixes itself), but that's it. If the CA refuses to validate your certificate for long enough (either deliberately or through a long-term problem), your cached OCSP response expires and you're up the creek.

The core security problem of SSL on the web is too much trust

Every so often I'm surprised by what people don't already know (although I really shouldn't be). Today's surprise, due to Tim Bray's Blow up the Cert Business, is that people don't understand the core security problem with SSL on the web. I generally operate in an environment where this is common shared information, something that everyone just knows, but this is not the world in general.

So let's be explicit about what the real problem is:

The core security problem with SSL on the web is that your browser trusts a lot of Certificate Authorities and gives them power over any and all domains.

Your browser or operating system has a large list of built in CAs. Almost all of the time, SSL certificates signed by any of these authorities will be trusted to establish that you are talking to any random and arbitrary domain. There is no restriction on what domain names any of these CAs can issue valid certificates for and no mechanism that allows a domain to publish something that says 'no, no, wait, only trust SSL certificates for me that are signed by CA <X>'.

(Google has added special magic to Chrome to hard-code this for some domains, especially Google's. This has been extremely useful for turning up imposter SSL certificates, but it doesn't scale at all and thus it doesn't protect your site or my site.)

This means that the (global) security of your domain is hostage to the worst CAs and the CAs that are most subject to government coercion, because any of those CAs can issue certificates that web browsers will accept as valid for your domain. This is real SSL security (as opposed to the theoretical model with perfect CAs) and fundamentally why SSL certificates are a commodity. As the core weakness of SSL it has caused almost all of the SSL certificate security failures; some random CA that should not have any power to say 'I certify that this is website X' for some important X has in fact issued a certificate that says exactly that.

(The CA involved this time around simply makes it that much more obvious than usual, because it was not a general CA.)

This core problem of SSL cannot be fixed by getting better run CAs (or by imposing liability on CAs, never mind the problems with that). Extremely well run CAs are still vulnerable to government coercion and legal orders (orders that may come complete with gag requirements that prevent the CA from speaking out; we have seen that sort of thing in any number of places). For that matter, some CAs are themselves agencies of various governments (and your browser trusts them all and doesn't restrict what they can issue certificates for).

This problem cannot be solved by putting some or many commercial CAs out of business, as Tim Bray proposes. For a start you won't have gotten rid of the CAs that are effectively arms of their government. Beyond that, a root certificate that browsers trust is an extremely useful and valuable asset (perhaps a CA's most important one), one that will be transferred from owner to owner for as long as possible. I'm sure that there are any number of entities who would be happy to operate a CA at a loss merely to have power over such a certificate.

(Also, available evidence says that you can apparently operate a profitable CA that gives away free certificates. This suggests that putting commercial CAs out of business is going to be harder than you might expect.)

As far as I can tell the only way to solve this problem for real is for people to be able to somehow restrict which CAs can issue certificates for their web sites; an extreme version of this is for people to be able to restrict which actual certificates are accepted for their websites. Until this happens we will all remain hostage to all of those CAs that our browsers trust.

(I've written about these issues before, but I don't think I've previously laid out the core problem in black and white like this.)

PS: I hope it's obvious how much of a politically explosive non-starter it would be to try to drop perfectly operable CAs (either commercial or governmental) from browsers. As always, proposing something that cannot be done is not solving the real problem.

How my new responsive design here works

Encouraged by the commentators (and their suggestions) on my earlier entry about responsive design here, I sat down and banged out some CSS and revised my markup. Since I went through a bunch of iterations (many of them not working) to get my current results, I want to write down everything before I forget how it all works and why I needed to do things the way I have.

Following Aristotle Pagaltzis's suggestion, the core styling is done with 'display: table...' settings on <div>s. The div tree looks like this (roughly):

<div class="wtblog">
   <div class="maintext">
      ... left column contents ...
   </div>
   <div class="sidebar">
      ... sidebar contents ...
   </div>
</div>

In the normal CSS rules, wtblog is set to display: table while the other two are set to display: table-cell with their widths set to 76% and 24% respectively. This creates an implicit table row and stacks them up side by side with most of the space given to the main content. The table-* display styles seem well supported on anything I really care about (IE 7 users are out of luck, though). This is basically exactly the structure I used to create via actual <table>, <tr>, and <td> elements. The initial rewrite to this form was pretty much easy and painless.

My first CSS attempt to transform this into a minimized version with the sidebar below the main content was too clever. In my media qualifier rules I reset each column to 'display: table-row' in order to get them to stack on top of each other, which worked but had the problem that display: table-row entities can't have borders and I wanted to set a top border on the sidebar. This caused me to go through several iterations of inventing extra <div>s so that I would have something to make into a display: table-cell <div> inside the table-row <div>.

After a while I came to my senses and realized the straightforward, obvious solution: plain 'display: block' <div>s already stack on top of each other. So now the minimized version resets all three <div>s to be 'display: block; width: auto;' (in addition to tinkering with margins, borders, and various other things). This just works.

I did go through some amount of pain finding a @media query that would work on the iPad Mini, not just in a desktop browser when it was narrowed. After some fiddling I made it work by checking against max-device-width as well as plain max-width (which is what the browsers are happy with). I also have a really iPad Mini specific rule to increase the font sizes some as well; I aimed for something that would make my content look much like the 'readability' view you can get in the iPad browser.

While I was fiddling around with my CSS I also set up a maximum width so that people with giant browsers on giant screens don't get text that sprawls all over the place. The maximum width is probably still too wide for good readability, but I don't know what the right maximum width is considered to be (casual web searches did not help answer this question).

Because I'm lazy and not crazy I specified almost all of my limits and sizes in ems so I didn't have to care about font sizes. In fact I think this works best; someone who has really increased their font size because they find it more readable doesn't magically want to read fewer words in a line than normal. Unfortunately not everything has sensible default font sizes, especially the iPad Mini.

(In writing this entry I've discovered that CSS has added all sorts of exciting new sizing units since I last looked at it quite a lot of years ago. Possibly I will use some of them in my CSS at some point, once I understand things like rem and vw better.)

The whole experience has been a lot less painful than I expected it to be. Dealing with the iPad Mini's peculiarities was annoying and involved a lot of experimentation with things that didn't work, but apart from that things went pretty smoothly. I ran into one CSS quirk but it's documented, more or less, and I think it existed even in the <table> version of my layout.

(The quirk is that almost all of the ways you might think of to move the first line of one table cell down relative to the first line of the other table cell don't work. They either don't do anything or they move both columns down at once. The solution is to explicitly set 'vertical-align: top;' in the table cell you want to offset; then things like padding will start working.)

I need some responsive website design around here

For reasons that involve increasing usage and lowering costs, work got an iPad Mini and I wound up as its holder (it may shock you to know that we didn't really have any tablets around before this). One of the things I've done with it is look at websites, including Wandering Thoughts. In a way this is unfortunate, because now I really want to redesign Wandering Thoughts to be responsive. What I really mean by 'responsive' here is that I want the sidebar to go away on small screen devices.

(Well, the sidebar should go down to the bottom. I don't want it to go away entirely.)

The iPad Mini is small enough that screen real estate is at a premium on websites. If you use it in vertical mode, you don't have room for anything apart from the content text; if you use it in horizontal mode, well, you sort of have room for a sidebar but not really, and anyways you'd rather read vertically because that's more text and it's is laid out in a more readable way because it's narrower (in my view). I can only imagine how much worse this is on a smaller device, like a phone. This is the sidebar issue made quite concrete for me.

The problem is that I don't know the best way to do this without completely tearing the site design apart, or if it's even achievable very easily without Javascript (and I refuse to make Javascript a required thing here). Someday CSS grid layout will make this easy, whenever it's supported by most browsers (and perhaps finalized), but that day is not today. I suspect that I can't do this at all easily in regular CSS unless I start forcing column widths, but I haven't looked recently. And I'd rather not force column widths because then I'd have to read up on design to figure out how wide readable columns are, instead of my current approach of punting on it (since browser width determines column width and in theory people can make their browsers narrower or wider).

The radical approach would be a complete redesign of the look of Wandering Thoughts that permanently demoted what is currently the sidebar down to the bottom of the page even on regular browsers with lots of screen real estate. Many blogs today have taken this simplified approach but I'm not sure I like it (and I'm not sure I like the lower visibility of some things in the sidebar, like my Twitter). Still, it would solve the problem.

Ultimately design is a hard problem and CSS's current awkwardness doesn't make it any easier. This probably means the current Wandering Thoughts layout is going to stay as is, since that approach takes the least effort even if it makes me wince a bit when I look at the site on the iPad Mini.

The web is social, and thus minor features can matter a lot

For a very long time, DWiki (the software behind this blog) had a very primitive comment system. One of the ways that it was primitive is that it didn't have any explicit user-visible field for your name. When you made a comment here it showed up with your IP address at the time and it was up to you to explicitly sign the comment in some way if you wanted to. I always knew that this was rather low-rent, but it took me years to get around to fixing it. One of the reasons that I didn't get around to it very fast was that I didn't see it as a very important change; after all, it was just being a bit more explicit about comment author identification.

I was wrong. After I made the change last August, my perception of the entire character of the comments section here changed. The easiest way to put it is that suddenly I was reading and interacting with people, people with names (and sometimes websites). Part of this is that people actually filled in their names where before many hadn't gone to the extra work of signing their messages, but another part of it is that once I had people's names I changed how comments were displayed to show the name instead of the IP address. And the two together worked a magic transformation from bland IP addresses to named people.

The first lesson I draw from this is something that I already knew in theory, namely that the web is a social place. Interacting with people is a powerful thing and we like it. The more we see our interactions on the web that way, the better, which means that features that encourage that feeling are probably a good idea (even if they're small and simple ones, as here).

The second lesson is the power of small changes (or at least what you think of as small changes). My current guess or theory about this is that ultimately the illusion of personhood on the web is made out of smoke and mirrors; it's at least partially a trick we all play on ourselves when we imbue some codepoints on a screen with personhood and so on. As a trick, little nudges can go a long way (and probably little glitches can ruin the illusion). We're predisposed to see things on the web (and anywhere) as people, so all it needs is a push to do it and that push can be a small one.

(This goes with the general idea that people are social that I wrote about a long time ago.)

(I doubt that this is a novel observation. I just feel like writing it down due to my own striking experience with the DWiki comment change. Such a relatively small change, such a big shift.)