Quoderat

As weblog syndication moves into the mainstream, people are complaining more and more about how difficult it is for an average user to subscribe to a weblog (here’s a recent example, but it’s only one of many I’ve read). One problem is deciding who an average user is — a sixteen-year-old who can text message on a cellphone numberpad with her thumbs at 20 words per minute, for example, can probably find the little orange icon on a web page — but the bigger problem is that making weblog subscription too easy will destroy the biggest future benefits of RSS and Atom.

While most feeds today are general, public information (like Quoderat), more focussed, personal feeds are currently our best hope for a solution to phishing and spam. Unlike e-mail, blog feeds are highly resistant to these problems: I have to manually subscribe to a feed to start getting messages, and can unsubscribe whenever I want. Someone selling drugs claiming to lengthen part of my anatomy can write all the messages he wants, but I’ll never see them; a script kiddy in the Russian Republic can create hundreds of messages telling me to follow a link to update my bank account information, but I’ll never even know. As average users (whoever they are) deal with more and more spam, and hear about more and more phishing cases, they will start to mistrust all commercial e-mail (legit or not), and there will be an excellent opportunity for RSS and/or Atom to step in and offer government, business, and other organizations a new, trustworthy channel for communicating with the public.

But wait — what if we make subscribing to feeds too easy? What if it becomes trivially simple to add a feed to a user’s subscription list with a script or disguised link, without the user being fully aware? Users could end up with apparently legit feeds with titles like “Daily News” full of spam; even worse, a user could end up with a feed entitled “Lloyd’s Bank” with a message to — you guessed it — go and confirm her password information.

Remember that one of the big problems with e-mail came from trying to make it easier for users, say, by running attachments automatically. Let’s make sure that subscribing to RSS or Atom feeds stays at least a little bit difficult, even for grandma and grampa. A bit of work to subscribe to each feed will be our best defence.

This week, I decided to try PHP and Ruby-on-Rails for prototyping web applications (I’d never used either before).

These are both web-application frameworks that serious J2EE-type developers tend to sniff at, claiming that they may be fine for simple toys but are not suitable for real projects. Otherwise, however, the two are drastically different: PHP encourages a page-oriented architecture and makes you do a lot of extra work to get any kind of model-view-controller (MVC) setup; Rails enforces an MVC architecture with pre-defined naming conventions for database tables, etc., and makes you do a lot of extra work to design your application any other way.

I’ve long been an MVC and Java servlet fan. I love object-oriented programming, use REST as a web architectural style, and tend to think of XML-encoded data in entity-relationship terms. So why did I like PHP so much better than Rails?

I think that the answer has to do with the fact that web applications — whether producing HTML for people or XML for machines — are really about views, not objects. In anything but the most trivial cases, the views involve information from many different types of objects merged together to create a new object type. The most common way to generate these views is through SQL queries joining together different tables, and the columns in the result set define the properties of the new object type. I’ve spent a lot of time trying to use and trying to write object persistence layers for web applications, but they never made sense — my models always progressed quickly through the simple CRUD steps (X.create, X.read, X.update, X.delete) but then fell apart as soon as I tried to make my app do anything other than manage its base data. Should I define a new Java class for every possible kind of query result? How do I handle results that do not involve full objects? If I’m not getting full objects in query results, what’s the point of a persistence layer in the first place?

After all that soul-searching, prototyping an app in PHP was like a cool breeze on a hot day. I wrote a few helper functions to automate escaping values to avoid SQL or HTML insertion attacks, but I managed to fight off the temptation to write a persistence layer in PHP. Instead, each page has some PHP code at the top that makes one or more SQL queries, followed by HTML markup with only minimal PHP added to insert dynamic results. It works, it actually seems scalable and maintainable, it’s easy to deploy (just about all ISPs already support PHP, so you just upload the *.php files), and debugging is trivial, because the query is right there on the page with the HTML that will display its results. Bugs are not buried deep beneath 20 layers of abstraction, and the database and filesystem are the only shared state.

Rails, on the other hand, was a disappointment. It tries to make my database invisible so that I think I’m dealing only with objects, but my database, and its query capabilities, are what will make my application more than just a collection of objects with a simple search box. I ran into a bug during one of the tutorials and it was almost impossible to trace the problem due to the deep layering. And the only thing that Rails seems to simplify is the basic CRUD operations, which are the easiest part of any web app. Rails also tries to tell me exactly how to set up my database and page hierarchy — I know that I can change it, but by the time I’ve learned to do that, would Rails still be any easier?

I don’t know if I’m ready to jump to PHP for serious development yet. Java has a lot of good libraries for XML and supports Unicode well, and J2EE also lets me develop in a page-oriented model if that’s what I really want (though I have to do a lot of configuration rather than simply plopping a file into a directory). At the very least, though, I’m going to stop worrying about abstracting away the database and will try to learn to love it, whatever environment I use.

A short while ago, I wrote about how my megginson.com domain has suffered severe collateral damage from security flaws in Microsoft Outlook, even though I’ve never used the product and do not run Windows. Today, I noticed that my IP address had changed, and that I was not seeing the site (due to a stale DNS cache, I think). Here’s what my hosting service wrote in reply (with the name of my other domain XXX’d out):

The domain megginson.com is on a different IP than XXXXX.com. The site is working just fine; we had to move your site a few days ago to a dedicated IP due to the excessive email spamming that was still coming in that was targeting your A record rather than your MX record. You were averaging over 500,000 pieces of spam a day even after you moved your email offsite as a result of the A Record targeting. The move to a dedicated IP allowed us to block all port 25 traffic on that IP to augment the incoming spam.

Pay close attention to that. My DNS MX record does not point to this ISP (it points to a dedicated e-mail service); the hosting service has only the A record. Even the DNS A record is getting 500,000 hits a day on port 25 (!!!) — I’m afraid to ask what’s going to the MX IP address. Sometimes I feel more like I’m under a fullscale botnet attack than just a bunch of bounces from virus messages sent by infected Outlook machines with my return address.

Kudos to my current hosting service, javaservlethosting.com. They are a high-volume, low cost hosting site, and you would have expected them to dump me long ago (as several other, much more expensive ones have) instead of going to all this trouble and losing all this money to keep my site up. You never know where you’ll find true integrity in the business.