To the system engineer, "accessibility" represents a set of user stories for an end user who cannot, for reasons unrelated to intentionally-designed security, access all application functionality. An individual who cannot see will have issues reading a system screen, and must use some sort of technology to have a screen translated into an audio format. An individual who cannot hear cannot make use of training materials with a voiceover. These user stories are often not initially considered by the system engineer, who is generally restricted by deadlines and must consider only the functionality that he requires to test the application as well as the requirements of his direct customer. Though these combined requirements may ultimately satisfy 99% of the application's end users, the final 1% presents an interesting challenge for the engineer.
I came across a thread on Hacker News posted by a quadriplegic user who was trying to ensure the best possible security for password management given his challenges as a user. The HN community was all over this one - and mentally all over the place, as per their usual. Let's distill a few of their best ideas.
Our customer needs the following features:
- The ability to securely lock and unlock his Macbook Pro
- The ability to log in to various websites
Our customer has the following constraints:
- Cannot move anything below the neck
Our customer is currently unlocking his laptop with a voice-administered password that proceeds to unlock an application password manager. By doing so, our customer exposes his unlocked laptop to anyone who can physically access the computer. All passwords and application access will be exposed to the thief, who can then impersonate our customer across the web.
Our customer could install a virtual machine (i.e., an operating system inside an operating system) and store all information inside the virtual machine. By doing so, the customer could leave the physical laptop unlocked at all times and only unlock the virtual machine to retrieve passwords at need.
Though our customer is not overly concerned with a sophisticated hacker, additional security could be provided by encrypting the virtual machine image on the primary hard drive and only granting keys to the VM software. Even if the machine is completely physically compromised, data will still be restricted to the users who know the primary password.
Bluetooth Unlock allows our customer to unlock his physical laptop only when a paired Bluetooth device is available. If our customer has a Bluetooth-enabled device on their person, the laptop will only unlock if the customer is in the presence of the laptop and relock if the customer is no longer there.
Most Bluetooth-enabled devices are, by default, easy to steal as well. If our customer's iPhone was stolen, the computer would be locked permanently with the customer unable to do anything to retrieve the iPhone. A Pebble watch or Bluetooth fob for a keychain might solve this problem by either strapping the customer's device to his wrist or making the key inconspicuous.
KeyLemon replaces the standard password prompt with a facial recognition prompt. Much like Option 2, this allows our customer to only unlock the computer when the computer can recognize the customer's face. By proxy, this allows us to only unlock the computer when our customer is in proximity to the laptop.
The problem? It's crackable. Just by printing off a photo of the customer's face, someone would be able to bypass the facial recognition software and gain access to the machine. It's highly unlikely that someone would steal the laptop and then have a picture of our customer's face available, but it's certainly a possibility.
The virtual machine probably provides the best benefits for the costs, but that's a substantial level of effort for a nontechnical user. Our facial recognition software can be easily spoofed, which leaves us with the Bluetooth option. It's an interesting puzzle to crack, but this provides a fantastic example of security concerns clashing with accessibility.