Building a Secure, Ethical Prototype and Preparing for Alpha Release

This chapter is co-written by Caroline Sinders; Jennifer Helsby Lee, a developer who has worked on activist projects; and Harlo Holmes, Chief Information Security Officer (CISO) and Director of Digital Security at Freedom of the Press Foundation.

Once having completed testing, the prototype or idea is ready for initial launch. This is known as an ‘alpha release’ which involves publishing an early version of a product that has been tested and passed certain tests or requirements called ‘quality assurance’ that enables it to be ready for use by users and communities. An alpha release is the term used when you are in the process of development, whereas the more common term ‘beta release’ is used for a hard and more public launch. Generally, if you’re ready for alpha release then you are somewhat ready for a select community or for some users to use it. Alpha can also mean you are launching a version of your project that is paired down; perhaps it only has some of the features you had hoped to include but not all of them.

The goal of this chapter is to share the process of preparing for an alpha release and give examples of how to Q/A the project. It’s important to think of software development as an organic and iterative procedure which allows a team to launch at any phase and continuously add or update to the product or service to help improve the user experience. This chapter offers a place in the curriculum to work with the community to reflect on the research and feedback to date to prioritize the most important needs of the community and what you can conceivably build together. This often requires weighing needs, time, budget, and bandwidth across stakeholders.

What to Keep in Mind When Preparing for Alpha

The main part of an alpha release is figuring out: the core components of the project versus the requested features (or as we sometimes call them, the nice to haves). Remember, this can feel like a balancing act that requires some tough decision making and conversations with the community. For example, one of the favorite features identified isn’t required for the minimum viable product, and doesn’t make it into the alpha release. Working with the community will allow you to determine the most important features to design for right now, and what can be included in future releases.

To help navigate the tough decisions, it’s helpful to focus on the specific product goals for the users. These include:

After answering these questions, it will be easier to determine which features feel like more of a priority. Cross check that list with how feasible (given time, resources, access, support) it is to build those features. From there it should be easier to understand the list of features that make it into the alpha release.

Keep it Simple

When building, always come back to the main goals. By pairing down your goals to the very minimal and core features that are the center of what you are building, you create a foundation from which you can build. Once you have your most important goals outlined, you need to come together as a team and ask: what is the simplest way that you could build a system that would accomplish all of these goals? And then ask: how can I approach this, and make this project usable, easy, simple, and functional? There are a lot of fancy add-ons that will be tempting to include but a usable product far outweighs an attractive product at this stage.

Those considerations are what you are aiming for in your alpha launch. Your beta launch can have more features or improved designs, but an alpha release is focused on the project working and being accessible for the community.

SecureDrop and It’s New Workstation Release

SecureDrop “is an open source whistleblower submission system that media organizations and NGOs can install to securely accept documents from anonymous sources.” While it was originally created by the late Aaron Swartz, it is now managed by the Freedom of the Press Foundation and available in 20 languages. More often, but not always, the users of SecureDrop tend to be activists and journalists with some background in security or technology.

When developing SecureDrop, the team focused on three axes: maintainability of the product, security, and usability. The team behind SecureDrop found that focusing on their main users, activists and journalists, allowed them to really tailor their resources and design to meet their main users' needs.

Over the years, SecureDrop hasn’t changed in functionality or enhanced feature requests because the goal of its creators has been to keep it simple. But some of its biggest evolutions have been with the workstation. The workstation has a very simple and paired down interface, but its main focus is encrypted messaging. Even with the tools' simple design, there is a lot of complexity under the hood that is required to keep its users safe and secure. The kind of functionality and security of SecureDrop requires a lot of security architecture, and maintenance. Meaning, SecureDrop’s biggest needs have continued to be technical ones though it balances that among usability and simplicity.

For SecureDrop's team, new features are not added frequently since every new feature will have a security implication. Every decision or addition is very deliberate and has undergone many variations of threat modeling and security analysis so building out a new feature like a workstation took a lot of time and consideration, even for an alpha launch.

Using Industry Rubrics to Guide Development

The SecureDrop team uses a security and industry standard security rubric to help guide development and feature addition. When scoping potential features, they list out every asset that feature interacts with and asks:

Only by answering the questions in the rubric is the team about to fully understand how potential solutions or mitigation will be addressed. If they aren’t able to solve for potential mitigations or solutions, then the team does not add in the new feature or functionality to SecureDrop.

