You fix it, you bought it

VUPEN said they found and successfully exploited a ‘zero-day’ (not previously known) vulnerability that defeated Chrome’s reputable ‘sandbox’ security model.

Google said Chrome was not hacked and was not vulnerable; instead, it was a problem with the Adobe Flash plugin, which is included with every Chrome install.

Gruber said, along with many others, that because Google bundles Flash with Chrome, even though Google did not write the insecure software (Flash) and cannot fix the insecure software (Flash), they still are responsible for the problem because they included it with Chrome.¹

Google engineer Chris Evans said the reason Google bundles Flash with Chrome is because most users already have Flash installed, but the version they have installed is, more often than not, an old and outdated version of Flash, presumably containing more security problems than the latest version. Therefore, even if the latest version has problems (or is likely to have problems in the future), bundling it is still likely to improve the situation for most people.

Let’s assume for the sake of argument that Evans’s explanation is Google’s motivation for bundling Flash².

People like me who have some semblance of knowledge about ‘computer stuff’ are familiar with the problem of helping relatives with their computer issues:

If you help them fix it, they’ll call you the next time it breaks again. And again. And again.

You can try to explain the reasons they got themselves into that mess: they clicked dodgy attachments, they installed smiley packs, or they simply continued to use a machine with Windows on it. But it won’t make any difference; by continuing to help them, you continue to enable their bad habits that continue to lead to problems, and they come to depend on you.

Google says that bundling Flash is better than doing nothing, but there is one other thing they could do:

Block Flash in Chrome by default.³ Move YouTube to HTML5. The world would follow.

(No, I don’t really expect this to happen anytime soon.)

Update 2011-05-25: I recently found out, completely by accident, that Chrome actually has a built-in option to do what I suggested; it’s just off by default. Here’s how to turn it on:

1. Navigate to about:flags
2. Find ‘Click to play’ on the page, and click ‘Enable’. Oddly, this does not actually enable the feature, it only enables another option which you can use to enable the feature.
3. Restart Chrome.
4. Open Preferences.⁴
5. Click ‘Under the Hood’.⁵
6. Click ‘Content Settings’.
7. Finally, next to Plug-Ins, select ‘Click to play’.

1. This reflects Gruber’s reasoning for why Apple has never included Flash on the iPhone or iPad, and no longer includes it on new Macs: it is beyond Apple’s power to fix when things go wrong; and Flash has a history of things going wrong, especially on their platform. ↩︎

2. And not, say, because it gives them a claimed competitive advantage in certain markets against a certain competitor who refuses to have anything to do with Flash as of late. ↩︎

3. It doesn’t even have to be as extreme as Apple’s prohibition. Simply putting the Flash content behind an overlay that says ‘click to display insecure content’ should do the trick. Most sites’ video content is already in h.264; they just need a little nudge. It’s sad how much the web depends on a plugin it doesn’t even need any more. ↩︎

4. Ttry explaining this part to a novice computer user over the phone. On the Mac, Preferences can be found in the usual place. On Windows, you have to explain what the ‘wrench’ icon is and where to find it. But then, nothing works the same way as anything else on Windows. ↩︎

5. Or if you’re using a Commonwealth English version, ‘Under the Bonnet’. Charming localisation. ↩︎

Folk Models of Home Computer Security (PDF)

Folk Models of Home Computer Security (PDF)

It’s always fascinating to me to learn about how ‘most people’ think about computers and technology.

If you find it too long, skip to section 2.1.

(Link is a PDF; here’s a Google HTML version.)

Apple hasn’t been any more specific about its plans for the facility, which one expert called “big-ass.”

Apple hasn’t been any more specific about its plans for the facility, which one expert called “big-ass.”

—Chris Foresman, for Ars Technica

How to merge Subversion branches with Git

Git-svn is good. It’s really good. As others have said, it’s actually too good, in that it reinforces the status quo (of continuing to use a Subversion repository regardless of the inherent issues) and the process of merging exemplifies this in a particularly insidious way.

It happens to many Git users that they are eventually forced to work with a Subversion repository. Fine, they’ll say, no problem. Just use Git-svn and you can do just about anything like you normally would in Git. Pushing to the repository will take longer, but oh well.

Then someone has to merge something.

Subversion users hate merging. It’s slow, it’s difficult, things go wrong and they have no idea why. They can read the docs cover to cover, they can Google it for hours, but they will never find out how to make it work right. They blame themselves, because it’s supposed to work, but they don’t know what to do. It’s just painful and they’ve resigned themselves to that fact.

But then you come along, and you have Git-svn. All other interoperation between Git and svn works so flawlessly, you just assume merging should work as well. So you do the merge in Git, it takes under a second and it looks like it worked fine. Problem solved?

Unfortunately, you probably never read the ‘caveats’ section in ‘git help svn’. Go ahead and read that now.
(Tip: git help -w svn)

But maybe you didn’t read it, or maybe you shrug and say, ‘eh, it seemed to work fine’, and you go ahead and ‘git svn dcommit’ the merge.

Basically: Git-svn supports reading Subversion merge metadata, but doesn’t support writing it. If you ‘git svn dcommit’ that merge, the Subversion server will receive all of the file changes but nothing to indicate it’s a merge. It will look like you made those changes all by yourself, in one commit. And of course, Subversion doesn’t support Git’s merge metadata either, so this isn’t even preserved for future Git-svn clones of the repository.

The result of this:

If you do a Git merge of Subversion repositories, you are the only one who can ever see that merge again.

