Blog

Welcome to a new Apple-world device

So that’s it. The iPad is a small tablet you can carry with you. It has great applications, a great web browser, and the hardware is pretty nice… well I haven’t seen one myself but it looks great. All that at an unbelievably low price. What’s the catch?

Well, it’s a little computer on which you can only install Apple-approved apps, apps you must purchase through the Apple online App Store. No doubt they’ll make a lot of money with the App Store — perhaps that’s how they can afford to sell it at this price — but the point is that everything you buy through the App Store is locked to your specific iTunes account.

What if after some time of use you want to sell your iPad to someone else. That’s fine, you can give him the hardware. But how do you transfer the apps? Those apps are linked to your iTunes account, the same account you use to purchase music, videos, and iPhone apps. You can’t give that account to him, so you’re stuck with apps you can no longer use, nor sell.

As long as it was small, cheap, unessential throwaway apps like you probably have thousands on your iPhone then it doesn’t matter very much. But if you’re going to buy serious apps you’ll want to protect your investment by being able to transfer/sell it to someone else if the need arise. That day the App Store’s DRM will get in your way.

I would also argue, from a developer standpoint, that DRM diminish the value of an app. It’s simple really: DRM prevents your customers from doing things they’d be otherwise legally entitled to do. You could also argue that there’s some privacy implications about purchasing everything through the same outlet, but that’s another subject for another day…

So my conclusion is: I’m pretty sure the iPad will sell, but I’m not sure I want one given the current software ecosystem.

Update: Aristotle Pagaltzis summarize quite well my thought about Apple restricting what you can do with their device.

Magic Launch 1.0.1 for files with no extension

Some files don’t have extensions. On the Mac, in the absence of other type metadata, the system will always open such files with the application for plain text documents. But sometime you might want to use a more specialized one. Here’s how you can use Magic Launch 1.0.1 (today’s update) to assign a different application to files with no extension, such as the commonly encountered “Makefile” and “.htaccess” files.

If not already done, you’ll need to download and install Magic Launch. To install, just double-click the preference pane you downloaded: this will open System Preferences and ask for your permission to install it.

On the left side of the Magic Launch preference pane you have a list of file types. You can add file types by typing their extension, but in this case you’ll need to select the file yourself, as it does not have an extension. The easiest way is to drag a file from the Finder to the list box on the left.

When you drag a “Makefile” file, or most files with no extension, the type “.txt .text” will be added and become selected. That’s because the operating system uses the same application for text files and files with no extension¹.

On the right side you see the default application for the selected file type. If you change it there, it’ll apply to all files of this type. In our case, if you change the default application for “.txt .text” it will also apply to all files with no extension. That’s not exactly what we want however…

We want to change the default application only for files called “Makefile”. To that end, we add a rule. Click the “+” button below the list box on the right to make appear the rule editor.

Here we give a name to this rule, and select the application we want to open when it matches the file. Then, in the criteria editor below, opening the first pop-up menu on the second row reveals a list of options. Selecting “name” will allow you to complete the sentence with “is” “Makefile”:

We can now save the rule. It’ll match files named “Makefile” and open them in the specified application.

You should now be able to add another rule for files named “.htaccess” if you want. Note that “.htaccess” is a hidden file because it starts with a dot, so it might be hard to reach. Fortunately, there is a way to show hidden files in the Finder.

If you want to share your rule with a friend, drag it from the list box to your desktop, where it becomes a file. You can then drag it back to the Magic Launch preference pane on someone else’s computer.

Markdown and XSS

Cross-side scripting is a well known technique to gain access to private information of the users of a website. The attacker injects spurious HTML content (a script) on the web page which will read the user’s cookies and do something bad with it (like steal credentials). As a countermeasure, you should filter any suspicious content coming from user input. Markdown doesn’t include an XSS filter, so you must provide your own. But be careful in how you do it…

The basic rule is this: filter for XSS after Markdown has processed any input, not before. If you filter before, it’ll break some of Markdown’s features and will leave security holes. Also take note that even if you use PHP Markdown in no markup mode, where it strips HTML tags, you aren’t safe from XSS. Let me show you why.

Here is an example of mixed HTML/Markdown XSS attack. It’s a link containing a script (this script is innocuous, but a real attacker’s script will not be).

> hello <a name="n"
> href="javascript:alert('xss')">*you*</a>

Now, let’s say we’re wrongly applying an XSS filter before Markdown to filter bad HTML. The XSS filter, expecting HTML, will likely think the <a> tag ends with the first character on the second line and will leave the text snippet untouched. It’ll fail to see that the href="javascript:…" thing is part of the <a> element and leave it alone. But when Markdown converts this to HTML, you get this:

