Category: Uncategorized

Part 5 of my SimCity 4 series is up on YouTube.

 

Now available: part 4 of the Cityville construction project with SimCity 4.

Here’s part 3 of the Cityville construction series.

Here’s part 2 of my series of videos showing the construction of Cityville in SimCity 4. Enjoy. Or not.

A while back, Haljackey posted a series called “Building a City from Scratch” on Youtube. It was exactly what it sounds like. He showed the entire process of filling a large city tile in SimCity 4 in real time modulo one or two technical glitches where screen capturing failed, etc. If you’re at all into SimCity 4, it’s quite amusing to watch him struggle through the building process.

Now I’ve decided to do a similar series of videos. My play style is different and my basic goals are a bit different. Where Haljackey employed various cheats to build large tracts of his city all at once at an urban level of density, I chose to grow the city from the bottom up without any money cheats.

Haljackey’s series ran for 100 parts. I don’t expect this one will be that long, but who knows?

Fair warning: this is in real time. That means no monkeying with the playback speed.

Without further ado, part 1:

In light of this recent announcement from the Chrome developers, I decided to comment on the situation. Basically, there has been something of a drive over the past few years to switch the entire web to use SSL everywhere. This is an absurd goal. I will elaborate on why shortly. The Chrome plan is that non-SSL pages always be marked as insecure rather than the situation now where an SSL page that references non-SSL resources is marked as such, or an SSL page that has a dubious certificate for some value of “dubious”.

The Case for SSL Everywhere

There is a case to be made for having every web site use SSL. It does afford some level of protection from snooping if your traffic happens to pass through some network element that allows traffic to be viewed (non-switched ethernet, wifi, proxy, etc.). It also theoretically gives some level of identity verification. It also has the potential advantage that the communcation cannot be proxied if the browsers and servers implement SSL and certificates properly.

The Case against SSL Everywhere

That all seems helpful on the surface. There are, however, some problems with the idea, and these outweigh the potential benefits.

First, to run an SSL site, one must have a certificate. In this age of sub $5 monthly hosting fees, having to obtain an SSL certificate pretty much doubles the cost of running a web site. That doesn’t include the hassle of obtaining the certificate in the first place. To do this right, every web site operator must deal with this directly rather than outsourcing this to their providers. The reason for this is the theoretically identity verification. A basic SSL certificate can run anywhere from about $75/year and up. You should be skeptical of the cheaper ones and certainly of the free ones because the browsers may not have the auhority certificate in their certificate bundle and will thus whine about the certificate not being trusted. Self-signed certificates also run into the same problem with browsers whining about trust.

Second, for maximum compatibility, you must have a dedicated IP address for your web site in order to use SSL. That is because the SSL negotiation and session setup happens before the HTTP protocol even starts up. That means that unlike non-SSL HTTP which can multiple many web sites on a single IP address, using SSL means that every web site requires its own IP address. Until IPv6 finally gets enough traction that IPv4 can be neglected, this simply cannot happen. (There are not enough IPv4 addresses in the entire address space to handle every single web site out there having a dedicated address once you consider that the users have to have addresses too.) There are some virtual hosting technologies which theoretically allow multiple SSL sites on a single IP address but these haven’t had significant penetration and it’s not clear that they are necessarily the right solution.

Third, the encryption and negotiation adds non-trivial overhead to every web page request. HTTP is already a verbose protocol with measurable overhead. Add in the non-trivial computation required to handle encryption, the need to transfer certificate and key information, and other additional protocol framing overhead, and you begin to add measurable overhead to every request. In this age of AJAX, a single web page can generate hundreds or even thousands of requests to the server. Every one of these requests will have the SSL framing overhead, and if persistent connections cannot be used, the session startup overhead, too. This does not seem like a significant problem to most because they tend to run maybe a handful of related sites on a single server which usually has significant resources to spare. For the web hosting operation with potentially thousands of unrelated sites on a single server, this becomes measurable. The resources used are more than just the CPU resources, though. The aggregate increase in bandwidth usage is also measurable. (A similar result happens for large sites with dedicated hosting, especially if they do not use a content delivery network.)

