2. Guard against all risk of fire Security is a huge issue and as exploit frameworks and toolkits become more and more prevalent and feature-rich the likelihood of vulnerabilities being discovered in our applications should be treated more like a certainty.  If you’re developing bespoke applications and especially web apps you’ll need to pay close attention to the OWASP Top 10 application security risks but from a database perspective the most notable threat is SQL Injection - the art of passing SQL into an application so that it might be executed by the database (as a good starting point check out OWASP’s SQL Injection Prevention Cheat Sheet).  If you’re deploying packaged apps or BI tools don’t think that you’ve gotten away with it, the primary responsibility may be on software developers to avoid exploits but if they’re baked into an application you’re implementing it will affect your users and your business, so…

  3. Protect wildlife, plants and trees The most important security contribution we as implementers can bring to the table is to review and limit the privileges required by our applications.  Many install guides and expensive external consultants ask for a ‘dbo’ (database owner) level user and some even ask for ‘sa’ (system administrator) or ‘root’ level privileges but don’t hand these out like candy on halloween.  In most cases these high-level privileges are only required during setup and install and can be removed afterwards but often basic read/write access is all that is required (and for BI tools often read-only), it may only be achievable through a few frustrating rounds of trial and error but if you assign your applications the lowest possible permissions you will significantly reduce the risk of compromise in the future.  Another important step during implementation is to make sure that your permissions are segregated, where possible have a separate user for each service and an entirely separate user for accessing each database not shared by any other application.  Whilst it may seem excessive this setup will allow you to audit any security issues and identify which user was compromised and exactly what they had access to.

  4. Fasten all gates Many Business Intelligence tools include some degree of control over connection management and if you’re developing your own application you’ll have complete control over all database connections, the decision to be made is whether connections are ‘pinned’ open, closed after x minutes or closed at the end of each transaction.  The preference will vary depending on the load and the usage, in most Business Intelligence use cases there tend to be a large number of users, not always connecting concurrently and issuing fairly large queries against the database followed by periods of quiet whilst a report is read – in this case there is usually no need to keep the connection open for long.  On the other hand if you have users issuing a constant stream of small transactions (e.g. a Point of Sale system) the overhead of creating and dropping connections might actually add load to the database so it would be more effective in this scenario to maintain the connection.

  5. Keep your dogs under close control This applies more to developers and BI architects where your dogs are your users, if you are deploying an application that creates load on somebody else’s database you should do whatever you can to limit each user’s ability to cause long running queries – in some BI tools you are handed an option to let a query time out after x minutes and perhaps limiting the number of rows returned.  If you are developing your own application you should include both of these options but make sure that you kill the query at the database level rather than just killing the thread in your application that made the request otherwise it’s equally bad if not worse since the user may simply re-issue the offending query.  The actual limits are bound to vary from database to database but that’s where the first point comes in, discuss this with both your users and the DBA.

  6. Keep to public paths across farmland / Use gates and stiles to cross fences, hedges and walls When it comes to solving problems try to stick within the basic and simple boundaries of an ordinary user, avoid using undocumented stored procedures, excessive use of user defined functions, custom data types, plugins and extended stored procedures or anything else that strays too far from a standard install of the database platform.  Obviously you’ve got an app to deploy and you want to solve your problems in whatever way is best for your users but the further you are from a standard deployment the more issues you’re likely to encounter, both you and the DBA might be fully aware of this amazing new setting you tweaked to make things run better but a couple of years down the line during a disaster recovery will it all come flooding back quite as easily?  What if one or both of you that setup the application have moved on to other roles?  Thinking outside the box is great but be conscious of introducing risk and if you do feel that it is necessary then make sure that it’s well documented in the Run Book or the corporate wiki.

  7. Leave livestock, crops and machinery alone Since you may already have elevated privileges on your own database, a shared database or even the server you may be tempted from time to time to perform maintenance tasks or make minor ‘improvements’ to indexes or configuration settings – do not do so without the DBA’s blessing.  If you’re following the rules above you’ll probably have a fairly good rapport with the DBA already so it’s likely that you’ll be granted some level of trust not to mess things up but be careful not to overreach, the DBA will be ‘in the loop’ of many changes and other requirements (e.g. critical deadlines, disaster recovery tests, unplanned maintenance) whereas you may not be aware of them so before you make any changes run them past the DBA – just in case.

  8. Take your litter home / Help to keep all water clean If you’ve ever been a DBA you’ll have seen, on more than one occasion, tables popping up called tmpSomethingorOther, tblToBeDeleted or TableName_bak but when it comes to the key questions (How long have these been around?  Are they still required?) nobody seems to have a straight answer.  I know myself that whilst I’ve been developing data warehouses I’ve created these sorts of tables and subsequently forgotten what they were used for, not too much of a problem if you’re ‘the guy’ but in a large team or with personnel changes over time it can be hard to know what is required and what isn’t – I came to a database once with temporary tables over five years old which had not been deleted out of fear that they were important.  The moral here is an obvious one, clean up after yourself or if the table must exist for some short period of time put a note in your diary to come back and cull it.

  9. Make no unnecessary noise Be mindful of what errors you raise and what you write to public logs, if your application causes a large amount of data to be written to database or other centrally collated logs you may inadvertently make it harder to detect genuine issues which will hurt both you and and other users of the database.  If you do occasionally need exhaustive logs consider adding a ‘debug mode’ into your application which can be turned on or off via a configuration setting, that way you can turn it on whilst you’re tracing a fault and need more verbose logging then turn it off when you’re done.

  10. Take special care on country roads There can be plenty of unexpected hazards on country roads so don’t always rush around everywhere at 60mph, acknowledge that whist you might want everything to go as fast as possible you could be causing some other critical process to slow or stop.  Driving at night can be treacherous too as you might come across an unexpected backup window or import/export process, talk to your DBA and coordinate the major tasks.  If it’s a shared server make sure you have access to the task list so that you know where to slot in your jobs and that those jobs get put back into the master list.

