At Segue, we look forward to the unique opportunities and challenges that come along with embarking on starting a new project. Segue recently partnered with a client in education that brought a particularly challenging but rewarding opportunity – to build a secure web browser application for tablet devices which would allow students to take web-based standardized tests without the ability to compromise the integrity of test results. The primary goals of the application were to make sure students stayed within the application, could not access any website outside of the test, and could not check email, take screenshots, or use any other features of the device which might compromise the integrity of the test. The solution also needed to be HTML 5, CSS, and JavaScript compatible and provide the ability to communicate via an API in order to check the integrity of the testing environment at any time, including checking if hardware and operating system features were enabled or disabled. This project provided our mobile app team the opportunity to work through some very challenging constraints and technical limitations to ensure a secure web-based testing environment.
Our Approach
Segue worked with the client to develop native iOS and Android web browser applications to securely administer web-based tests, while also enabling the tablets to be used for daily classroom activities. Given the need to progressively identify and mitigate potential test taking exploits as they were identified, Segue used an iterative Agile approach that allowed us to collaborate with the client, developing the highest value and highest risk features first, and discovering and mitigating additional needs along the way. Within two weeks, Segue deployed the initial version of the mobile iOS and Android web browser applications to the client’s environment for live testing with their web-based tests and provided frequent updates thereafter for additional testing and review.
The Solution
Existing mobile web browsers do not support robust customization or security and a solution designed for them would not meet the following requirements:
- Prevent students from using navigation controls other than those provided within the test
- Prevent students from exiting the test and switching to another application
- Prevent students from copying and pasting text
- Prevent students from taking screenshots, using audio or video, or connecting to external accessories
- The designers of the tests needed to be able to use JavaScript embedded within the test pages to query the devices in order to determine if hardware features were enabled or disabled at any point while the test was in progress
Therefore, to meet these requirements, Segue created native iOS and Android web browser applications comprised of a single web view and introduced features on the app level and within the browser view to meet these critical security requirements. The solution was comprised of the following components:
Shared API: The custom web browsers needed to be compatible with Apple’s iPad and Android tablets. Since both platforms are different, not only in the languages used for development, but also in the sheer variety of hardware and software features offered between them, a shared API was developed to minimize redundancy and provide a single common interface. To achieve this, Segue created a universal JavaScript API which could be included in web-based curriculum tests and allow curriculum test designers to call functions which would execute on both iOS and Android devices. Segue created one JavaScript file containing iOS specific code and another JavaScript file containing Android specific code. Both used the same method names, so the tests could be built regardless of mobile tablet platform, including the proper JavaScript source file by detecting the web browser user agent string at runtime.
iOS Web Browser Application: With iOS 6, Apple introduced a feature known as Guided Access. This actually gave us quite a leg up when it came to disabling certain features of the device. By enabling Guided Access, a test proctor can lock the students into the custom web browser app and disable the home button. Disabling the home button prevented students from exiting the application, thereby preventing access to other apps and device features such as email, Internet, camera, etc. This one feature almost single handedly solved our major concerns, but we needed a way to determine if Guided Access was enabled and we also needed to know if it was ever disabled so the test could be stopped. Fortunately iOS offers a function to query the device to check the status of guided access, which was accessible via the JavaScript API.
Curriculum test administrators wanted the ability to direct the web browser toward specific test URLs and wanted to ensure that students could not change them, so we created a settings bundle in the built in iOS settings application. This allowed the test administrator to disable Guided Access, change the test URL via the settings app, then restart the secure browser and enable guided access to make sure they could not be changed.
One of our greatest difficulties was disabling copy and paste because it is a feature that exists on the operating system level in iOS. Since almost everything in the secure browser happens within a web view, it inherits the default copy/paste functionality. To override this we needed to subclass the web view so we could modify the default menu controller to specify our own options for when the user presses and holds their finger on a text item.
In order to allow test designers to call JavaScript functions and execute native code on the device, we needed to figure out how to convert JavaScript to Objective-C (Apple’s native language). First, JavaScript code on the test page calls an API function. In this example, we will call this function isGuidedAccessEnabled. This function creates a hidden iframe on the test page and sets the src attribute to a URL like “apischeme://api/isGuidedAccessEnabled/callbackHandlerName”. By setting the src attribute in an iframe, we are able to intercept it with an Objective-C method defined in the web view. Within this native method, we can determine that the URL scheme is of type apischeme and we parse the rest of the URL to determine which function should execute. In this case, we see that we want to know if Guided Access mode is enabled so we call this method natively and return the result as a boolean value that the callback handler in the JavaScript API can handle.
Android Web Browser Application: As an open source platform, Android respects the user’s desire for customization, while protecting them from malicious activity. Applications are not permitted to do certain things that might be construed as harmful to the user – for example to override the home button or programmatically enforce the use of a particular input method such as a particular software keyboard. You wouldn’t want an app that prevented you from running other apps or a keyboard that forced itself on you so that it could send your keystrokes home to a 3rd party. However, the open source nature of Android created a few more security challenges then iOS, so we had some additional challenges to overcome.
Android’s WebView provides very convenient and easy access to native code and platform functionality through JavaScript. However the need to create a shared API, and the limitations of iOS’ JavaScript implementation left us with a fair bit of work on Android. This made the Android backend significantly more complicated than it otherwise would have been. In the end, we wound up with an implementation not too dissimilar from PhoneGap – a framework for building hybrid mobile applications, consisting of both native and web code.
To determine if the user left the web browser application, we relied on Android’s lifecycle methods – onPause and onResume, to determine if the user left the application. This necessitated controlling changes on device rotation, so that turning the device around would not be construed as leaving the application. We also used Android’s WakeLock’s to keep the device active during the test – primarily to keep the screen on and network active, but as a handy side effect preventing a suspend/resume cycle, which could look like leaving the app.
Locking down copy and paste was probably the most challenging. We could clear the clipboard on coming in and going out of the application, but how to clear it within the application? Android’s WebView component uses a Contextual Action Bar (CAB), and access to it is not available via the API. We had no way of removing the copy and paste functionality from the CAB. Fortunately the Java Reflection API came to the rescue, allowing us access to the otherwise hidden code to remove the copy and paste buttons. This allowed for text selection to work normally. This kind of workaround is not for the faint of heart – by nature it’s very brittle. There could be manufacturer changes to what appears on the CAB, the order of items, etc. Additionally there are some major changes underway in the Android 4.x releases to the WebView component. We could only work around those versions that we had access to – it will definitely require testing and maintenance.
For the Input Method problem, we implemented our own keyboard based on the Android 4.0 keyboard, but with things like spelling correction, etc. removed. Ultimately this was not something we could completely lock down, since they also wanted to support hardware keyboards.
At the end of the day, someone requiring or desiring this strict control may be better off rolling their own Android device with a customized version of Android that locks many of these things down at the platform level, or working with Google to extend the operating system to provide additional controls. Restricted profiles, new in Android 4.3, are a good first step, but still won’t provide everything.
While the secure mobile testing application project was challenging, the team ultimately overcame all the highest priority technical and security challenges, delivering high qualify apps over the course of two months, and collaborating with the client along the way to react to changes. Our team enjoyed the opportunity to solve challenging technical problems, which provided an opportunity to learn new technical skills and apply creative architecture and development approaches. We’re looking forward to our next challenge!