Balancing security, privacy and convenience

For the last two years, my keynotes have included sections where I discuss the balance between security, privacy and convenience. 

There are always trade-offs between these three when developing products and services, with convenience often prevailing as the key requirement. The recent proliferation of activity trackers and voice-activated home automation devices is just one example of this in the world of connected devices, where little thought is given to how the security and privacy of the information being collected can be abused and/or misused.

For over 20 years, I’ve tried to understand why users of services and products are not holding implementers of products and services accountable for this imbalance. The TL;DR summary of what I’ve found: convenience is always the top priority; in most circumstances, implementing proper security and privacy functionality is hard; and you have plenty of people pointing out problems but few who help provide knowledge of how to fix the issues or, more importantly, to provide transparency and informative information on a product or service’s default behaviour.

Every time I’ve taught a security workshop to network operators who typically also had security-related operational oversight, I started with the fundamentals of implementing good cryptography and giving advice on what questions to ask vendors: 

• How do you implement randomness in your cryptographic implementations?
• Which encryption algorithms do you support? 
• What modes do you use in your cryptographic implementation (ECB, CBC, OFB, CFB, and so forth)? 
• What is your default key length? 
• How are keys exchanged and renewed?

It’s a snoozer to most and no one usually cares about these details. The network operators, like their end-users, just want a convenient means to configure a secure solution with the least amount of work. Yet we are constantly reminded what a paradox this is.

 

There are many product and service choices made for convenience including:

• People automatically appearing as contacts in a new application to make it easier to connect with them.
• Creating a new account using your Facebook or LinkedIn credentials rather than creating a new username/password combination.
• Video is automatically turned on to enable you to see each other during online communication.
• Information is automatically sent to a manufacturer or third party for analyzing and improving services.
• A device automatically connects to an open Wi-Fi without needing a password so you have immediate Internet connectivity.

From a security perspective, these defaults are insecure given that malicious actors can easily manipulate such functionality to cause harm. Instead, we need to exert control over communication and have accountability for any misbehaviour.

Taking back control of privacy and security

This requires careful thought on how to instantiate fundamental functionality of authentication, authorization, access control, integrity, confidentiality and auditing. At the very least there should be considerations for how to handle the following:

• How are individuals, devices or applications authenticated, that is to say what credentials are used to assert identity?
• What are these individuals, devices or applications allowed to do once authenticated?
• How would you control access to specific data or services? 
• How do you assure the integrity of communication and ensure the sender and recipient are who they profess to be and that no one has modified any data in transit? 
• How does it comply with confidentiality policies, where only the intended parties can see the data?
• What information do you track for auditing purposes to detect and provide attribution for any accidental or deliberate abuse?

Then there are aspects of privacy to consider, where there are nuances related to human rights and freedom of expression. Anonymity and hiding of one’s identity have been a privacy requirement in instances where online communications and access to information can put lives on the line. Also, who has the right to access any data? And should all data access be only allowed with specific permissions to do so?

A key aspect to balancing trade-offs between convenience, security and privacy is to articulate and understand the trade-offs. This is especially important for end-users who would have a harder time enumerating the varying considerations.

Trusting online communications and understanding the true risks is critical. What may be easy for a healthy person to use may be nearly impossible for the elderly or disabled. The requirements are also vastly different for convenience, privacy and security depending on who uses a specific Internet-enabled tool or product.

And, sadly, the malicious users or criminals who take advantage of a crisis are the primary culprits of raising fear, uncertainty and doubt of many usable online tools and services.

The following table is a simplified requirement matrix that might be useful to start some discussions for organizations new to ubiquitously using online tools or to vendors building new online tools and services:

Requirement	Specific details
Usability
Setup time	How easy is it to install and get started?
Multi platform	Can it be used in a heterogenic environment that includes multiple operating systems? What are the caveats? What doesn’t work in which platform and why?
Resource requirements	How much bandwidth or computing power is required for normal operations? Are the capabilities usable in low bandwidth and low computing power modes?
Error management	When something goes wrong how quickly can it be detected? How quickly can a detected error be fixed? While you never know the severity of an error, are there processes in place to handle error management issues?
Upgrades	Are any settings reset when software or firmware gets upgraded? What notifications are given for any upgrades and details on what is being upgraded and how?
Security
Authentication	What types of credentials are used for authentication? What methods of multi-factor authentication are supported? If applicable, how is key lifecycle management done by the vendor (creating, distributing, storing, backing up, renewing, revoking, destroying)? What are the default settings for key lengths? How can credentials be forged and with what level of difficulty for determining forged credentials?
Authorization	How is authorization performed and what credentials are required?
Access control	How can I control who has access to the service/data? How granular is the control?
Integrity	What mechanisms are used to ensure that parties communicating cannot be impersonated? What mechanisms are used to ensure that information cannot be modified in transit? How can the integrity mechanisms be compromised?
Confidentiality	What mechanisms are used to ensure that only authorized individuals can see data? How can confidentiality mechanisms be subverted or bypassed? What level of issue is there if no one can see the data but can glean metadata information such as if there have been changes to files?
Availability	What can disrupt service or access to data?
Audit	What information can be accessed and logged for auditing purposes?
Privacy
Identity hiding	What mechanisms can be deployed to achieve anonymity of who is using or accessing service or data? How can these mechanisms be subverted?
Content Hiding	What mechanisms can be deployed to only have confidential access to certain information? How can those mechanisms be subverted?
Data Sharing	What data is shared with whom? How is the data shared? How can I track when my data is being shared and with whom? What are the default modes for any data sharing?

Preserving privacy and securing online communications needs to be appropriately balanced with convenience. In an upcoming post, I’ll delve more deeply into what I call blind trust and how we all can take responsibility for increasing trust and safety in our digital worlds.

Read: Blind trust

Merike Kaeo has over 25 years of experience in pioneering core Internet technology deployments and leading strategic digital security transformations.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.