Finally, most web sites do not need any level of security at all. Period. This blog, for instance, does nothing that is actually security sensitive. Sure, I log in to the site over HTTP. But I am the only user that does. Even if you did create an account here, I do not collect sensitive information and you do not need an account to view the site. This is a public site publishing information publicly.  I do not handle payments over the web. I do not run an authentication service. My site has absolutely no need for SSL. Period. Adding SSL to the site would incur higher hosting fees, require a certificate (more fees), and would increase the maintenance burden because I would then have to deal with certificate renewals, etc.

Why Security Warnings on Non-SSL Are Dumb

The last point against SSL everywhere is really the main point here too. If the majority of sites see no real benefit from using SSL, then there is no impetus to adopt it. If the vast majority of sites do not adopt SSL, then showing a warning on non-SSL simple adds to the noise. People will become accustomed to ignoring the warning icon and the status quo will continue, but with less real information available to those who do care.

The fun thing here is that there used to be an obvious signal that SSL was not in use on a web site. Web browsers used to show the entire URL in the address bar when displaying a page. Now that they abbreviate the http:// part out of the URL, that signal is no longer present so now they feel the need to overload another signal to do so. Had the web browser makers not insisted on making the interface “easier”, we would not have this problem. It would be clear to anyone who actually cares that things are not secure.

Finally, given that most users don’t understand security at all, having a warning about non-SSL is just going to confuse them and they will ignore it anyway because they have to see their pictures of kitties eating cheeseburgers or whatever it is.

Closing Remarks

In summary, this plan from the Chrome developers is misguided. It is sufficient that the major web sites people use (Facebook, Twitter, Gmail, MSN, etc.) which do deal in sensitive information enable SSL. Vanity blogs simply don’t need it. For sites that do enable SSL, the existing browser warnings are sufficient to identify dumbness.

If enabling SSL everywhere really had real tangible benefits that outweigh the hassle and cost, it would be happening without help. It is not. If the problem is simply that the operators do not know what the benefits are, then the solution is education, not bludgeoning with spurious warning. With proper education, if the benefits sufficiently outweigh the drawbacks, change will happen without employing blunt instruments. Given that major hosting companies haven’t made the switch in this direction, it seems that is unlikely to happen in this case.

I sincerely hope this plan from the Chrome developers never moves past Chrome and is derided by the other browser makers as misguided. Should a time come when web sites really are primarily delivered using SSL, then such a plan starts to look sensible. Until such time, it should be derided as the dumb idea it is.

 

My latest drivelapse video is up. This time, I took a drive along Powderface Trail out in Kananaskis. It was severely damaged during the 2013 floods and you can easily see the legacy of that damage along the road in this video. Note the one lane bridges with rough gravel leading up to them and the various points where portions of the road are washed out. In particular, observe the road around the 5:30 mark in the video – that spot was a bit worrying.

Here’s the next entry in my road video series. This one is the same as the previous one but in the other direction. The start and end point is the same.

As I mentioned previously, the Dinosaur Trail loop at Drumheller is well worth doing, especially when the Bleriot Ferry is operating.

The latest installment of Lost Wizard on the Road is up. This time, take a trip around the Dinosaur Trail loop at Drumheller, Alberta. This particular trip travels clockwise from the junction of Highway 575 with Highways 9 and 56 in Drumheller. At the mid point, there is a great view of the Bleriot Ferry as it makes its way across the river and back again.

This trip is well worth doing if you are in the Drumheller area when the ferry is operating. (If you’re going to be there in the spring or fall, check to see if the ferry is operating before making the trip.) Even if the ferry isn’t operating, the trip is still worth doing but it turns into two out and back legs starting from Drumheller.

I recently had occasion to attempt to integrate PayPal Payments Pro into a web site. Now, theoretically, that shouldn’t be a big problem. However, I was skeptical from the start since my previous experience with integrating anything PayPal was less than pleasant.

