Knowledge of application context is used routinely in mobile applications—for example sensing a user's context (e.g. location and physical actions, time, etc), reducing network usage during periods of inactivity and designing for users. But how does this idea transfer to the server?
I almost called this environmental awareness, but didn't want to cause confusion with discussions about network/server environments. By 'situational awareness' I mean awareness of factors external to the application that might be used to affect its behaviour. In my talk this week about application intrusion detection, I will be discussing how an aspect such as the general risk level to an organisation/application might be used to alter an application's actions (e.g. amount of logging, attack detection thresholds). But this awareness, can be used beyond attacker detection and response.
Information is knowledge and additional awareness of external factors can be used to control changes to the application. An adaptive application can learn change in response to outside factors. And no, I don't mean displaying an intrusive and annoying paperclip that says "It looks like you're writing a letter". Apart from standard functionality the user sees, some ways your application may already be doing this are:
- customising content based on:
- geo-location information
- user preferences
- device type (e.g. mobile), browser and screen resolution
- typical user behaviour
- implementation of additional delays for failed attempts at authentication
- use of reputation-based systems
- displaying the number/identities of active/logged-in users
- detecting usage of the application by users from a different location than they had used previously (e.g. IP address)
- showing advertising based on users' behavioural characteristics.
But what else can be done? I remember chatting with someone during an unexpected period of severe weather which had disrupted travel in south-east England one morning. They had explained that in situations like this when their call centre was under staffed, they had procedures in place to reduce the length of each customer call, by shortening their own scripts taking out offers for helping with anything else and cross-selling/up-selling. The dialogue script was adapted to the situation. A web application could respond in a similar way during increasing, and higher periods of demand, to increase availability:
- switch to more static content (e.g. change the home page to static HTML rather than a scripted dynamic page)
- swap to lower bandwidth assets (e.g. display photographs instead of videos, use lower resolution photos)
- use third-party servers for some content (e.g. video on YouTube)
- reduce the size of pages and number of page elements by dropping out non-core material (e.g. promotional items, banners)
- increase caching
- delay non-core server intensive activities (e.g. management report generation)
- provide links to printable forms to divert some or all users of a particular online service.
Similarly, if a local (e.g. dynamic PDF creation or chart generation), back-office (e.g. data archive) or third-party service (e.g. payment authorisation, address look-up) is detected as running slowly or has become unavailable, some of the following may be possible:
- switch to cached data
- add a queue to access the function
- slow down the speed at which users can undertake the function
- offer alternative (quicker) ways to complete the transaction
- take the service offline, but offer to email users back when it is available again.
Similar changes could occur in advance of, or during, known scheduled application maintenance periods:
- advanced warning notices to users
- timed count-down to function or application shutdown
- preventing users beginning new tasks which might not be able to be completed before the shutdown
- ability for users to request notification that the service is back up.
The important thing (remember "clippy") is not to change the user experience too noticeably, and where there is a significant change (e.g. download the form instead of doing it online), provide a time-stamped explanation of the change and reasons.
These measures all bring complexity, and it is important they do not introduce additional vulnerabilities to the application. The problems are quite likely to be in authentication, authorisation and session management and need to be identified during security specification and verification processes. The effect on data integrity, including accuracy, also needs to be considered. But the measures are worth considering where the alternative is additional standby staff and increased usage of other channels.