<blockquote>
 <p>hello <a name="n"
 href="javascript:alert('xss')"><em>you</em></a></p>
</blockquote>

After parsing with Markdown, the first > on the second line disappears because it is used as the blockquote marker in the Markdown blockquote syntax, and now you’ve got a link containing an XSS attack!

Did Markdown generate the HTML? No, the HTML was already in plain sight in the input. The XSS filter couldn’t catch it because the input doesn’t follow HTML’s rules: it’s a mix of Markdown and HTML and the filter doesn’t know a dime about Markdown.

As for why disallowing HTML markup within Markdown doesn’t solve the problem, consider this other attack vector using the Markdown syntax itself to create dangerous links:

[some text](javascript:alert('xss'))

Once the text is processed by Markdown, you get this:

<a href="javascript:alert('xss')">some text</a>

The XSS attack is still there! Markdown isn’t an XSS filter, it just makes a link from the URL you give it.

Again, if you apply the XSS filter before Markdown, it won’t filter anything as it’ll see the whole a plain text. But, most importantly, it shows that you need an XSS filter even if you have set Markdown to allow no markup, otherwise you risk javascript injection on your site.

So the conclusion is that, if you want real security, you need to filter Markdown’s output, not the input. There’s no other choice.

Note that if you’re using Wordpress, it is already using the kses XSS filter that should work correctly with PHP Markdown.

About LaunchCodes

Yeah, I know I’m not the first to create an application to restore opening files using creator codes in Snow Leopard. I’ve been beaten to it by the developer behind Pagehand who released LaunchCodes two weeks ago. This week I released my own: Magic Launch. It’s annoying really. So how did that happen?

Apparently we where two with the same basic idea: create an application to capture file open events from the system and launch the right application based on the creator code. Strange coincidence don’t you think? Not really.

It’s not a surprise for me to see Ross Carter from Pagehand do this: he had already created such a dispatcher in order to redirect PDF files to Pagehand but only those Pagehand could read. It was a simple matter of pushing the concept a little further, checking for creator codes, and find a way to configure everything.

For my part, it’s the same story. If you dig a little on my website you’ll find the source code for the D for Xcode Launcher (bundled inside D for Xcode), which is simply an application used to open D source files in Xcode at the time it didn’t handle files with the .d extension (.d as in D programming language, not to mix with DTrace).

My first prototypes were an adaptation of that code. But Magic Launch turned out to be a fresh start entirely. I rebuilt the launcher app with Cocoa so I could more easily add a rule evaluation engine. And I took a different route from the Ross: I decided it would make more sense to configure everything from a preference pane.

There was a very good reason to go for a preference pane, despite the increased complexity for me. For Magic Launch to work, it is essential to know which default application you set, but at the same time it is essential to change that setting so that Magic Launch’s agent application is used to open those files. And while it’s easy take note of what is the default application when you first enable Magic Launch, if you later want to change it via the Finder it’ll unfortunately disable Magic Launch for that file type. The solution is to change the default app though Magic Launch, which will then take care of the rest. To make this enjoyable I needed to offer the best interface I could, and that should be a preference pane. It turns out that Magic Launch is a pretty decent control panel to change the default application, even though that’s not the primary purpose.

In late december, when LaunchCodes appeared, I was working on my online payment system. That’s something Ross already had for his other application, so I guess this is what allowed him to release earlier. But I wasn’t too worried given that Magic Launch was ready too and that it had more polish and more features.

I didn’t act as nothing happened though. I added a warning message to Magic Launch that appears the first time it detects LaunchCodes to make users aware that both should not be active at the same time (or small problems will ensue). I also took notice of a shortcoming that Michael Tsai pointed out (see point 1) and fixed it in Magic Launch prior release. And LaunchCodes provided me with a solution to the uninstall problem: allow it to be deactivated to restore the default applications, and ask users to deactivate then uninstall.

I hope Magic Launch can prevail with its more natural interface and its additional features. Beside the customizable rules, there’s a few other tricks Magic Launch also does better than LaunchCodes 1.0: it preserves file icons and it pass along search queries to the target application (like when you open a PDF document in Preview from the Spotlight menu). And the rule system in Magic Launch offers many more possibilities that what you can do simply with creator codes, with many possibilities for growth in future versions.

I can’t help but feel a little bad for Ross: seeing an unexpected competitor appear with a superior product even before his first users reach the end of the 30-trial period isn’t something I’d hope for. But at least, his program is a little cheaper so it still stands a chance. That, and it’s not his only product. Ross, I wish you better luck with Pagehand.