The problems with the Nitesh Dhanjani (ND) blog post about handling URL schemes in Apple’s IOS appear legion to me but I will try to summarize:

ND is worried that, based on an external URL, an application that starts a very noticeable process without prompting for authorization first, could do something bad. Nothing bad seems to happen, however. Actually something good happens. But ND is still worried and he wants Apple to make changes for him.

Allow me to put this in the form of a question:

As a mobile user, do you want your device to prompt you every single time you use an application? Would that make you feel safer? ND would feel safer. I quickly would feel annoyed that my phone has zero trust of sites and is always begging for authorization.

Personally, I do not want to be prompted every time, especially if the application in question is going to start a very noticeable process that can be easily canceled when it starts. There is no clear risk here and a clear downside to the user experience.

Allow me to put this in the form of an analogy:

Road blocks. ND is proposing that road blocks be setup on every street corner because authorization is important to help prevent all kinds of theoretical bad things. Do you like road blocks on your streets? Do you feel they are justified when there is no clear danger without them?

In security management this is not always a good model. It can make users frustrated and highly motivated to break things. ND obviously prefers this model. He has complained to Apple before about the need for more authorization steps when browsing, as found in his 2008 “carpet bomb” advisory, which Apple also ignored.

He argues that lack of prompts for authorization is an iOS failure. However, assuming we accept it is a problem at all, we really should focus on why an application decided not to prompt for authorization. Apple apparently tried to tell him the same thing, but ND was not totally convinced.

I contacted Apple’s security team to discuss this behavior, and their stance is that the onus is on the third-party applications (such as Skype in this case) to ask the user for authorization before performing the transaction. I also contacted Skype about this issue, but I have not heard back from them.

I do agree with Apple that third-party applications should also take part in ensuring authorization from the user, yet their stance leaves the following concerns unaddressed.

His first concern is…brace yourself…that the user can clearly see when an application handles the external URL. He puts it like this:

[A website can] yank the user out of the Safari browser. Since applications on iOS run in full-screen mode, this can be an annoying and jarring experience for the user.

First ND wants us to believe that something sneaky is happening, and then he calls it an “annoying and jarring” experience. More to the point, how would an “annoying and jarring” experience be made better by adding an annoying and jarring authorization pop-up? We clearly have different ideas about mobile use and how to measure security. I would wager he would want a world full of road blocks, because he could stop and personally thank every one for the good job it is doing. I would want a world where I could get to my destination safely with as few unnecessary roadblocks as possible.

Since the application has to start in full view of the user, the risk of unauthenticated attacks is very low at best. If you do not want to be “yanked”, cancel the process and exit the app.

Of course you might say the attack may already start by the time the app has loaded and given back control to the user. Bad things in theory could have happened by the time that the user is allowed to hit cancel or exit.

I am open to suggestion here but right now my response to this is to take a closer look at the horrible “abuse case” that has been presented by ND.

The Skype application is loaded and initiates a phone call, with a giant “end call” button.

So the application has started, it processes the URL, which tells it to initiate a call, and the user can cancel the call. Should Skype add another step that asks “Do you want to make this call?”. It looks like a usability question to me more than a security one.

I imagine a user actively using a browser with their finger on the screen and then all of a sudden Skype loads and they are right there…looking at a cancel button that they can press immediately.

Skype was probably right in making this usability decision. A user that does not want to make the call will cancel the call using the cancel call button. A user that wants to make the call will…make the call. How convenient.

Maybe there is another example of bad things that can happen, but ND gives us only a link to URL Schemes. Instead of showing any real risk, he says that Apple’s decision on handling URLs proves the risk.

The most logical explanation for [Apple’s Safari] behavior is that Apple is concerned about their customers’ security and doesn’t want rogue websites from being able to place arbitrary phone calls using the customer’s device.

However, since the Skype application allows for such an abuse case to succeed…

Hopefully you can see why I do not call it an abuse case. I do not accept that Apple’s behavior alone proves that Skype is insecure.

Here is another plausible and logical explanation for Apple’s behavior — Apple does not make its money from calls and their developers use iOS primarily on networks for network applications. Therefore, they put in an extra step just to confirm that they really want to switch to the awkward phone features of their device.

