Firesheep - What you need to know.

So, what do you need to know about Firesheep?

What it does

Firesheep makes it trivial for any Firefox user ( Windows or Mac, Linux coming soon ) to do a "Sidejacking" attack on the browser session of anyone on the same non-protected* wifi network that the attacker is on. For example, Facebook is one of the sites that is vulnerable ( and by far the biggest name in terms of actual usage ). So, if you're at a coffee shop and someone has Firesheep installed, and you log into Facebook on your laptop, they get a notification on their laptop that you've just logged in, with your profile picture. They click on it and !Bingo! they can instantly do whatever they want, as you, to your Facebook account. That's it in a nutshell.

The developer's post on it is here: http://codebutler.com/firesheep

What sites are vulnerable?

The current list is here: http://github.com/codebutler/firesheep/tree/master/xpi/handlers/

The only notable exception is Google. Google has secured themselves from this vulnerability by locking up their services with SSL. More on this in a second.

What do you mean by that "*" in the first part?

It's easier actually to define what I don't mean. WPA2 ( The "2" is important ) wifi networks are NOT vulnerable. WPA, WEP, WEP2, and open networks ( and whatever other kind you might have that doesn't use WPA2 ) ARE vulnerable. Basically the entire point of WPA2 is to protect clients from other clients.

So, for example, there are 3 coffeehouses within a 3 minute drive of my house. One has a WPA2 network. The other two don't. Guess where I'm getting a Latte?

So, as a user, if you're WPA2, good to go.

What if I'm not on a WPA2 network?

Well, then you need to be careful. What do I mean by "careful"? Use Firefox with the SSL Anywhere Addon. Or a Tor network. Or if you have the means, VPN. More about some options here: http://news.cnet.com/8301-27080_3-20008217-245.html

Is this a lot of technical mumbo jumbo? Yes. Do you want a 15-yr-old hoodlum posting bestiality pictures on your profile the next time you want to surf over a mocha? Probably not.

At the end of the day, though, these are all just throwing a carpet patch over a wine stain in terms of the real behind-the-scenes problem. The only way to actually eliminate the risk is to secure all of a site's traffic with SSL encryption. Up till now the industry standard for when this was necessary was "If e-commerce is involved". That may be a thing of the past. More for site owners farther down the page.

Is someone doing "something™" about it?

Well. Perhaps. As I said, Google already did. I don't run Facebook. Maybe you could email Mark Zucherberg? I hear he's pretty busy these days. Basically we all just have to wait & see.

SSL is in truth not all that expensive. And if enough users make enough noise, yes "they" probably will do "something" about it.

I have a website. Can people use this to break into it?

Many of our client sites have Administrative panels to manage their site's content. If you take the same kind of precautions as you would for Facebook, you'll be fine regardless. However, the real question is - are you on the list of sites I linked above? No? You're not the next Google? Ok you're probably pretty much fine as far as Firesheep is concerned. Basics like making sure you have a strong password, using SSL Anywhere, regularly updating your Windows Anti-Virus software and running scans, etc. will probably keep you pretty secure in terms of your own website.

So what REALLY "fixes" it on my web site?

As mentioned before, it really is up to the site owner and administrator to provide the real fix for it. That fix is: *trumpets* S S L.

SSL ( Secure Socket Layers ) changes the address of your website from http://mysite to: https://mysite. It also encrypts all traffic between your site and the end user so that no one in the middle ( ex: Firesheep users at the coffee shop ) can decipher the conversation.

Honestly, SSL is peace of mind, and it's fairly inexpensive peace of mind. You'll spend less on it than you do on a couple months of car insurance. We can recommend that you do this, but it's really up to you.

Locally Caching Google Web Fonts

So recently amid all my hubbub of implementing CSS3 & HTML5 feature sets, I ran into a very annoying problem regarding Google Web Fonts ( Which I love, tremendously ). The problem, in a nutshell, is this: DoubleClick. I have hated this "technology" for as long as it's existed. Not for any paranoid tin-foil-hat-wearing concerns about my cat pictures being cached for all eternity. Rather because it's so painfully resource-intensive. When I'm trying to access web content and I see in my browser status bar, "Waiting for xyz.doubleclick....", a slow seething sort of anger starts to seep into me.

Well, it turns out that since Google now owns DoubleClick and they put it in pretty much everything, "everything" includes end user downloads of Web Fonts, which is otherwise an excellent and extremely game-changing solution for presentation design. As opposed to, say, sifr, which makes me want to run away and hide under Zeldman's seat cushion.

Also, as far as my personal anecdotal testing is concerned, these fonts do _not_ cache well. Maybe the actual font does, but the added HTTP overhead from DoubleClick pretty much negates any actual caching of the font data itself. So, how to fix? Well, pretty simply, really, as it turns out. I'll outline it here.

The current state of affairs:

If you include a Google Web Font in your HTML documents and have any sort of basic thimblefull of knowledge about HTML & CSS relationships, you'll notice that the basic relationship is just like any other CSS include <link> that you might create yourself. The difference is that the end document is not a flat CSS file, but rather "dynamically" calls for a specific font family & possible variant(s) to be pulled into your overall HTML document. Like this:

<link href="'http://fonts.googleapis.com/css?family=PT+Sans:regular,italic,bold,bolditalic&subset=latin' rel='stylesheet' type='text/css'>

Well, so that's fairly ok, right? Just for kicks, let's go & see what that page contains. It's just a URL after all. Click Here to see it:

http://fonts.googleapis.com/css?family=PT+Sans:regular,italic,bold,bolditalic&subset=latin

Again, fairly ok. Now, we have a whole new set of URL's, and some basic CSS to encapsulate them. Again, in this example I've selected all 4 variants of PT Sans. You might have more or fewer in your actual usage of a particular font.

Again, copy-paste one of those URL's into a browser tab ( you're using tabs, right? Ok, just checking... ). Ah, now here's NOT a normal text file ala CSS/HTML. It is in fact a ttf, or True Type Font, file. Again if you inspect the URL you can tell that it's being "dynamically" generated.

