The Video Tag

Firefox 3.5 is out, and, among a slew of major improvements, it now supports the HTML 5 <audio> and <video> tags. I don’t post many video clips to Daring Fireball, but henceforth, when I do, it’ll be with the <video> tag. IE users can suck it.

John Gruber, Daringfireball

I couldn’t agree more. It would be especially nice if the <video> tag were to support FLV, (a) eliminating the need for idiotically customized FLV players, and (b) Flash.

Upgrade your web browser to Firefox 3.5 or Safari 4 or better to watch this video.

Do you see a video above? If not, the video tag on your browser isn’t fully supported (at least for QuickTime).

There’s just one problem: Gecko (i.e. Firefox’s HTML engine) only currently supports .ogg containers, which is about as useful as, er, something that isn’t useful. It doesn’t even support H264 or MP4v.

Java’s Broken Sandbox

Apple has just — finally — patched a bunch of well-known Java-related security issues with OS X. The Mac world can breath a sigh of relief that a potential threat to people who haven’t turned off Java in their web browsers has been averted… until the next “pwn to own” competition.

The biggest security issues on the Mac all seem to be Java-related. (Once you figure out how to get OS X to “execute arbitrary code” through some other security issue, the next biggest issue is Apple’s failure to effectively implement Address Space Layout Randomization, but Java’s the main way people seem to get to that point.)

The obvious way to handle this problem would be (a) for Apple to turn off Java by default, and/or (b) have the OS ask users who have Java switched on to confirm the launch of Java applets the way it asks users to confirm the launching of newly downloaded desktop applications. (This is pretty much how Microsoft has ended up dealing with the gaping security hole that ActiveX represents.)

Even if it weren’t for Java’s abysmal security record, it would be nice to know if you’re about to load a Java applet so you could just avoid that website on principle.

And for our next trick, let’s treat Flash the same way. Indeed, it would be interesting if browsers offered users the option of ignoring Flash but loading flv streams directly into a native player that bypassed Flash. (HTML5’s video tag is a step in that direction — the key would be to have browsers recognize FLV as a streaming video format and do an end-run around video players.) Aside from a few cute games and FLV players, exactly what do we need Flash for anyway?

Random Thoughts on Improving Internet Security

Disclaimer

IANACSE (I am not a computer security expert.) But…

When I was in my final year of high school, I had the opportunity to study with the Australian Mathematics Olympiad Squad. I didn’t make it into the team, but a friend of mine and I got close enough to be invited to the training, and be lectured to by Paul Erdos for a week. I’d love to say that this was an inspiring experience, but unfortunately the impenetrability of his accent was exceeded only by the material he was covering. It didn’t help that, alone among the participants, my friend and I hadn’t spent years in gifted programs and/or at universities getting exposed to graduate-level math.

For me, the highlight was a field trip to a presentation at a math conference about cryptography. I only understood the outlines of what the speaker was talking about at the time, but the subject matter was the theory underlying what is now known as public key cryptography. So, attending and not understanding that presentation, and a hazily recalled education in Pure Math, are my only special claims to domain knowledge.

The Problem(s)

The most commonly used internet protocols — http, ftp, and POP/IMAP/sendmail — are hopelessly insecure.

The standard solution for http is to switch to https.

With ftp at least there’s sftp. If your ISP doesn’t support sftp, use another ISP.

Email is pretty much a lost cause because even if your connection to your email provider is secure, the email transmission is not going to be, so anyone who cares about email is encrypting their email content using PGP or something similar.

I haven’t had an email exchange with anyone, ever, that required me to use PGP, so it’s obviously not very popular. By now, PGP should be built into every mail client and operate transparently (it would make spam harder and more expensive to send, too), instead our best option is usually webmail via https, or a proprietary solution like Microsoft Exchange or Lotus Notes (which has, laudably, been secure from the beginning — it’s a shame it sucks dead dog’s balls in pretty much every other respect).

OK, let’s ignore everything except http