Skype, on the other hand, is all about making calls. Their developers are loathe to put in an extra step to get in the way of doing the thing that their application is supposed to be doing…mistakes are what the giant red cancel button is for. This is a security model that allows things to happen but also gives an opt out to reduce risk. It is similar to the thought that it is better to have good brakes on a car than road blocks with speed checkpoints on every road.

In conclusion, I agree with ND when he says developers need to realize that users may not have authorized every invocation of a URL handler (external start of an application). Controls should be in place for when this happens. Canceling a call after it has started is a sufficient control in the example given.

I disagree with the idea that authorization on the front-end of an application is the one and only possible solution. Some external URLs have to be trusted. Look at what Safari does, for example, it loads URLs. Why doesn’t ND propose that Safari ask the user for authorization before it loads each URL? Ha ha. Oh, wait, ND would probably say he done that already.

I also disagree that Apple should audit applications to behave the same as theirs. Applications have different security models and the use/need of authorization is not universally understood by Apple.

And I disagree that Apple should step in the way of applications and regulate URL handling. I install Opera or another browser and then the responsibility shifts? Should Opera also be expected to “throw an authorization request prior to yanking the user away”? It becomes a browser issue rather than iOS. If there were some example ND could come up with of significant risk, perhaps I would go along with this, but so far I only have the Skype example, and that works fine.

The ideal solution, since ND and I probably will end up having to agree to disagree, is to present a configuration option. Apple could allow their device to be configured two ways: to always force authorization or to leave it as it is today. An additional option could be more granular by giving a “remember my preference” for each application. Then low-risk applications would not be blocked unless you really want them to be blocked.

ND also tried to say we now all depend on iOS so there is urgency to this issue, but this reminds me of my earlier posts that the iPhone is still far behind in the mobile market and losing. I’ll just leave that topic alone.

The latest development of multi-hulls for the US Navy called the Littoral Combat Ship (LCS) has some interesting parallels to recreational boating.

The US Navy, after the end of the cold war, moved from preparing for open ocean confrontations with a major navy to rapid engagement near land to support operations against “asymmetric” opposition. We have seen some of this already in Somalia, where special forces in small helicopters stage reconnaissance as well as surgical strikes on enemy land convoys.

A white paper by the Secretary of the Navy in 1992 called “From the Sea” defined the scope of “littoral” combat:

Operating forward means operating in the littoral or “near land” areas of the world. As a general concept, we can define the littoral as comprising two segments of the battlespace:

* Seaward: The area from the open ocean to the shore which must be controlled to support operations ashore.
* Landward: The area inland from shore that can be supported and defended directly from the sea.

The littoral region is frequently characterized by confined and congested water and air space occupied by friends, adversaries, and neutrals–making identification profoundly difficult. This environment poses varying technical and tactical challenges to Naval Forces. It is an area where our adversaries can concentrate and layer their defenses. In an era when arms proliferation means some third world countries possess sophisticated weaponry, there is a wide range of potential challenges.

This explains how the LCS design had to depart from prior designs in the Navy. It sails extremely fast but also has to be maneuverable; it can complete a 45knt turn in only 4.6 ship lengths. A one ship length turn can be done at 7knts. It accelerates to 45knts in less than 2 minutes and stops from 30knts in two ship lengths. Even with these performance numbers it still carries sophisticated and heavy arms as well as attack helicopters and small rigid hull inflatables.

A hull design suited for shallow water, a small crew and an open space for modularity further distances it from old warships. Although it sails the open ocean the main value will be achieved navigating around harbors, major rivers and near shoreline.

What does this have to do with recreational boating? Multi-hulls are pushing along the same performance/cost and complexity formula. Why sail a million dollar 52-ft “sled” with ten crew or even a million dollar 40-ft “turbo” with seven when you can get twice the performance with a quarter-million dollar 30-ft trimaran and less than half the crew.

The polar chart below shows speed in 10knts of wind at various angles.

This video shows what performance (capability per dollar) can look like these days:

While a trimaran built for fun provides speed, a shallow draft and a wide berth in the main hull for storage like an LCS, it also has a major downside. Compared to a monohull if it capsizes the crew will be unable to right the boat again and continue sailing. That should not be too much of a problem as these boats, while seaworthy, are meant to be raced “littoraly” (near shore).