Designing the Access My Info Tool

As discussed elsewhere on this site, Access My Info (AMI) is a tool that empowers customers of commercial data operators to make justified requests for access to the personal information that companies hold on them. This post describes the rationale behind the technical decisions that went into AMI’s implementation and its initial deployment with our launch outreach partner, Open Media.

Privacy considerations

In addition to achieving the tool’s core objective of creating a legal request for access, we developed AMI to collect none of the personal information that people input when creating their request. We did this because the substance of a legal exercise of one’s rights — in the case of AMI, an access request letter — requires the input and disclosure sensitive information. In a nutshell, DSI and any implementers of AMI have no business or interest in knowing Canadian citizens’ telco subscriber information, their names, addresses, and the metadata tying all that together. This kind of personal information should only be shared between the data operator and the citizen requesting access.

Nevertheless, we and our partners have several secondary objectives associated with this tool. For instance, researchers and policy makers interested in data privacy can benefit from learning about the outcomes of individuals’ requests for access to their personal information. Some research and policy questions include: how many people submitted requests, and to which companies? How many people received full responses? What data fields were provided by telecommunications companies, and where are there similarities and differences between responses?  Furthermore, outreach and advocacy organizations who deploy this tool may be interested in maintaining a healthy community of citizens interested in data collection, retention, or privacy issues, which could include discussions with people about their experiences using the tool.

To accomplish these secondary objectives without undermining the tool’s policy of collecting no user-submitted information, we added a final, optional stage to the web application’s letter generation wizard. Specifically, we included a link to an external website which appears after a citizen has generated their request. Using this link, citizens can decide to submit a form indicating whether they would like to help out with the research and stay in touch with the outreach partner.

AMI itself does not collect user-submitted data, nor does it embed externally-hosted data collection forms into its interface. By nudging users to a clearly different website to voluntarily share information with our outreach partner, Open Media, we are creating a logical distinction between the process of creating a request through AMI and any supplementary, optional processes that involve the submission of personal data to another party.

Role of the Individual

Another important design consideration is the request filer’s autonomy. In addition to not collecting user-submitted information, the tool does not send requests on people’s behalf. It is up for the individual to either mail the request physically or electronically after having generated it. Because we have made this design decision, the companies receiving AMI-generated requests should not question the request’s origin or dismiss the request as vexatious.

While this results in a slightly more substantial time commitment on the behalf of requesters, we regard the extra time as important so that the requests are not dismissed out of hand. We want to empower individuals to exercise their rights, not just empower them to send requests that will be disregarded by the recipients.

Everything Clientside

AMI guides users through a multi-step form that pulls in data specific to selected companies and their services without sending data to a server. We achieve this by using the client-heavy JavaScript library AngularJS. Inputted data is stored in the web browser as Javascript object instances and manipulated at various stages of the process by leveraging Angular conventions.

The PDF letter that is generated in AMI’s final stage also relies on a JavaScript library, called JSPDF. JSPDF converts the HTML output of the letter to a PDF entirely within the user’s web browser; having created the PDF, the requesting individual can then save the document to their computer to print and mail to their telecommunications provider.

People sending an email version of their request letter click on a mailto link with pre-populated to, subject, and body fields that will open up a new email window in the requester’s desktop web client of choice. All that remains is to review the letter in one’s mail client and then hit send.

Future Work

A major area of future work for the AMI tool is to expand the number of supported companies beyond simply telcos. A wide range of Canadian commercial entities collect, process, and disclose personal information. AMI has been developed to easily accommodate new companies and services, but nevertheless to support them would require a significant amount of work to prioritize and select companies of interest, identify the types of personal information collected by their services as well as known and potential uses of that information.

Open Source Software

A major area of future work for the AMI tool is to expand the number of supported companies beyond simply telcos. A wide range of Canadian commercial entities collect, process, and disclose personal information. We developed AMI to easily accommodate new companies and services and we will identify new sectors and organizations based on internal prioritizations; however, we welcome any interested members of the Canadian or global Internet community to clone, fork, and submit pull requests back to AMI through our source code repository at Github. AMI is released under the Apache 2.0 license. If you would like to discuss how you could help further the tool’s development, please drop the developer, Andrew Hilts, an email at andrew@digitalstewards.ca.