Really it comes down to one thing, as the great and wise Jerry Springer oft said, “take care of yourselves, and each other”.

Capture mobile users from the full site – if your full site isn’t rendering well on mobile devices how are people going to find the link to your mobile site?  Put in place a redirect to a mobile optimised layout though it’s worth remembering that redirects could also be annoying to users that wanted to see your main site so… Provide a link back to your full site – this could be in the footer or as a landing page but in some cases the user may be trying to achieve something not possible on a slimmed-down mobile site or they may be on a tablet that is incorrectly being recognised as a mobile device. Remember the bad old days - there are still a large number of mobile devices out there that do not fully support CSS and JavaScript, including older Blackberry models which are common in corporate environments.  If non-smartphone users are a target audience for your site it should be designed with these older phones in mind and progressively enhanced to support more modern design features and input validation. Consider multiple mobile layouts - you could have a theme that optimises content specifically for iPhone and Android, leaving the other mobile users with a plainer but still small-screen optimised site.  Figure out what your audience is likely to be using and target that but don’t forget to tweak and customise the site after you’ve gone live based on the type of devices your users are actually using which will change over time. Use appropriate input types – if you are asking the user to provide email address or usernames via a form it can be difficult for them to enter correctly if autocomplete is turned on, similarly it would be better to provide the numeric keypad if you are asking for a telephone number and you usually would not want .  You can provide this functionality with a mix of the <input> tag and the autocapitalize property, there are a whole host of other possibilities including length checking and regular expressions but bear in mind not every device will respect these features. Avoid scrolling – pagination vs. scrolling has long been a debate in web design circles but if you want to provide your users with a more ‘app-like’ experience the key elements to your site should fit adequately on the page without the need for scrolling.  This may not apply to content but if the user is being asked to follow through a process or provide a series of inputs it will be much clearer to the user what they have to do if it fits on one page, equally… Avoid clutter – if you have pages with little content it may be worth ensuring that any non-essential (but for whatever reason required) footer information sits below the bottom of the screen to avoid clutter, at the very least you should consider a little trailing white space followed by a dividing line to clearly separate the content from the footer. Consider the user’s goal – you might be falling over yourself to provide content or services to your mobile users but is that what they really want?  Consider whether or not the user might have other goals in visiting your site and show how they can be achieved, even if that is not via your mobile site.  For example, it may be helpful to include a ‘contact us’ or a telephone/email link on at least the first page if not every page. Don’t be annoying – it’s the little things that tend to irritate users and on a mobile device this is magnified since they are already compromising on screen size and input capability.  For example, pre-fillling forms with help text may mean that the user is going to have to delete that text to enter their own – irritating enough on a desktop and even more so on a mobile device. Device testing is essential – there are dozens of emulators and simulators for mobile devices but nothing will ever match testing on devices, it is very tempting as a developer to test primarily on a desktop but it really isn’t the same as holding a small device at arm’s length and using a tiny keyboard to provide input.  During your testing phase have someone with a very critical eye run through your site to check for any minor irritations, make sure to tell them to be ruthless in their criticism.

I hope that provides some useful information to those of you starting out with the mobile web and of course, much of this is up for debate so do get in touch if you disagree or have content to add.  The list is not intended to be exhaustive and over the next few months I’ll add posts on testing and more technical aspects of the process.

Time from about 7pm onwards

Location: the upstairs room of the Nell of Old Drury pub.

For more details, suggestions, offers of help, offers of sponsorship etc:

Subscribe to the London 2600 email discussion list or email this blog via meetings@london2600.org.uk

Read the full post at darknet.org.uk