It’s important to note that the questions posed from the security rubric are specific to threat modeling and enhancing the security of the product. There are additional rubrics that cover security vulnerabilities, types of harms that could occur, data controls, and more. To fully understand the implications of new features many different analyses should take place across teams and with the community. New features have the ability to provide greater convenience and usability for some users, whereas they can negatively impact others. Or even lead to gaps in the tools’ original functionality.

Creating New Functionalities: The SecureDrop Workstation

Recently, SecureDrop rolled out a new iteration of their workstation. This really large and development-heavy project was initially only offered to a small number of organizations that were willing to work with SecureDrop on this alpha release. By working with a small group of very supportive stakeholders in alpha, it allowed the SecureDrop team to iterate and test new features. It also provided an opportunity to refine communication on the value of the update while helping the SecureDrop team gain insight into how to organize trainings and workshops about the new workstation feature. By working closely with specific teams, they were able to figure out the core functionality of the tool while still prioritizing security and usability.

Sometimes “Small” Changes Cause Big Problems

When working on an intricate development project, small changes can appear like minor updates but require many hours or weeks of engineering time. For your alpha release, you may be doing something similar. By working with just your community for an alpha release, it allows you to really hone and understand the most important parts of your project while ensuring that the product works and responds to your community. We’ve seen some products launch that were not prepared for the amount of traffic or users and break during launch. It’s important to test and make sure your product can withstand being used by thousands of people without hiccups or glitches. Alpha releases can provide a concrete understanding of what’s really important in your product for the community and slow down the adoption of the product to allow for less congestion at launch.

Translating Goals into Features and Benchmarks

SecureDrop had to create specific goals and then center those goals throughout the course of development, while creating privacy and security metrics. If your project is handling any user data, then it’s important to establish your security goals to prevent potential harm to your users from bad data practices. In the case of SecureDrop, the tool's central goal related to security is: knowing you want to protect the confidentiality of source documents in SecureDrop. By focusing on ‘protecting the identity of sources’ and ‘the source documents’ these became the two product requirements that guided the development of the project. This goal can then be translated into a user journey as: a user needs to send collaborators documents but needs confirmation on the documents being sent, and a kind of confirmation or trust that the documents are sent securely.

Understanding Feature Prioritization In Prototypes

Another benefit of creating product goals and translating that into development, is it gives your team a moment to sit with the development, community and design teams to determine how feasible it is to build those features. Perhaps you envisioned a fully fledged mobile app but the objectives can be achieved through a simple web application - which provides greater access and enhances usability of your intended audience. The more specialized requirements add more time, and can be more confusing for users. It’s important to ask and spend time discussing “how much is this feature needed to achieve our goals”. This question helps prioritize discussions with the developer and community.

As mentioned for SecureDrop, the biggest product goal is to prioritize security features. Every feature that gets proposed goes through a considerable amount of threat modeling before the feature can be included into wireframes or into the product roadmap. The team asks: how would the new feature impact the rest of the project as a whole? For example, some features may help solve a really annoying inconvenience but from a security perspective are unwise to implement. This requires the team to come together and weigh the different requests and considerations through security and privacy threat modeling while re-analyzing the user journeys, and user flows of the product. This process is illustrated in the upcoming case study that looks at why the copy-paste feature in SecureDrop was never implemented.

We suggest balancing features that offer convenience to the users against the potential security implications, and designing your own community safety and threat model framework. By developing your own framework, you bring the practice of security into the specific context you are working with. Doing so will require thought around the implications such as if the tool is too difficult to use, or if users data is leaked, or how you will abide by local security standards. And then allows you to understand your product-specific options to mitigate harm. However, it’s ultimately up to you and your community to determine the specifics of your needs. For example, Signal has different product considerations and use cases from SecureDrop, so as a tool, it’s much easier to send documents. But Signal is a messaging app, designed for secure messaging and not for whistleblowing.

Determining When to Add a Feature (Or Not)

Across the products and software we’ve built, there have been numerous times when a feature was requested that was too complicated to implement. Or in the case of SecureDrop, a feature was requested but we quickly realized that it presented a security risk.

This kind of scenario is one you are going to encounter time and time again, and it’s a difficult trade off, but is part of an iterative product development process. The community may want the product to do one thing but it may not be technically or financially feasible at the moment. In these instances, we would start ideating with the community to create a workaround or a second solution that addresses the problems they are raising.

