Allowing Kanary Users To Add Their Own Exposures

image of a button with a plus sign and text: Add Exposure

Sometimes Kanary members knew about exposures that weren't caught by our scans.

For the first few years, we handled this unofficially: members could email our support team who would manually input the exposure into our Django admin dashboard.

Eventually, we decided to support this as an official feature. Turning it into a self-service flow would provide three significant benefits:

  1. Relieve pressure from our support team.
  2. Make manual exposure submissions a visible feature to users.
  3. Provide an added incentive to upgrade to Premium and a new feature we could promote.

Requirements

Allowing for open-ended submissions wasn't as simple as just accepting a URL.

Kanary's app ran automation to remove exposures from Google and data broker websites. However, these often appeared in lists or directories of multiple people. We needed to know what our member's exposure contained in order to properly target it for removal automation.

Additionally, Kanary accounts could have multiple members. And each member could have multiple variants of names and other data. (Addresses, phone numbers, etc.)

When an exposure was found in an automated scan, we knew all of this from the start. But to align user-submitted exposures with that data, they needed to be properly tagged: Which member was exposed? What data does it contain? Does it also appear on Google?

The solution:

I created a new screen with two components: a form for collecting the exposure details alongside a list of previous user-submitted exposures.

As many potential pieces of data could be exposed, I implemented a progressive disclosure pattern to keep the initial experience focused. The form only showed <select> inputs for specifics after the member indicated the type of info being exposed.

In action:

Written