Developing Privacy Best Practices for Direct-to-Public Legal Apps: Observations and Lessons Learned
Bibliographic record
Abstract
Canada’s access to justice problem is undeniable. Too many people are unable to get the help they need when they experience legal issues. The reasons underlying this problem are multi-faceted and complex. One major barrier to effectively accessing justice is the cost of legal services; the fees associated with hiring a lawyer are often prohibitive. Increasingly, technology is advanced as a potential solution to the unaffordability of conventional legal services. Courts have tried to create efficiencies by, for example, allowing for e-filing and video- conferenced testimony, where appropriate. For lawyers, new technology products emerge almost daily to help streamline tasks such as legal research, practice management, document creation and civil discovery processes. Indeed, Canadian law societies are now considering whether lawyers have a professional duty to be technologically competent. In addition to such developments in the courts and in lawyers’ offices, there is a flurry of activity related to developing technological tools intended to be used directly by the public to address legal needs. For ease of reference, we will refer to such tools as ‘‘DTP (direct-to- public) legal apps.”\nAs useful as they may be, DTP legal apps raise unique and important privacy issues. This article discusses a project we undertook with the goal of creating a set of privacy best practices for DTP legal apps. Our interest in privacy issues specific to legal apps dovetailed with the Office of the Privacy Commissioner of Canada’s (‘‘OPC”) interest in encouraging the development of sector-specific guidance for compliance with privacy obligations. We obtained funding from the OPC to carry out this project in 2017 which resulted in a final report, Improving Privacy Practices for Legal Apps: A Best Practices Guide, submitted in March 2019. A full copy of this final report can be found in the Appendix. In this article, we detail our work on this project, including the challenges faced in fulfilling our research mandate (to draft a model privacy sectoral code for DTP legal apps) and the lessons we learned in that process.\nOur goal here is twofold. First, we hope to provide the foundations for future projects and conversations relating to the optimal provision of DTP legal apps in Canada, and the development of privacy guidance for DTP legal app developers. Second, we provide critical reflections on the objective of creating a sectoral privacy code, particularly in a rapidly evolving technological context. Neither of these issues have yet been the subject of dedicated scholarly analysis. This article aims to fill this gap and facilitate more informed discussions about both the provision and regulation of DTP legal apps in Canada and privacy regulation in emerging digital spaces more generally.\nIn Part I, we outline the background and context of the project. In Part II, we discuss the feedback we received about privacy concerns and the best practices model from developers engaged in the creation of DTP legal apps. Part III considers how structuring the best practices guide through the lens of the Personal Information Protection and Electronic Documents Act (‘‘PIPEDA”)1 imposed specific, and sometimes problematic, constraints. In Part IV, we highlight some particular features of the DTP legal apps ‘‘sector” and identify how these realities impacted the development of what was initially conceived of as a sectoral privacy code. In Part V, we examine the role of law societies in relation to a privacy code of practice for DTP legal apps. In Part VI, we reflect on the final best practices guide we created. Finally, we revisit the lessons learned from this project.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame distilled prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.
Codex and Gemma teacher scores by category
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.001 | 0.015 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.000 | 0.001 |
| Science and technology studies | 0.002 | 0.000 |
| Scholarly communication | 0.001 | 0.002 |
| Open science | 0.001 | 0.000 |
| Research integrity | 0.000 | 0.000 |
| Insufficient payload (model declined to judge) | 0.000 | 0.000 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one teacher head, not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".