Blizzard Entertainment, makers of the phenomenally-successful multiplayer game World of Warcraft, have introduced two-factor authentication for logging into the game.  For $6.50, they’ll sell you a dynamic password keychain token called the Blizzard Authenticator, which looks much like the RSA keyfobs many in the IT industry use to log into their corporate VPNs.

It may seem silly to use two-factor auth for a video game.  However, with 12 million players, World of Warcraft is a big business, and stolen accounts are worth money.  Logging into someone else’s account, looting it for virtual money and supplies, then selling them on the open market can easily net $50 per account, more for particularly lucrative ones.  What’s more, the account itself can be sold to offshore “gold farmers” who have a constant need for accounts as Blizzard revokes theirs for Terms of Service violations.  Considering that a stolen credit card number is usually worth only about $10, WoW accounts are actually pretty good targets for theft.

People steal these accounts via installing old-fashioned key loggers — Trojan Horses attached to downloaded software that monitor the user and steal their password when they log into WoW.  Generally these keyloggers are attached to fake WoW cheat programs with names like “WoW stat changer“, or modern recreations of some early real cheats that no longer work (the “speed hack” and “teleport hack.”)  Aspiring cheaters download and install these applications and are disappointed to find they don’t work, but don’t realize that their account has been stolen when the app was run.

The best mitigation to this would, of course, be not to download dubious cheat programs for World of Warcraft.  However, since downloading and installing UI add-ons is a normal activity by WoW players, it is perhaps a bit much to expect players to know the difference between a safe UI add-on (written in Blizzard’s LUA scripting language) and an unsafe one (with real executable code.)  So Blizzard offers a two-factor token, which renders a stolen password useless — since the dynamic passwords change every minute and are not reusable, keyloggers can no longer steal accounts.  If you’re a World of Warcraft player who downloads & runs a lot of not-very-trustworthy Internet software, $6.50 is a small price to pay for security.

The ironic thing about this is that most banks won’t offer this level of security to their customers.  The loss of my World of Warcraft account would be a minor inconvenience (Blizzard keeps backups, after all, and can “roll back” a player’s account to a previous state upon request), while the theft of bank accounts and credit cards would be much more serious.  Yet my bank offers only passwords for protection, and other banks’ “two-factor authentication” isn’t really (”something you know” and “something else you know” is not two factors, it’s one factor repeated twice.)  Banks usually cite cost as the reason, and at the $90 for an RSA token, that sounds reasonable — but if Blizzard can put out their own tokens at $6.50, banks could, too.  The real reason is that the banks do not want to inconvenience their customers by making them carry around an additional object for access to their accounts.  For the most part, customers care more about convenience than security, and many customers would be locked of their accounts by losing a token than would be saved from theft.  (For that matter, customers don’t even know it when their bank account isn’t stolen because of a security measure, so they have no perceived benefit at all.)

Blizzard’s answer to the convenience/security tradeoff is to give customers the option — you can get an Authenticator if you want one, or just use passwords otherwise.  Banks don’t want to do this, though, because it would make password-only customers feel insecure.  The availability of a token might make them realize how unsafe a password alone is, and they might decide to forgo online banking altogether.  This is the last thing banks want — online banking is much cheaper than tellers.

I don’t usually post about newly-discovered vulnerabilities, simply because there are so many of them — a dozen come out every day, especially in web applications.  However, this one has further-reaching consequences.  Security researcher HD Moore (of Metasploit fame) has discovered a vulnerability in the OpenSSL cryptographic random number generator used by Debian Linux, the widely-used distribution on which Ubuntu is based.  As I have discussed before, flaws in the RNG underlying a cryptosystem can compromise the entire system — both block ciphers and public-key systems rely on a source of entropy to create the large numbers they work with.  If the bits of entropy in this source is smaller than the key length, a “back door” is created — instead of cracking the key, you essentially “crack” the RNG, by trying all the possible seeds and seeing which one produces the key you need.

