Developing Privacy Best Practices for Direct-to-Public Legal Apps: Observations and Lessons Learned
Notice bibliographique
Résumé
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.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,001 | 0,015 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,000 | 0,001 |
| Études des sciences et des technologies | 0,002 | 0,000 |
| Communication savante | 0,001 | 0,002 |
| Science ouverte | 0,001 | 0,000 |
| Intégrité de la recherche | 0,000 | 0,000 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,000 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; un appel candidat d’une seule tête enseignante, pas un consensus.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».