I’ve recently been looking at implementing some kind of security for logging in to websites over http. The usual, simple solution for this is to switch over to https, but the vast majority of the world’s web servers are serving http, and this includes all kinds of services with logins and passwords that people don’t really think too carefully about. How likely is it that some username/password combination a given person uses for an insecure website (e.g. a blog, forum, or whatever) is also used for a secure website somewhere else? Even if https is secure (which is open to doubt), it’s undermined by the insecurity of http.

Here’s the actual form code for Digg.com‘s login form (modulo whitespace):

<form method="post" action="/login/prepare/digg">
<div class="form-row">
<label class="dialog-label" for="login-username">Digg Username</label>
<input class="login-digg-username text" name="username" value="" type="text">
</div>
<div class="form-row">
<label class="dialog-label" for="login-password">Digg Password</label>
<input name="password" class="login-digg-password text" type="password"> <a class="dialog-link forgot-link" href="/login">Lost username or password?</a>
</div>
<div>
<input name="persistent" checked="checked" type="checkbox"> <label class="inline"><strong>Keep me logged in on this computer</strong></label><br>
<input value="Login" type="submit">
</div>
</form>

I’m not trying to single out Digg — it’s just an example of a large scale, popular site that requires user logins and offers zero security. Facebook — a very high profile, popular site — is just as stupidly insecure (the relevant code is a bit harder to read). Why isn’t this a scandal?