In this case, the result of this OpenSSL bug (an erroneous “bug fix” made in 2006) is to reduce the entropy in the seed to only 15 bits — a terribly small number (32,768) in cryptographic terms.  Moore was able to produce all the possible SSH keys that could be generated on this system in a matter of hours, save for those few people using 8192-bit RSA keys (and he’ll have those in a few days, too.  He’s placed them all on his website for download.

So what are the implications of this?  The most important one is SSH authorized keys.  SSH is the secure replacement for Telnet and FTP; security-conscious administrators and users use it instead of older protocols.  SSH has an option wherein instead of using a password to log in, you can save a set of keys in your user account, so that when you connect to another server the keys automatically authenticate you.  It’s quick, convenient, and generally more secure than passwords — and thus secures the most sensitive accounts (such as root) on almost all Linux-based servers.  With this exploit, it goes from being more secure than passwords to being much less secure — 32,768 guesses and you’re sure to get the right one.  This can be automated in a couple of hours if there is no lockout on the target machine (and the root account is normally not protected by a lockout since doing so means that an attacker can intentionally lock out the legitimate administrators.)  You could even use this as a local attack — log into your webhost account and run a script that will shortly give you root access to the server (from which you will have root access to most of the other servers at the hosting provider, too.)  Moore’s website includes a couple of scripts that can easily do this.

The nasty part about this is that keys are sticky.  Upgrading your Debian/Ubuntu servers to fix the bug is, of course, required.  However, also necessary is to replace every key generated on a Debian-based machine in the last two years (since 5/2/2006.)  It’s quite a task for administrators to even find all of those keys.  The first step is that if you use SSH to or from a Debian system, you need to immediately delete your authorized_keys and generate new sets (after applying the patch for this bug, of course.)  After that, it’s important to make sure all your users do the same.  Purging the SSH keys of all the users is not going to be a painless process and will undoubtedly involve some support cost, but keep in mind that not doing so is the equivalent of having all your users using 3-character lowercase alphabetic passwords.

The harder problem, though, is this: this bug isn’t really in SSH, it’s in the OpenSSL libraries.  These are commonly used by all sorts of apps to generate keys — OpenSSL is practically the Linux equivalent of CryptoAPI/DPAPI on Windows.  Everything uses them.  Essentially, every key generated on a Debian-based system for any purpose whatsoever in the last two years is potentially vulnerable.  You won’t be able to use HD Moore’s linked scripts to crack these, but they are all potentially cryptographically feasible now.  This is a major breach; if the NSA didn’t already know about this vulnerability (which I wouldn’t rule out), they’re no doubt engaging in a flurry of excited codebreaking right this minute.

Auren Hoffman at Summation has an interesting post on the “black hat tax.”  Essentially, how much do hackers and other online criminals actually cost us?  He estimates it at 25% of time and resources, after taking into account not just hackers but also scammers, phishers, and responding to law enforcement requests.  According to James Currier (who founded a good number of social-networking type sites, some of which are quite substantial), this “tax” is 25-40% for consumer Internet companies, with it being especially high in unexpected places (like online dating sites.)

That’s a lot of money.  More importantly, it’s a lot more money than most managers think we’re spending on security.

Now, the accuracy of these statistics is obviously dubious — even a respected and experienced person’s ad hoc estimate is still just an ad hoc estimate.  But it’s worth thinking about this for your company.  How much time and effort gets spent on problems that are, if not strictly security problems, problems you wouldn’t have were it not for malicious users?  This includes not just the things you do to defend your sites (firewalls, IDS, code reviews, etc.), incident response, and responding to subpoenas.  It also includes having to carefully write & test your emails to make sure they don’t get caught in spam filters, and setting up logging & auditing on your sites so you’ll be capable of responding to a subpoena if you get one in the future, and planning for regulatory compliance, and some of your disaster recovery & backup costs.  Consider not just purchases of security hardware & software and the hours of work by the security team, but also all the time consumed by product development and IT teams planning for or responding to security threats.

This “black hat tax” is your real security budget.  And importantly for security managers, this is a genuine, demonstrated cost, as opposed to the “risk” we spend most of our time talking about.  It’s one thing to say the company might suffer a $10 million loss in the case of a data breach, so we need to spend more on security.  Managers can go on believing that “it won’t happen to us.”  It’s quite another to say that the company already does lose $500,000 every year due to the cost of dealing with malicious users, and that we should spend that same money proactively, on planned security measures, rather than spending it reactively.  Don’t just think of your security budget as simply mitigating risk — think about what your company is already spending, just not on the security team.  Can you prevent some of that cost from being incurred?  Can you centralize some of these effors?  Security spending as a way to reduce cost, rather than as a cost center, may be a lot more appealing to your CIO.

A story in the New York Times tells us that Charter Communications (the United States’s fourth-largest cable company) is going to start tracking user behavior and using it to sell ads.  They spin this as a potential problem because of privacy implications — it means that the cable company is watching your web surfing so it knows what ads to show you.  While they say it will be anonymous (i.e. they only know that a specific tracking cookie is associated with one user, but not who the user is), when it comes to an ISP this simply isn’t true — they do know who you are (due to billing information) and if they were not-so-politely asked (i.e. with a subpoena) they would be able to associate your tracking cookie with you as the individual user.  As a matter of policy they don’t associate the tracking profiles with individual users’ personal information and share it with their advertising partner — but they have the data, which means law enforcement can have the data.

However, all the discussion about privacy in the article is, in my opinion, a secondary issue.  As I’ve discussed before, using an ad replacer has other effects that may be much more serious.  It means Charter is now mounting a man-in-the-middle attack on all its customers and editing the web pages they view.  Thus, if there are any security flaws in the NebuAd software (like, say, a cross-site scripting vulnerability as we saw with Barefruit in a previous post), they are now embedded in every web site viewed by every Charter customer.  When you’re a large ISP like Charter, this makes it worthwhile for hackers to try to attack the system — being able to steal the bank account passwords of every Charter customer at a given bank is almost as good as being able to do it to all customers of the bank.  It may only be 10% of people, but 10% of everyone is still a lot of people.  In addition, Charter customers are no longer contributing to the revenue of the web sites they visit (which could be interpreted as an attack on those websites by Charter — they just stole all their revenue.)  I don’t much expect Charter to care, nor their customers, but the more ad replacers that are out there, the less advertising is able to support web sites.

So, what to do if you’re a Charter customer?  Well, you can opt out of the tracking system by setting a cookie, which means the ads you’re served will not be targeted.  However, the ads probably will still be replaced, so you’re still not helping pay for the web sites you visit.  And chances are that Charter could still come up with a record of all your web surfing if they were served a subpoena.  If you want to avoid that, the only choice is using an encrypted tunnel and mix network like TOR (which law enforcement has probably at least partially compromised, but this puts them in a situation like the Allies after they broke the Enigma machine — if they use evidence from a TOR compromise to prosecute you, then they give away that they’ve compromised the network and criminals will stop using it.  Thus, you’d need to do something pretty serious for them to be willing to admit they know about it.)  And what to do if you’re an advertiser-supported website?  Not much.  You can lobby for net neutrality laws, or ban Charter customers outright (which will hurt you more than it hurts them.)  However, I would expect Google, DoubleClick, and other ad networks to start working on obfuscating their ads soon if more major ISPs embrace ad replacement.

According to the EFF blog, customs has taken to randomly searching electronic devices for suspicious data.  It is somewhat mysterious what they are searching them for — given only a few minutes and a technically unskilled border guard doing the searching, it’s hard to imagine them actually finding anything better hidden than a file on the desktop labeled “terroristic threats.doc” and a hyperlink to the Al-Qaeda Homepage.

Thus, from a security perspective, this just isn’t a good idea.  There’s a large tradeoff in inconvenience, delay, and civil liberties violation for a miniscule increase in security.  However, it does get me thinking about an interesting problem — how does one hide data from people inclined to search your electronic devices for it?

A legal search is a totally different kind of threat from a hacker attack.  With a hacker attack, you simply have to keep them out of the data — with a legal attack, you have to hide the existence of the data, as the legal system has at their disposal an additional channel for getting the data — they can subpoena it and demand you disable any protective measures and hand over the data.  Thus, encryption — the primary defense against data disclosure to hackers — is of limited use against a legal attack.  (And note that a “legal attack” doesn’t just mean law enforcement or other rightful authorities — it also means attack via lawsuit.  Abuse of the legal system is not limited to the political administration — competitors and other adversaries can and do use the legal system to get at things they shouldn’t have.  In other words, this information isn’t of value only to criminals — there are a lot of perfectly legitimate reasons to hide data.)

The EFF points out a few possible ways of avoiding scrutiny from customs:

• Create multiple accounts on the machine, and just log in with an account with nothing sensitive in it when asked to log in.  This is basically taking advantage of the lack of technical expertise on the part of the searcher.
• Take only the data you need on the trip — just minimize what there is to find.  This is a good idea anyway, but probably unsatisfactory if you are carrying, say, diplomatic communications.
• Bring no data at all, and when you arrive at your destination, retrieve the information via VPN.  Before flying back, VPN the data back and delete it.
• For sensitive business communications, have the data encrypted by someone else who provides the key only when you arrive at your destination.  This would work to protect the data, but it also means that, being unable to comply with an order to reveal the data, you may just have to miss your flight.

I have two more that they didn’t mention:

• Encrypt the data onto something that is not an “electronic device” subject to search, like a CD-ROM, USB key, or whatever.  It no longer falls under the search provision.  Obviously it could be searched if you were actually arrested or sued, but it gets around this particular issue.
• Use TrueCrypt Hidden Volumes.  Merely hiding an encrypted file on a disk will not hide it from a skilled attacker, because cryptographic data is distinctive.  Statistically, it has a uniform distribution, which makes it look unlike any other kind of data except white noise (random numbers.)  Essentially, it looks so bland and generic that it stands out — because no real data is that essentially devoid of information.  Since nobody keeps a hard disk full of random noise files, if one exists, it must be encrypted data — which means you can be subpoenaed for the key.  TrueCrypt’s hidden volume feature gets around this in a novel way, which I’ll discuss below.

Hidden volumes take advantage of the similarity between random noise & encrypted files.  A section of disk is reserved for an encrypted virtual disk.  When this is created, it is filled with random noise, which is replaced by encrypted data as needed.  The trick is that you can create another encrypted virtual disk inside the first one.  So long as some data is in the “outer” volume (as no one would have a huge encrypted file on their hard drive with nothing in it — it’s not plausible), there is no evidence that the “inner” volume even exists unless you have the key.  The inner volume’s encrypted data blends into the outer volume’s white noise.  Thus, you put slightly-secret data in the outer volume, and really-secret data in the inner volume.  When asked to reveal the key, you reveal the key to the outer volume only, and have plausible deniability of the inner volume’s existence.

As with any countermeasure, though, there are limits.  If you’re hiding from the NSA or some foreign government’s equivalent, just putting a couple TrueCrypt volumes on your laptop’s hard disk will not do the job.  The problem is that the operating system and the applications you use may leave traces that reveal the existence of the inner volume (e.g. Word’s file history notes that you opened a file on Drive F:, when your laptop doesn’t have an F:…)  For extremely sensitive data, it would be necessary to not only put it in a hidden inner volume, but also to only ever access that inner volume from an ephemeral operating system (e.g. a LiveCD, or an OS you boot off a USB key and load into a RAMdisk.)  If the OS you use never makes any changes to the disk outside the encrypted volume, evidence of the volume remains hidden.  You would of course want a normal OS and outer volume to be present and used, for plausible deniability to be present (as, once again, it’s not reasonable to have a laptop with only random noise on the hard drive.)  You would also want to access the outer volume with the laptop’s native OS after any session in which you accessed the inner volume (as otherwise the access date on the encrypted file could be newer than the last boot date on the OS, once again leaving a breadcrumb trail.)

And all this makes me wonder once again what the government plans to get out of casually searching the data on laptop hard disks.  The only people whose data will be discovered are those with nothing to hide.

I’ve talked before about ad replacers, where ISPs dynamically edit the contents of web traffic for their customers, replacing ads on web sites with ads of their own. This is a threat to the business model of the internet, as if done on a wide scale it would render small, advertiser-supported websites unable to support themselves. It’s also difficult to fight, as it’s a variation of the Times Square effect (the fact that in any movie that shows Times Square, all the ads have been replaced with ads from the movie’s sponsors) — companies do it because it makes money and they have no contractual obligation not to. About the only things that would stop it would be enough customers caring about it to make it a competitive advantage not to replace ads, or some sort of net neutrality law banning ad replacers. The former isn’t too likely, because by and large customers hate all ads equally, and couldn’t care less whose ads they’re seeing.

Dan Kaminsky, however, gives us another reason to oppose ad replacers in his latest presentation, which he gave last week at Toorcon 10. A bunch of ISPs (and I mean big ISPs — Comcast, Earthlink, Cox, Verizon, Quest) decided that rather than replacing ads in live pages, they’d go after something less controversial — typos. They set up their DNS servers to return ad servers run by a British company called Barefruit when a DNS lookup failed (rather than following the RFC and returning NXDOMAIN, the code for “no such domain.”) This is similar to what Verisign SiteFinder did a couple years ago (SiteFinder was taken down after a storm of bad publicity), but instead of affecting the entire Internet (VeriSign did this on the root domain name servers), it only affects customers of the specific ISPs doing it.

The result is that if you mistype “www.google.com” as “www.gogole.com” or somesuch (actually, gogole.com is registered to Google, too, but it’s just an example) on one of these ISPs, you get a “site not found” page from the Barefruit, filled with ads. Doesn’t seem too harmful — after all, you’re still getting the error message, and seeing some ads never hurt anybody.

Except for one problem. Dan Kaminsky found that the Barefruit page constructs the error message from an argument in the URL querystring (telling the server which site you were trying to hit, so it can say “Sorry, we couldn’t find an entry for www.gogole.com” or somesuch.) This is the classic cross-site scripting vulnerability — you can just toss in some JavaScript in that URL, and when someone clicks a link to the corrupt URL, the JavaScript will execute in their browser. Normally, this is bad — a site with an XSS vulnerability can be used to carry out phishing attacks, where users are sent a link to a site (say, a bank), but clicking the link executes the attacker’s script and steals their credentials to the site.

When it happens in this ad replacer that’s based on DNS voodoo, though, it’s not just bad — it’s catastrophic. The ad replacer page comes up for subdomains, too. Not only does a typo of Google send you to the Barefruit site, so does trying to go to this-domain-does-not-exist.perimetergrid.com. Since the Barefruit page comes up in response to a call to any bad subdomain, and the Barefruit page has a severe XSS vulnerability on it, this means that an attacker now has an XSS to work with on an arbitrary subdomain of every domain on the Internet. A really insidious, intelligent attacker (e.g. Dan Kaminsky) can do terrible things with this.

Luckily, Dan is a nice guy, and instead only did ridiculous things with them, crafting links to RickRolled versions of Facebook, MySpace, Apple, Microsoft, eBay, ToorCon, Fox News, etc. However, he could have just as easily crafted links to GMail, Hotmail, Chase, Bank of America, Fidelity, and eTrade that steal your credentials when you click on them.

The presentation slides do not make it obvious what exactly his script does (presumably because Dan explained that out loud during the presentation.) However, I can see from context how this attack works. The attacker writes a script to exploit a given site, and then creates a link to a nonexistent subdomain containing the script. They then send this out in a phishing email, or embed it in a hidden iFrame on a compromised site, and wait to receive credentials. Any user who clicks on the link:

http://evil-subdomain.gmail.com/index,html,aaa=bbb&ccc=ddd<script>[long evil script file here]</script>

gets sent to the Barefruit page, but with the attacker’s long evil script inserted into that page. That script then takes over:

1. The browser thinks that the script is running off of “evil-subdomain.gmail.com”, since that was the DNS query that (falsely) returned the Barefruit page.
2. The script sets document.domain to “gmail.com”. Since it is on a subdomain of gmail.com, this is allowed under the same-origin policy, and the browser lets it happen. The script is now permitted to script against gmail.com.
3. The script creates a frame that occupies the entire browser window (thus hiding the Barefruit page entirely) and loads the real gmail.com into the frame.
4. The script grabs document.cookie out of the frame. Since the frame is gmail.com, and document.domain is set to gmail.com, this is permitted. Document.cookie contains the user’s GMail credentials, or at least a session ID that will let the attacker in.
5. The script generates code to load a resource from the attacker’s malicious server, with the cookie contents in the resource value. Loading a resource (e.g. an <img src=…> tag) is allowed on other domains, without the same-origin policy applying.
6. That resource doesn’t exist on the malicious server’s pages, of course… but now the user’s cookie is in the attacker’s server logs where he can retrieve it at his leisure.

And what does the user see when this happens? Just a normal load of the GMail login page. And there’s nothing wrong with GMail in this example! It could be any site, including online banking, shopping, etc. There is nothing that the site — or the user — can do about it. Click a link or visit a malicious web page and the attacker steals your credentials to any site he wants.

All this is made possible because you’re on an ISP that is running an ad replacer, and that ad replacer contains a vulnerability. Using the ad replacers makes a simple cross-site scripting vulnerability into a full compromise of the entire Internet.

Are you on Comcast, Earthlink, Cox, Verizon, or Quest? They’re some of the biggest ISPs in the nation, so probably so. If so, be glad Dan Kaminsky found this simple, obvious XSS before some malicious hacker did, or that hacker could have been stealing credentials from half the Internet for months without detection.

“Without detection.” Yeah, maybe Dan wasn’t the first one to find this. We’ll never really know for sure.

This vulnerability is fixed now — it was very straightforward, and Barefruit fixed it within hours. But Barefruit isn’t the only ad replacer out there, and there will be more experiments like this in the future. Whether “net neutrality” becomes a law or not, it needs to be something we demand from our ISPs, or this won’t be the last internet-wide compromise we see.

HexView has an article about tracking vehicles with RFID tire pressure monitors. The devices are found in tires and transmit tire pressure to the engine control module, which sounds innocuous enough, but to prevent modules from reading neighboring cars’ tires by accident, they also transmit a unique ID. Thus, you can follow a car around town based on its ID, turning tire pressure monitors into tracking devices.

RFID devices are becoming more and more common, and this trend will continue — they’re too convenient for many purposes for the security risks around them to stop them. You may not want every consumer good you buy to be tagged with an ID that lets people watch your shopping from 100 yards away, but the scenario of being able to check out at the grocery store by instantaneously scanning every item in your cart simultaneously is too compelling for people to resist.

Bruce Schneier has a post on the ineffectiveness of security cameras, but while calling them ineffective it does note that criminals moved their crimes to somewhere the cameras couldn’t see. This may be “ineffective” for a government camera system designed to deter crime, but it’s precisely what privately-owned security cameras are meant to do — make a target unappealing so criminals go elsewhere. This actually shows that cameras do deter crime… but only where they can see it.

However, both of these technologies can have pernicious effects, too. The HexView article points out that you could use the RFID tire monitors to commit murder — set a bomb with a radio trigger that goes off when the “right” car drives over it. It would also be just as useful to private investigators spying on citizens as it is to law enforcement chasing down criminals. And speaking of law enforcement, these cameras create a dangerous imbalance in their favor — the camera evidence is all under their control, and thus can come up when needed to prove a perpetrator’s guilt yet be conveniently lost in cases of police brutality, abuse of power, corruption etc.

This is an interesting time for surveillance — police and government surveillance ability is skyrocketing (London is practically blanketed in cameras at this point, as the British seem much less uncomfortable with them than Americans are) but it is still largely in the hands of authority figures. This is dangerous because of how fast the change is coming — our criminal laws and sentencing structures are based on the principle that most criminals get away with it. A $75 fine for speeding seems pretty reasonable, but what if that fine were levied every time a car hit 1 mph over the speed limit? Most of us would get fined a dozen times a day, every day, despite not even meaning to speed, because our behaviors are based on the idea that we probably won’t get caught and that even if we are police are unlikely to punish us for very minor transgressions. If people were caught for speeding every time, and fined every time, a $75 fine would be absurd — the fine could probably be under $1 and still bring in a few hundred dollars a month from every citizen. What is the right legal structure here? I can see two possibilities:

• Raise the speed limits to the speeds we really think no one should exceed, and continue to fine every time.  Maybe you should get charged every time you exceed, say, 85 on a highway or 55 on a city street.  Set them high enough that there’s no leeway required.
• Leave the speed limits where they are but set the fine really low, say a $0.25 per minute of speeding.  This makes speeding discretionary — you can obey the law, or not, but if you choose not to you pay a penalty.  This is a fundamental change in the whole idea of crime and punishment, and itself has some pernicious consequences — it means that a certain income level can render you “above the law,” which is not a good thing.  Obviously some crimes (such as murder) should not be treated as discretionary, but for traffic violations it could make sense.

It’s not just traffic laws that are like this; consider the War on Drugs.  If every person who ever smoked marijuana went to prison, we would have a nation of felons — there’d be few people left who could vote, get security clearances, hold most jobs, etc.  The RIAA lawsuits against file-sharers are a good example of what happens when technology that catches everyone gets used to enforce laws designed under the assumption that only the worst and most flagrant criminals will be caught — people being hit by millions of dollars in fines for using technology to do something that wouldn’t even raise an eyelash if done by old, physical means (e.g. posting a song on BitTorrent vs. handing it to a friend on a cassette tape.)

A surveillance society needs a different kind of jurisprudence — one that sets punishments that fit the crime even if applied every time.  On the bright side, actually doing this would lower crime rates tremendously due to the psychology of criminals.  Escalating punishments does little to deter crime because criminals are risk-seekers — they do not expect to get caught.   Even a small punishment can be a strong deterrent if applied every time — if criminals are usually caught, such that all criminals have some first-hand experience with being caught and punished, it would break this idea.  On the not so bright side, a surveillance society must have very liberal laws to avoid being a police state — our current legal system, applied to everyone every time, would result in tyranny.  We all break 10 laws a day, it’s only sloppy enforcement that allows us to live our lives.  Unfortunately, the technology for ubiquitous enforcement will come well before the legal system changes to make it livable do.

What’s interesting to me is what will happen when surveillance becomes even more common: that is, when it is no longer monopolized by authority.  This has already started with cellular phones.   Almost everyone carries around a device which, while primarily for communication, contains a camera and often a voice recorder and videocamera as well.  Everyone is equipped to carry out impromptu surveillance at any time.  Devices like these glasses from ThinkGeek (found via BoingBoing) coupled with the rapidly falling cost of storage capacity will change this to everyone actually carrying out impromptu surveillance all the time.  This will have a chilling effect on human behavior at first — would you act differently if you knew everyone around you was videotaping everything you did?  Everything you say will, indeed, be able to be used against you, and not just in a court of law.  However, look at what young people put on MySpace and Facebook these days — the next generation does not have the assumption of privacy.  They’ve grown up in a world where they know everything goes on a permanent record, and have simply accepted it.  Sure, they’ll be occasionally shocked by it (e.g. the first time their party photos on MySpace disqualify them from a job), but the knowledge of permanence has not stopped them from sharing themselves, and eventually the rest of us will adjust, too.

Consider what the democratization of surveillance does to government power.  When we’re all recording, someone is watching the watchers.  Corruption, abuse of power, etc. all rely on the fact that authority figures can get away with crimes because they are more reliable witnesses in court than their victims are.  When everything is on the record — and not just the official record, but everyone’s record — police and government officials become compelled to act within the law.  While this may not be much of an impediment in truly totalitarian societies like China where the courts are as corrupt as everyone else, it’s a very strong bulwark of freedom in any society with an independent judiciary and a liberal tradition like the Untied States and Europe.  This is the next generation of surveillance — everyone sucking in light and sound from their glasses, or lapel pens, or even contact lenses, recording every moment of their lives on multi-terabyte devices that fit in their pockets.  It’s probably only 5-7 years away, and it washes away the current problems of a surveillance society and replaces them with new ones.

I think this cycle will continue for some time.  After all, once we’re past the era of democratized surveillance, computer graphics and artificial intelligence technology will improve to the point that ordinary people can modify their recordings to create perfect video of events that never happened, indistinguishable from the real thing.  What happens to recordings in law courts then, when they cease to be reliable evidence and become hearsay?  Tapes will become the new eyewitnesses, known to be unreliable and requiring corroboration from others.  When it becomes truly easy to make forged video, perhaps we will have emerged from the surveillance society from the other side — why bother to record anything when there’s no way to tell if it’s real?  Sometimes the only way out is through.

Microsoft gets a lot of criticism over Internet Explorer not being “standards-compliant.” However, it’s actually not so simple, for a variety of reasons. One of them is that the web itself is not very standards-compliant — while IE8 has a standards-compliant-browser mode, it has to offer an IE7 rendering fallback mode because most web sites don’t render properly if you strictly interpret XHTML. (Opera and Firefox violate the standards in the same way for the same reason.)

However, another is that sometimes doing things the “right” way can be bad for security. To prevent cross-site scripting attacks, many websites implement a blacklist — they search for specific “bad” data and refuse to show it. Others are behind a protective appliance that filters out “bad” data and eliminates it before it even reaches the web server. This is not the proper way to do this — you should allow a whitelist of good data, not look for badness, which comes in many forms — but it is nevertheless common. This process will, however, filter out obvious attacks, like a user putting this into a message post:

<script>alert(”This is some script!”);</script>

However, it’s not so likely to catch, say, this:

¼óãòéðô¾áìåòô¨¢Ôèéó éó óïíå ïâæõóãáôåä óãòéðô¡¢©»¼¯óãòéðô¾

So, what the heck is that? Actually, it’s the same script in 7-bit ASCII, but the high-order bit of each byte is set, making it a different character. If you were running a blacklist checking for, say, <script> tags, this would sail right through. Likewise, a filtering appliance will not see anything wrong with this.

However, if this is displayed on a web page with the encoding set to US-ASCII, (e.g. a page with <meta http-equiv=content-type content=’text/html; charset=us-ascii’> on it, which an attacker may also be able to inject given the right circumstances) Internet Explorer will render it properly, causing the script to execute! Other browsers, however, will be safe due to their non-standards-compliance. They don’t render 7-bit ASCII properly, instead taking the presence of an 8th bit to indicate that you really “meant” UTF-8, and thus show only the gibberish characters above.

Standards compliance is not an unalloyed good — the standards are documents on paper, and don’t always consider their own security implications. They were written to tell people how to do things, not how not to do them. Real browser behavior is based on a combination of standards and precedent. There are few real-world reasons why rendering US-ASCII as US-ASCII and not ISO-8859-1 is important — on non-malicious pages, you should get basically the same output. However, trying to do the “right” thing can open up a security vulnerability. Due to this and the compatibility issues, I think that Microsoft’s attempt to make IE8 the first standards-compliant browser is not actually going to work out — my guess is that when it comes time to release it, they’ll make the IE7-like rendering mode the default, with standards-compliant mode only an option.

So, as a web developer, how can you defend against attacks like the above? You could look for “<script>” encoded in US-ASCII, but there are dozens of other encodings out there, and as RSnake’s XSS Cheat-Sheet shows, there are dozens of bad things you can encode in them. What you instead have to do is use regular expressions to allow only a limited subset of good user input. For fields like ZIP code, this is easy (allow numbers only, and the - character if you want ZIP+4), but with general message posts, it can be harder. Letters, numbers, common punctuation marks, spaces, and carriage returns may be enough. If you need to use HTML tags, it’s best to go in multiple passes — match the tags you want to allow (like bold and italics) and replace them with a custom marker, then HTML Encode the entire message, and then finally replace the custom markers with allowed (unencoded) tags. It’s still not 100% effective in all cases, but it’s a lot safer than any blacklist can be.

The Today Show has a cover story today entitled “Mom lets 9-year-old take subway home alone.” The controversy over this — that is, the fact that there is any — is a wonderful example of how poorly people assess risk in modern society. What this woman, Lenore Skenazy, has done to stir up trouble is to make a decision about her child based on reason rather than emotion (specifically fear) — something that seems frighteningly uncommon today. As she puts it:

“It’s safe to go on the subway,” Skenazy replied. “It’s safe to be a kid. It’s safe to ride your bike on the streets. We’re brainwashed because of all the stories we hear that it isn’t safe. But those are the exceptions. That’s why they make it to the news. This is like, ‘Boy boils egg.’ He did something that any 9-year-old could do.”

She’s right. Most of us in our 30’s today remember growing up in the 1980’s — and it involved riding your bike across town, visiting neighbors, and being unattended for relatively long periods of time. Of course there were unsafe areas – there were parts of cities where people alone really aren’t safe — but these are the exceptions rather than the rule. Today, most parents seem to live in fear, convinced that there are criminals lying in wait to abduct children everywhere. It simply isn’t the case — it never has been, and crime rates are lower today than they were in the 80’s! We have not gotten any less safe, we have simply become so afraid that we think we’re less safe. And this culture of fear is damaging and contagious:

“Half the people I’ve told this episode to now want to turn me in for child abuse. As if keeping kids under lock and key and helmet and cell phone and nanny and surveillance is the right way to rear kids. It’s not. It’s debilitating — for us and for them.”

There are a variety of reasons that people believe that their children are under constant threat. Among them are:

• Vividness criterion: shocking anecdotes stick in our memory more than statistics, and they attract our attention. This is both why the media reports on every bad thing happening to a child, and why we remember them.
• Availability bias: when determining how frequently something happens, rather than turning to statistics we turn to how many cases of it we can remember. Since the news reports on every plane crash, but almost no auto accidents, we think of air travel as riskier even though we know the statistics show differently. Since in this age of pervasive news reporting we hear about crime more often, crime must be more common, even though the statistics show differently.
• Fundamental attribution error: when something happens, we tend to overestimate behavioral causes. So when a child is hurt, we assume the parents did something wrong, even if the event is random and exceedingly rare.
• We overestimate risks from intentional causes and underestimate risks from natural causes. This is probably related to the vividness criterion — someone deliberately hurting a child is more shocking than the child being hurt in a bike accident. The result is that we expect people to be malicious a lot more often than they are, and we think children are more likely to be hurt by criminals than by illness or car accident, once again despite statistics showing otherwise.

In truth, the violent crime rate today in the United States is less than half of what it was in the 1980’s! Most of our burgeoning prison population consists of nonviolent drug offenders, and most violent crime occurs in geographically delimited areas. Skenazy is right — the streets and subways of New York City are as safe as they were in 1963. Crime against children is even lower — the simple fact is that the overwhelming majority of humanity doesn’t want to hurt kids and is inclined to help and protect them.

It’s sad how many normal childhood experiences have been lost to this obsession with safety from small risks — just try to buy a chemistry set today even as an adult and compare it with what was available to young children 20 years ago (or to what’s in The Golden Book of Chemistry Experiments, now available pretty much only via BitTorrent, which begins by teaching children to use an alcohol burner to shape glass tubing. Today, a children’s chemistry set would never be allowed to contain an alcohol burner… or glass tubing.)

The key is this:

‘The statistics show that this is an incredibly rare event, and you can’t protect people from very rare events. It would be like trying to create a shield against being struck by lightning.’ ”

She said that people ask her how she would feel if one of those terrible and rare events happened to her son. “It would be horrible,” she said. “But you can’t live your life that way; you could slip in the shower.”

When faced by extremely low risks, the rational response is sometimes to disregard them. Sometimes the response to fear of something is, in aggregate, worse than the thing itself. We of course do the same thing with terrorism, and these same biases cause us to misallocate security dollars in industry, too (how many companies have tens of thousands of dollars in firewall and IDS hardware, but no disaster recovery plan?)

A company named Phorm (formerly 121Media) has introduced a new product for ISPs.  The idea is that the ISP installs this product (basically a transparent proxy) on their network, and as their customers surf the web, the OIX  proxy replaces advertisements on web pages with advertisements on the Phorm network.  To make it more palatable, they also provide some minor anti-phishing services (the sort of thing that’s built into IE7 anyway.)

They make a big deal out of their privacy practices.  They do not maintain histories on browsers the way Google does — they just replace ads on pages based on the page’s content, kind of like Google AdSense but for image and rich-content ads as well.   Customers, unsurprisingly, don’t really care either way about this service — what’s it matter if I get CNN’s own banner ads on their pages or my ISP’s banner ads?  They’re still ads, and nobody likes them, but whose ads they are isn’t high on a consumer’s priority list.

However, products like this (generically called “ad replacers”) are going to be extremely important to the future of the Internet.  The linked article talks about how ISPs’ profit margins are narrow given their customers’ increasing appetites for bandwidth, and how this advertising revenue will help them recover.  What it doesn’t mention, though, is where this revenue comes from – it’s the ad revenue that would otherwise be given to the sites you browse.

In other words, ubiquitous use of ad replacers would boost ISP revenue while destroying ad revenue paid to web sites.  This is a tremendous threat to Google as it eliminates their sole revenue stream!  For that matter, if an ad replacer can substitute ads, why not substitute the first page of Google search results?  Google won’t sell you #1 placement in organic search… but with an ad replacer, Comcast (for example) could sell you #1 placement on Google for Comcast users.  In addition, all the small niche websites that currently pay their hosting bill (and their owners’ salaries) off of advertising revenue may find themselves unable to do so.  People hate advertising, but what happens to the Internet without it?  The free, ad-supported Internet goes away, replaced with paid, subscription-based walled gardens.  Nobody wants that, but that’s the world ad replacers lead to — and ironically, it’s a world that has no room for them, as they would then have no ads to replace.  This is difficult to fight economically, though — an ad replacer can be a tremendous source of revenue so long as there aren’t many of them.  There’s lots of incentive to make them, even though in the long run they kill the ecosystem.

What this will lead to is a new security arms race.  Publishers will have to start finding ways to “hide” ads in their pages, so that ad replacers do not recognize that they’re ads and replace them.  This will be particularly hard for the large ad networks like Google’s where the ads must be embedded in thousands of dissimilar web pages.  As the publishers come up with better ways to hide ads, the ad replacers will be updated to find them.  The result is likely to be quite a mess, and result in neither the ISPs nor the publishers getting as much revenue as they’d like.  In addition, while Phorm may promise not to build up profiles of private information on you, an ISP who did engage in Google-like privacy invasion would be able to do it far better than Google can — after all, they have all your billing info since you’re a paying customer.  Unlike Google, they really do know who you are, personally, and not just by your browsing habits.

In the long run, international backbone providers could even start replacing ads in order to avoid local legislation, though this would lead to the ridiculous situation of the same ad on a page possibly being replaced several times on its way to the user.  I don’t see any solution to this other than legislation — the same sort of “net neutrality” laws  that forbid content-based traffic shaping or Comcast-like protocol tampering could also forbid ad replacers.  Unfortunately, economic incentives aren’t likely to have much effect, since the actual end users won’t change ISPs to go to one that promises not to run ad replacers — as only the publishers, not the end users, care whose ads are seen.