This is where understanding your minimum viable product (MVP), along with how long it will take to develop the feature and the risk for that MVP, is really important. When you’re designing and prototyping, you will need to consider the time, feasibility, cost, and maintenance of the software in order to implement the feature.

Time: How long will something take to build? If it’s one of the core features you absolutely need, prioritize it. If it’s something you’d like to have, but it’ll take away core developer time, save it for a later release

Feasibility: Is this something your team can build right now with the resources you have? Or do you need someone with different skillsets to achieve it? If it’s not related or that necessary to your main goal, place this feature on a nice to have list and make a note that you need more team members to achieve this.

Cost: How much will this cost? Most likely, you’re working with a small budget and constrained resources, so any of the features you have cost money. It’s important, along with feasibility and time, to think about the cost of every feature or addition. This can help prioritize what to build and how.

Maintenance: All software and projects need to be maintained. Perhaps this project is funded with one grant to launch it. While it may seem premature to think about maintenance, it’s important to start planning what maintenance could look like to ensure you are not building something that will launch, help someone for a little bit, but never be touched or maintained again. In upcoming chapters, we will dive deeper into maintenance and sustainability but as it relates to feature implementation, this is important to be aware of continuous support.

Remember to Be Transparent With Your Community:

We highly recommend being transparent with your community about your limitations for prototyping, whether it be capacity, timeline, resources, or others. In some cases, funding is restricted or managed through a grant, and it often has a timeline of when and how it has to be used. In other cases, what seemed like a simple feature addition could take many months and require more capacity from the team than was anticipated. Being upfront in the ideation process about your and your team’s limitations, can help set expectations with you and stakeholders as to what features to prioritize and what can feasibly be built.

When To Not Make a Feature, On Copy Paste in SecureDrop

The SecureDrop workstation runs on the Qubes operating system, which is purposefully designed to make every window a user interacts within a browser as separate, secure windows. Different users have requested the ability to copy and paste material from one window into another, but Qubes and the design of SecureDrop didn’t allow for this quick transition.

To analyze the potential feature, the team built a pros and cons list for adding copy-paste and the different implications it would have while modeling the experience from a user's perspective. Let’s say you were using SecureDrop and decided “well, I’ll just copy and paste out of the SecureDrop window into a different program.” The built-in clipboard (how you copy) on your device is a different virtual machine managed by a totally different set of processes on your computer which is outside of the SecureDrop software. They learned that by copy and pasting from your browser, the user is exposing data from a zone that was containerized (SecureDrop) into a new area that has a different set of security properties and a different set of protections than the SecureDrop workstation. The team had to consider the interaction of the built-in clipboard function and the SecureDrop window where the user is reading this document. In doing so, they had to understand how the data was handled, how memory is allocated, and what are the attacks that someone can perform on memory. They performed a threat modeling framework while understanding potential harms.

For the SecureDrop team to investigate the viability of this feature, they had to understand the architectural level of their code base and run a series of security tests driven by the questions in their threat modeling framework. For users, what seemed like a simple feature to add was actually incredibly difficult and nuanced for SecureDrop to add. While they wanted to support the request from their users, they ultimately decided against adding the feature as it breaks the security model of Qubes and poses a security risk for users.

Wireframes Make it Real

You might have already created wireframes or drawings to showcase to your community, which is helpful when demonstrating the overall flow for your product. We also recommend creating them during the prototyping phase. Wireframes and product sketches are a great way to walk your community through your prototype and its functionality. Initially, sketching together the vision for the product is a part of the ideation phase with the community but it helps to have a designer take suggestions from the community and make it real through a visual demonstration. For example, a community member may say “we need a really easy way to see if a message has been sent securely through our system.” A designer may take that and think, “the users need a confirmation message or signal that the message or document went through, and another that it was received, along with some kind of notification that the security or encryption of the device worked, too. These two features could be wrapped into one.” Your designer can mock this up and present it back to the community to see how that feature resonates with the group.

Keep in mind that wireframes and sketches can be hard to infer, and understand, even if your community really understands technology! If there is a functionality or an interaction that isn’t immediately apparent, annotate that or write a note on the sketch. Better yet, walk your community through it (either online or in-person). Move slowly and encourage people to speak aloud and ask questions when they get confused. It’s important to make sure everyone is on the same page. Additionally, presenting it live to your community can help you see things you didn’t notice at first. Maybe something you thought was obvious isn’t? Maybe you’re missing a small feature you didn’t quite think about? This kind of back and forth helps finesse the project and create stronger, more realistic wireframes.