(And even then, only if you keep that working copy of yours preserved forever). All other Subversion users and all other Git-svn users will not see this as a merge. And because of this, you have made future merges, annotations, history tracking, and many other things much more difficult for everyone else, whether they use Subversion or Git-svn. (In particular, it may make future merges with Subversion on that branch nearly impossible.)

This is why the safest thing to do, and what I always recommend to Git-svn users, is:

Never merge Subversion branches with Git.

Switch back to Subversion when you need to merge Subversion branches. Yes, it’s slow, painful and error-prone. This is your motivation to convince the organisation to switch to a sane SCM (remember, as much as Git seems like the best one, there are several alternatives that, if not as good as Git, would at least be an improvement). You can only do so much to work around a system that is fundamentally broken. If your organisation seems incapable of understanding this, it may be an indication that that organisation is also fundamentally broken, and you may wish to consider how much you can do to work around that.

However…

If you’re not going to heed my warning, and you’re determined to do it anyway, here’s how to do it while keeping the level of destruction you cause to a minimum.

Assume you’re merging a branch named ‘source’ into a branch named ‘target’. Open two Terminal windows (or tabs, whatever): one for Git, one for svn. The part before the $ indicates the line number and which Terminal you should type into.

It should go without saying that if you receive errors at any point (not counting conflicts, which you should resolve normally), and you don’t understand what’s going on, you should abort the process, undo whatever destruction you have caused and start over.

[01:git]$ git checkout target
[02:svn]$ svn checkout proto://url/to/target target
[03:svn]$ cd target
[04:git]$ git svn fetch
[05:git]$ git svn rebase -l
[06:git]$ git merge remotes/source # (resolve any conflicts)
[07:git]$ git commit --amend -m "Merge source - PARTIAL"
[08:git]$ git svn fetch # IF THE RESULT of this is that you received more commits, GOTO line 05
[09:git]$ git svn dcommit
[10:svn]$ svn up # IF THE RESULT of this is that you received more commits OTHER THAN YOUR MERGE(s), GOTO line 04
[11:svn]$ svn merge proto://url/to/source --record-only
[12:svn]$ svn commit -m "Merge source - COMPLETE"

The key here is the ’–record-only’ option to ‘svn merge’, which only sets the metadata and does nothing else. This should effectively repair the missing metadata caused by your Git-svn merge.

As you can see, this is a rather ridiculous amount of effort to do a merge. What’s more ridiculous, though, is that it may end up being drastically less time and effort than doing the merge with Subversion, due to all of the nonsensical conflicts that Subversion introduces, and/or simply the amount of time Subversion takes to do anything (I have literally sat watching Subversion churn through a merge of a few large commits for 30+ minutes, when Git did the same thing in less than one second).

The risk here (besides the possibility of you doing a step wrong), and the reason for all of the GOTOs, is that your merge is split across several commits, and while you’re committing them, other users may still be using the repository (especially while line 09 is executing, which can take a while). If the merge content from Git and the merge metadata from svn don’t agree, you have a big problem that will cause a lot of trouble for you. If possible, it is advisable to ask other users to stop committing while you’re doing this. If it is not possible to ask this, or if doing so would draw you ire, and indeed if you’re working with a high-traffic repository, my solution may be essentially impossible for you to complete (infinite loop).

An odd side effect that you may notice: your Git working copy will show the merge as having occurred at your first commit, but other Git-svn clones or Subversion clients will show it as having occurred at your last commit. This is probably a minor issue.

One last word of advice: Avoid doing people too many favours by doing their merges for them. You could end up becoming a de-facto Release Engineer, and that’s not a fun job.

Analysis of World of Goo’s iPad Launch by its creators

Analysis of World of Goo’s iPad Launch by its creators

An interesting look at the differences between iOS App Store and more traditional game software markets.

I believe that if you identify with any political group or philosophy that has a name, you are far more susceptible to confirmation bias than someone who doesn’t. And as a general rule, I don’t trust anyone with a strong opinion on a complicated topic.

I believe that if you identify with any political group or philosophy that has a name, you are far more susceptible to confirmation bias than someone who doesn’t. And as a general rule, I don’t trust anyone with a strong opinion on a complicated topic.

—Scott Adams

Thieves stealing debit card numbers via fake bank door locks

Thieves stealing debit card numbers via fake bank door locks

This is why I always swipe a card that isn’t a credit or debit card, such as a grocery store discount card, to open the bank door. I’ve tried this with dozens of branches of different banks over the years and it’s never failed to open the door.

I read about this trick on the internet many years ago (don’t remember where): the door lock doesn’t actually verify the authenticity of the card; it only checks that it has a readable magnetic strip. It doesn’t matter what kind of card it is. The door lock is only there to make you feel safer, or maybe to keep homeless people out; it doesn’t do anything to verify that you’re a customer of that bank.

A fake door lock could, however, steal the number you just swiped. This would be easy to plant since they’re often in a low-traffic, easily accessible location. But I’m not too worried about thieves stealing my discounts at the grocery store.

(via Schneier)

Adium's attempts to be in the Mac App Store

Adium’s attempts to be in the Mac App Store

Not going so well.

WikiLeaks is not the problem

WikiLeaks is not the problem

Bruce Schneier:

In the 1970s he would have mailed them to a newspaper. Today he uses WikiLeaks. Tomorrow he will have his choice of a dozen similar websites.

Schneier on Security: TSA Backscatter X-ray Backlash

Schneier on Security: TSA Backscatter X-ray Backlash

Good collection of links to what people are saying about the TSA lately. It’s good to see that this is getting so much attention.