Wandering Thoughts archives

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.)

'Command line text editor' is not the same as 'terminal-based text editor'

A while back, I saw a mention about what was called a new command line text editor. My ears perked up, and then I was disappointed:

Today's irritation: people who say 'command line text editor' when they mean 'terminal/cursor-based text editor'.

I understand why the confusion comes up, I really do; an in-terminal full screen editor like vi generally has to be started from the command line instead of eg from a GUI menu or icon. But for people like me, the two are not the same and another full screen, text based editor along the lines of vi (or nano or GNU Emacs without X) is not anywhere near as interesting as a new real command line text editor is (or would be).

So, what do people like me mean by 'command line text editor'? Well, generally some form of editor that you use from the command line but that doesn't take over your terminal screen and have you cursor around it and all that. The archetype of interactive command line text editors is ed, but there are other editors which have such a mode (sam has one, for example, although it's not used very much in practice).

Now, a lot of the nominal advantages of ed and similar things are no longer applicable today. Once upon a time they were good for things like low bandwidth connections where you wanted to make quick edits, or slow and heavily loaded machines where you didn't want to wait for even vi to start up and operate. These days this is not something that most people worry about, and full screen text editors undeniably make life easier on you. Paradoxically, this is a good part of why I would be interested in a new real command line editor. Anyone who creates one in this day and age probably has something they think it does really well to make up for not being a full screen editor, and I want to take a look at it to see this.

I also think that there are plausible advantages of a nice command line text editor. The two that I can think of are truly command line based editing (where you have commands or can easily build shell scripts to do canned editing operations, and then you invoke the command to do the edit) and quick text editing in a way that doesn't lose the context of what's already on your screen. I imagine the latter as something akin to current shell 'readline' command line editing, which basically uses only a line or two on the screen. I don't know if either of these could be made to work well, but I'd love to see someone try. It would certainly be different from what we usually get.

(I don't consider terminal emulator alternate screens to be a solution to the 'loss of context' issue, because you still can't see the context at the same time as your editing. You just get it back after you quit your editor again.)