This is all fine & well and not a huge concern, if you have even some basic access to your web stores, ala FTP.

The Fix:

What I've done can be pretty simply described. I've added a few flairs based on long-term considerations. Basic steps:

1. Copy-Paste the font ( or font family ) CSS file.


2. Put the resulting FLAT CSS file at a location & naming convention of your choosing, somewhere within your web app or a centralized known location that you can always get to.


3. Download each of the .ttf files, rename them according to some sensible convention, inclluding the actual ".ttf" file extension. The mime-type should be included in the binary of the file itself. ( This is a good theory. If any knows how to test it let me know. )


4. Place those, again, somewhere sensible that you can access. A "ttf/" directory in the directory that you placed that CSS file in step 2 seems pretty darn reasonable to me.


5. Edit the CSS to reflect the new URL's of those .ttf's instead of Google's "dynamicized" URL's.


6. Edit the original CSS include to reflect the new location of your flat CSS file.
7. Enjoy fast download times on Web Fonts.

That's pretty much it.

Some Considerations:

Naming conventions I used were pretty much according to my existing web development conventions. "PTSans.css" ( really complicated, right? ). "ttf/PTSansItalic.ttf" ( super creative, I know. ).

I also placed these on my own company domain, under a /_css/webFonts/ directory. That way I can "locally" store them just once and continually recycle the URL's for them.

If I'm going to use one of these, I'm just going to grab all variants from Google, do all this downloading once, and be done with it, rather than piece-mealing each variant. Small bit of extra time now, saving time later.

I used wget ( best command line tool E V E R ) to pull these to my web server. If you happen to be blessed with shell access, here's an example ( assuming you're cd'd to the directory you want the .ttf's in ):

# wget http://themes.googleusercontent.com/font?kit=F51BEgHuR0tYHxF0bD4vwvesZW2xOQ-xsNqO47m55DA -O PTSansBold.ttf

Hope that helps someone. This post is mostly just to document the fact that DoubleClick latency is EXTREMELY annoying, and that again, from my anecdotal testing definitely affects end-user experience if you're trying to use this overall technique.

Earlier today I read Steve Jobs' thoughts on Flash, as posted on Apple's Website. You can read his comments here: http://bit.ly/bUXHZl

Now, this issue has been brewing for a while. As a Web Professional, I have some pretty strong opinions all around about. I've never really felt the need for a blog, but as my thoughts continued to pour out on Facebook, I quickly realized that 410 characters just wasn't going to be enough to encapsulate them. So here I am.

I'm so split on this whole topic.

On the one hand:

