Mass-assignment – don’t control access at the model level

I followed with some interest the debate around the “mass assignment vulnerability” recently reported in Rails. I dislike the way the whole debate is couched assuming access control at the model level. When you are stating that an attribute cannot be assigned, you are stating that to assign this attribute from the controller, you can’t use the normal update_attributes method, and must update it explicitly.

I don’t like the laziness this implies. I believe we should embrace practices that encourage explicit thought about the attributes a controller method can update – encouraging developers to build in an intentional fashion, and consider exactly how each method they build behaves. The role based security in Rails 3.1 is alright. But I still think the definition of which attributes a controller method updates should be made explicit. It isn’t just a security concern. The attributes a controller method can take as input to update a model should be part of the contract of that method, in my opinion. It aids understanding.

I far prefer the ideas of the View Model and Model In Model Out. The input a controller can receive, and the output that is rendered to the view is both explicitly modeled (and therefore documented), and independent of the underlying model. Using a tool such as Automapper can prevent the noise mapping View Model to Model can introduce.

I don’t know the Rails community well enough to know what people are doing in this space. I saw a stackoverflow post that refers to a Presenter patter, but can’t say I’ve looked too closely yet.

Autosaving of form fields in browsers

I’ve once again lost a decent sized chunk of text in a textarea, due to a browser crash. I’ve started wondering about whether browsers should implement autosaving for textareas. Our usage patterns have got to the point where we use browsers to write large chunks of text on a regular basis.

Generally when I’m writing an extended chunk of text, I will do so in a text editor, and only copy the text into a website when I have to. However, this is a poor workaround.

Some websites implement their own autosaving. Whilst this is a great move on their part, I think that it’s time to look at how autosaving could be supported at the browser level in a standard fashion. Browsers already maintain a significant amount of state after a crash, tabs, positions within tabs, etc. Extending this to include form entries shouldn’t be challenging.

The main difficulty with this proposal is the privacy and security implications. But these are not insoluble.

Firstly, when a browser first considers autosaving a field, it could ask you whether to enable it, with options like Yes once, Yes always, Yes for entire site, and the equivalent No options.

Secondly, an extension of the idea of autocomplete="false". Replace the autocomplete attribute with private="true". I like this as it specifies intent rather than behaviour. The browser can then interpret that private fields shouldn’t have autocomplete, that they shouldn’t autosave, and other behaviours that are meaningful for the private field.

I think this is something that’d be worth W3C consideration. Or alternatively one of the browsers should pick this feature up as a point of difference. I’ve already lost more text than I’d like because of browser crashes.

Android is the mobile platform of the moment

If you’re going to choose a single mobile platform to develop for in the next year, there are three main alternatives: Android; iPhone; and Windows Phone 7. It’s my belief Android is the platform for developers new to mobile.

Colleagues I talk to are surprised about my opinion. iPhone has the Apple design x-factor, and appears to still be the in thing around my office. And Windows mobile has a new, effective and quite unique design aesthetic applied to its user interface.

However there are reasons that Android looks like the best of the bunch.

The most immediately important reason is price. The cheapest Android phone I can find on Pricespy is an LG GT540 Optimus at NZ$281. The HTC Tattoo and Sony Ericsson Xperia X10 Mini are similar prices. The cheapest iPhone on there is an iPhone 3G 8GB for NZ$599. Whilst I can’t find any pricing for Windows Phone 7 at the moment, the high minimum specifications lead me to conclude it’s prices will be in the iPhone price range.

Gadget fetishists will spend a lot of money to have a really nice piece of kit that’s well designed. But Android phones are starting to get cheap enough to appeal to consumers who are looking for just a little more than a vanilla mobile. As consumers start to realise that smartphones are finally priced within their reach, a whole new audience is going to be available to Android developers.

But longer term there’s another important factor. As an open platform, Android is going to be used as the basis of more and more non-phone devices. I can’t make my points more eloquently than this article: Tipping Points and The Future of Electronics. But I’ll leave you with a quote from it: “But that’s beside the point, which is this: saying that Android is fragmented as a phone platform by comparing it to the iPhone is like saying the iPhone App Store is closed by comparing it to the PC. It’s the wrong comparison. Instead, think of it this way: Android is the most unified electronics device platform in the industry’s history.”.

I think Android is going to become a bigger market than the other two platforms, both for applications, and for skills. Android is a great platform to be involved in for a software engineer. I’m excited to be learning it.