First off, I started out by trolling through the developer documentation at PayPal’s site. It quickly became clear that organization is not their strong point. There is much discussion of various APIs and SDKs which mostly serves to confuse the issue if you don’t already know the answer. Since I know what an SDK is, I thought, perhaps, such a thing would make my life easier, as is often the case. I figured it would prevent me from having to bother with all the low level communication details. Alas, that was not to be the case.

I downloaded the SDK I apparently needed though determining that was something of a chore on its own. Then I attempted to use it. I discovered that I need something called “composer” to “install” the SDK. That was the first WTF. SDKs usually do not require “installation” of any sort. You should be able to just download them, shove them somewhere convenient, and use them. Nope, not this one. Instead, you have to run this “composer” thing to fetch dependencies and construct the environment properly. And this requires command line access on the server, which is a no-go for the vast majority of hosting providers.

Well, as it turns out, I have command line access so I attempted to follow the instructions for installing this “composer” thing. First, it barfed about some obscure PHP setting not being set correctly but it provided some helpful advice for fixing that. Once I got past that, it gave me reams of cryptic errors about SSL problems and no clues what might be the cause. Fun. Eventually, I got thie installer thing to run using a command line switch which is not mentioned anywhere except in the help output from the installer itself.

Okay, great. I got the “composer” thing installed. Then I ran it (after some difficulties working out how to do that successfully) and it seemed to finish without problems. Then I followed the basic instructions on using the SDK itself.

This all seemed good until I actually tried to make a call into the SDK. Nothing worked and there was no documentation or any guidance on what might have gone wrong to cause the error. Much searching around on the interwebs revealed many people having similar problems with no useful answers from PayPal except “you didn’t install it correctly”. Basically, this left me with a completely useless SDK which apparently works fine for PayPal employees.

I did some digging into the SDK itself. What I discovered was horrifying. Inside the SDK are dozens, if not hundreds, of little PHP files defining classes all over the place and using namespaces all over the place. The whole thing is apparently glued together by an autoloader provided by this “composer” thing. Leaving aside the very heavy, obscure, and complicated dependency on “composer”, which apparently is there because it is more “convenient” for something like 0.0001% of all developers, it became abundandly clear why there was such a problem. Here’s a hint: if your system falls over dead without a class autoloader, you either have a very large complex problem or you have an overly complex rube goldberg scheme going on. Here’s a hint on the hint: you almost never have a very large complex problem.

After some quick studying of a few of the files, I realized that a piece of academia had escaped into a production system. The SDK design is textbook “object oriented” design in a source structure that would be more at home in a Java jar file.

Next I wondered if there was any particular reason for the complexity. After all, there might have been. I dug around for a while until I found the documentation for the underlying API. Much to my surprise, I discovered that it was a simple collection of remote procedure calls accessed through one a couple of interface formats (SOAP or Name/Value Pairs, namely). In other words, they took a fairly simple set of function calls and wrapped them up in a rube goldbergian class hierarchy, exceptions, and some sort of framework.

Now armed with the API documentation, I cranked up my PHP skillz and started banging away on the keyboard. In under an hour, I had a single function that could package up a request and send it to the PayPal server. It even managed to obtain a proper response from the server (“you are not authorized” in this case because, well, I didn’t use proper credentials, but it did prove the concept).

Now, the API has a large number of calls available. I can see a class structure for such an API having a class per API call and even an underlying structure for making API calls.  But why does an API based around essentially simple remote procedure calls need a massive library and framework system with a fragile class autoloader to work? Why can’t it just define the basic API level stuff in a single file and then, possibly, each actual call in its own file and be done with it? And better yet, why can’t that simply be in a single directory structure that can simply be dropped in, a single file included, and access to the whole shebang just works?

In summary, SDKs are supposed to make the developer’s life easier, not harder. PayPal completely missed this point with their SDKs. When it is orders of magnitude easier to work with the raw API (I’m not kidding about orders of magnitude), the SDK is horribly broken.

If you have occasion to integrate PayPal services, ignore the SDK entirely and deal with the low level API directly. Your sanity and budget will thank you.