For example, we have had great success in making a fast product sketch to send over email to our stakeholders and community to quickly gauge “is this what they were imagining” when we were discussing product requirements and features. These quick sketches can elicit great feedback from the community. This lightweight process helps people define product goals without having to waste a lot of hours and time in generating the specific user interface or feature into the code base of a project.

Streamlining Your Product Development Pipeline

Creating a specific development-to-production pipeline can help minimize the time between updates. The SecureDrop team has found that moving from alpha to beta can result in a lot of development changes moving really quickly. Alpha is often the space where you are rapidly learning and iterating because the product is in use and you’re moving towards a more stable and larger release or the beta release. Anything can change at the drop of hat, so having a streamlined product development pipeline can help your team more easily and quickly respond.

In some cases, updates will happen frequently and sometimes there can be long stretches of time between updates. Long stretches can result in losing the alpha testers or any new users, so the more easily and quickly your team can iron out issues, respond to glitches, and add in new, needed features, the better it will serve your community.

Threat Modeling and QA-ing

Building your alpha is a perfect time to see what your product looks like in practice, especially from a harm mitigation perspective. While we learned and applied threat modeling in Chapter 3, launching any version of your product will require another review of the threat modeling principles. Now that you have something to release, there might be new harms or threats that can be faced by the community through what you’ve created that might have been overlooked beforehand. To reapply the framework, review the feature requirements and whether they are prioritizing one group’s needs or safety over another. More specifically, look at the entire project and ask: What could possibly go wrong? What’s the worst thing that could happen in our project, across your community, and users who are very different from our community? This can be helpful for not just your users or community, but a good general privacy by design practice to fold into your product design.

By applying threat modeling tactics for different user groups in the release phase, it allows you to more holistically look for ways in which your project may have blind spots or accidentally create unsafe or potentially harmful scenarios. Looking back at Chapter 3, we introduced the case study of Facebook requiring users to use their ‘real names’ and the harm that can cause for certain communities. Though this made sense to Facebook’s authentication systems and passed earlier phases, testing this in the release phase would have shown the team how actual users would have reacted to the policy and ultimately how some people would feel unsafe.

It can also be helpful to put yourself in the shoes of the attacker or a malicious site to understand how they will use the new features. By asking how they would harass your users or the project itself, and purposely use your software to harm, it allows you to see where there are gaps in security, privacy, and even a user’s ability to agency to make choices in your project. Dana Fried, a Senior Software Engineer who works on Google Chrome, uses this thinking when they tweeted: “Whenever you're rolling out a new service or feature, ask yourself: what would 4chan do with this? Then plan accordingly.” 4chan is a popular image-based bulletin board platform online that allows people to post anonymously and is known for sharing inappropriate content that would be moderated or removed elsewhere online. Through its anonymity cloak, its users often post, share, or abuse the content or users from other platforms. Preparing for how 4chan would use (or abuse) your new features can serve as a litmus test for some test cases.

To understand how we would analyze a process like this, we will use an example of a payment app that publicly shares payment transactions across its users. If a user of the payment app is targeted or harassed online, someone could look at their public profile on the payment app and use that data to harass the victim or anyone who has engaged in a payment transaction with them. This would require the team to look at the solutions or harm mitigations this user would need. Perhaps the ability to immediately hide their public payment history, or quickly go private, or a security setting that makes their history not discoverable outside their friends list. Adding in these features makes your product generally safer for all users, not just ones experiencing harassment.

Along with working through the different threat models, the security of the product needs to be tested through a QA process. Each time the code is updated, you need to have at least one dedicated QA person who is testing the technology across as many platforms as possible. This includes various types of Android and iOS devices to ensure that it is accessible on multiple platforms and that there aren’t gaps in the code that allow third parties to access information related to your users. Since the QA process will have to happen regularly, creating guides and checklists will help standardize the process so that the same elements are reviewed every time.

Create a Plan to Respond to Users in Real Time During Alpha

While we cover this more in-depth in the launch phase, it’s important during the alpha release to have a way where users can flag an issue for you or request a feature and have a system in place so your team can respond quickly. This could be a ticketing system on your website, feature updates with detailed notes via an app store, GitHub changes, or email updates, etc. Responding to your users and your community will help alleviate any confusion and friction in an early release phase where it is so important to have their support and understanding of the process.

Additional Tips For Launching

Based on our previous experiences, we’ve collected some additional tips to consider when launching your alpha release.