I can't disagree with Apple's tech reasons. Adobe has some terrible technologies ( Flash, AS3, ColdFusion, DreamWeaver, Contribute: I'm looking at you, guys ). The Internet would be a far better place without them. I am actually one of the biggest Macromedia haters you're likely to find within a few router hops of a given area. Keep in mind: I'm not talking about Adobe core products previous to that merger. Photoshop, Illustrator, all those design tools. Have fun. GoLive was a wretched wretched waste of bytes, but whatever. Not that many people used it anyway. I did quite a lot of Flash coding though, specifically in AS2. The move to AS3 had me very excited. I was looking forward to improvements in all the things we devs had been clamoring for for so long. Then I picked it up. Namespaces, strict methods, lack of logic in override capabilities, par-for-the-course AWFUL documentation, blatant changes in core Objects to the point that there was no point in trying to salvage old code... I could go on and on, but the point is I nearly threw the book out a window in disgust. Haven't touched it since. I've administered a ColdFusion 7 server. I've heard 8 is supposed to be marvelous? I couldn't care less. I finally had to write a PHP script to monitor ColdFusion and kill/restart the service whenever it choked on its own sputum ( many many times each month ), so that I didn't have to get phone calls at 10:30 at night and go leaping for a WiFi connection any more.

To sum up: everything that Steve is talking about? I get it. Seriously.

On the other hand!

I'm excited about HTML5. I look very much forward to CSS3. I'm on board, man. I spend at least a few hours every week looking at examples, checking up on browser support, messing about with it on the side. I can't wait till it's mature enough to release on a production project. Here's the thing: It's not even a RECOMMENDATION yet. The W3C is still trying to figure out what it's supposed to be. Browser support for its featureset ( which is changing by the week ) is minimal at best. Yes, there are a few cool gimmicky implementations - many of which show promise for robust solutions - but this is just geeks taking the prototype new Web rocket out for a spin at this point. Wear a helmet, because it's a bumpy ride. This is not production mainstream stuff. And, as usual, the last kids to the party? Microsoft. Their browser IE, which depending on who you ask or where you're sitting could be from 30% to 95% of a given userbase ( 30 for the W3C, 90 for just about any corporate Intranet site ) is getting NOWHERE implementing it. So we're what, a year out? Maybe? Depending on when Redmond decides to wake up and smell the doctype? Here's Wikipedia's latest knowledge of the progress among all browser engines in getting HTML5's current known features up and running: http://bit.ly/ak1o7A

The Crux

I guess my problem is that Apple is shoving 10-15% of the global userbase forward forcibly while IE is going to drag 50% ( or so, depending ) of the userbase back for who knows how the hell long. And developers and clients are going to be stuck in the middle. That is as I see it, like it or not, the reality of what we'll have to deal with for the next couple years. I don't get to say, "F Flash" just because Steve Jobs does. I have to support everyone. It's the same reason why I've been dying to legitimately say, "I don't support IE6" since roughly 2003 and I can't. I had to test a rather persnickety navigation bar in IE6 just this week to make sure it was working and matched the design spec.

And what's Steve's solution? I will quote:

"If developers need to rewrite their Flash websites, why not use modern technologies like HTML5, CSS and JavaScript?"

That's great, Steve. Are YOU going to pay for that? Because when I start recoding something, it's going to cost someone money. And part of the value of hiring someone like me in the first place is to keep your TCO low over time. Not re-develop your site every time Apple says "Jump".

I've got one site in particular in mind. The entire business basis for it is to deploy videos to a very specific audience for subscriptions. We developed it using the best tool for the job at the time: Flash Video. At this point, they're pushing 1,000 videos. Those all need to be re-encoded and re-deployed to take advantage of HTML, after we figure out how to build an HTML5 video skin that will work for them including licensing. That's going to take time, which as we all know equals money. I don't know if you've noticed it lately? But we're in the middle of a recession, and I've heard they're having some cash flow issues. Now if they say, "How do we make this work for iPad users?" I have to say, "Open up your wallet".

To Sum Up ...

... As Dr. John Dorian would say. I'm split. I think it's not a great situation for anyone. A friend on Facebook's comment was as follows:

"Nobody said technology transitions were graceful. They're ugly and expensive and disruptive. But they're also inevitable. [sic]"

I would agree with that. Expensive for who is really the question. If it's expensive for Adobe? That's one thing. If it's expensive for my clients? That's another. I like making money, but I don't like giving people the impression that their feet are to the fire because Steve Jobs wants a sterile perfect little environment for his devices to live in. It's the Internet. It's a mess. It always has been, it always will be, and damn it that's why I love getting right in the middle of it and sorting it out.

I still say: I'm split. On the one hand it's probably good for the Internet in the long run, and I can't blame Apple on the basis of their tech reasoning. In the meantime it's going to be very expensive and a giant mess. And it's going to be people like me - not Steve Jobs - who are going to be in the cross hairs when someone gets upset about that expense.

Keep your tags closed, Kids. It's a jungle out there.