It seems to me that it’s criminally negligent of the folks running these sites, and the people developing the most popular open source website software — phpbb, wordpress, drupal, etc. — not to have addressed this, when the solutions are so very straightforward and have been publicly and freely available for so long. Apple got into quite a bit of hot water — and rightly so — for (allegedly) not sufficiently securing MobileMe chatter between web apps and servers, but many of us spend a lot of time on all kinds of websites requiring passwords that make no real attempt at keeping our information safe.

  1. By default, during the setup of any of these programs, the admin should be forced to provide an encryption key, or — better — set parameters for automatically generating such a key for the website. Ideally the key would be refreshed periodically (or even created on-the-fly if the horsepower is available). Some security is better than no security at all, so even if the default key is “only” 64-bit this would be very helpful.
  2. The login page (and any other page where the user enters sensitive information) should simply incorporate JavaScript that takes the public key supplied by the server and encrypts it before posting it back to the website. Encryption in JavaScript, even on fairly slow machines and browsers, is close to instantaneous, and could be done in the background. If JavaScript is disabled, the code can warn the user and fall back to the usual (insecure) method.
  3. The web server then decrypts your private information using its private key.
  4. All such programs should make it easy for users to have their password sent to them encrypted via a supplied public key. (I.e. tell the user where to go to get crypto software to make their own key, and then allow the user to provide a public key (perhaps even store it in their profile) and use it to encrypt password reminders, etc., when necessary. The same techniques should be used to handle “secret question” transactions and the like (obviously).

Correction: as Andrew, my loyal reader, points out — servers shouldn’t store passwords at all. The server should store the hash, and for login attempts the server should ideally provide “salt” which should be added to the hashed password and encrypted before sending. Then, a hacker probably can’t “replay” the encrypted/hashed username/password combination to break in (since they won’t usually be able to enter the session which had that particular salt). Even if the server is totally compromised, no cleartext passwords are stored in the system. It follows that users can never have their old passwords sent to them, they can only be given an opportunity to reset their passwords. If a web service offers to send your password to you, avoid it if you can and treat it as utterly insecure otherwise.

The problem is that, in the end, the password restoration process is only as secure as email, so while the server shouldn’t store passwords and should allow resets instead of sending old passwords, ultimately you’ll need some mechanism to restore access, and if it goes over email we’re back to hopeless insecurity.

Steps one to three, of course, are essentially what https does (but only applied to sensitive data, rather than the whole web page), but has a number of added benefits. It allows reasonable levels of security on commodity http servers. And it will make https even more secure, since https is currently a single point of failure. Here are random hackers discussing methods for cracking or spoofing https. (Do you think your local Savings and Loan or Credit Union paid to have any additional security beyond https for its online banking software?) And it will give criminals headaches in trying to deal with a bizarre cornucopia of — possibly layered — security protocols. (It’s better to have ten different and not entirely reliable layers of security than one that you’re convinced is incredibly good — even if it is incredibly good.)

If nothing else, it’s a competitive advantage. After all, no security is impregnable — the trick is to be secure enough that would-be hackers pick an easier target.

Adobe CS4 — User Interface Clusterf**k

I’ve been “struggling” along with Adobe CS3 for some time, so finally switching to CS4 is a bit of a shock. To start with under Windows (I don’t have the Mac version) they’ve decided to opt for a non-standard Mac-like UI — the menu bar is at the top of the screen. OK that might be great, except that it’s (a) not the platform standard, (b) ugly, and (c) doesn’t actually benefit from Fitts’s Law because the menus are actually buttons that don’t reach the top of the screen. How hard would it have been to make the menus look (and work) like menus?

Adobe tries to implement a Mac menu bar under Windows and fails.
Adobe tries to implement a Mac menu bar under Windows and fails. Note that the shortcuts become underlined after you hit Alt -- which is both non-standard and annoying.

If you have multiple documents open, by default they’re arranged in tabs in an MDI-like interface (yes, they’ve combined a fake Mac menu bar that doesn’t benefit from Fitts’s Law with a fake MDI interface … if only they’d made everything Metal and put the main menu at the bottom-left of the screen it could have been perfect).

If you actually want to look at two documents side-by-side, well you can “tile” — which isn’t too bad, or you can “float” the windows — which separates the menubar and palettes from the documents. Exactly how this is supposed to be workable I’m not sure. What is definite is that Photoshop CS4 somehow manages to become a total slug when more than one document is visible or you use any floating windows. (When you choose Tile there’s a huge thunk … and I’m looking at empty documents on a late-model PC with lots of RAM.)

And the UI implementation is buggy too. When I tried to see if standard Windows keyboard shortcuts work as expected, well… the UI just went crazy. (They do kind of work, but they also trigger random behavior in the UI, so after pressing Alt, then F to see the File menu, the application had resized itself (beyond full screen) and magnified the underlying image.)

If you’re going to break platform rules, it should be for a good reason and you should do it competently. Adobe Photoshop CS4 feels like a bad X-Windows port.

Good grief.

Vista Naming Conventions

One of the first things Windows veterans notice upon switching to Vista is that “My Computer” has gone. It’s been replaced, of course, with “Computer”.

Obviously, Microsoft originally chose to name the icon “My Computer” in the interests of usability. They wanted the user to realize that the icon referred to the computer they were using and not some random computer, or the concept of a “computer” in general, and didn’t want to give the icon a stupidly long name such as “the computer you’re currently using, yes, this one” which, obviously, would be more precise (since most Windows computers are in fact “The Man’s Computer” or “Dad’s Computer” or “The incredibly crappy computer the school bought five years ago and never upgraded”. Of course in the interest of usability, Microsoft wanted to be precise, but not waste too much menu space.

But it seems that Apple’s infatuation with “usability” has begun to infect Microsoft to the point where they’re willing to drop the highly informative “My” from in front of all kinds of things, allowing veteran users to become horribly confused.

The “usability” fascists have been hard at work elsewhere, e.g. renaming certain standard applications such as “Outlook Express” to “Windows Mail”. Here, Microsoft is not only looking to Apple’s approach to “usability” (Apple’s Mail application is helpfully called “Mail”) but also to Open Source’s desire to keep branding clear (e.g. carefully referring to Firefox as “Mozilla Firefox” so you’ll find it under “M” instead of “F” and won’t confuse it with all those other Firefox programs, or helpfully putting a “K” in front of anything associated with KDE so that people will know it’s KDE Mail and not, say, GNU Mail; living in Alabama I can think of another organization that would heartily approve). So instead of “Outlook Express” (which might be confused with a “faster” version of Outlook) we have “Windows Mail”. It’s also good to know that you’ll be able to find “Windows Mail” under “W” along with all your other frequently used applications (such as “Windows Mobility Center” and “Windows Live Messenger Download”) in long alpha-sorted menus.

Might it be too radical to suggest that with Windows 7 Microsoft might consider dropping spurious branding from things like “Mail” and sort applications by their name or function instead of vendor?